Visit Modern Campus

The Value of Service Oriented Architecture in Higher Education

Adopting service-oriented architecture in higher education IT practices ensures that all departments are united under the common theme of strong customer service. Photo by Khalid Khalil.

Service Oriented Architecture (SOA) is an approach to building technology applications that aligns business and IT goals. This is accomplished by defining and building services that are business focused and can be reused and deployed across multiple software applications. The value proposition from the business perspective is that SOA enables business flexibility and agility while focusing on the goals of the organization. In order to build and deploy SOA-based applications, the technology team must first understand the business processes and build services that represent these processes. Applications then become the composition of a set of business services that accomplish specific functions that are aligned to business objectives.

In the technology domain, SOA has been around for a number of years and has been successfully used in many organizations. In recent years, however, many more organizations have shown interest in standardizing their application development processes around SOA. There are a number of reasons for this uptick in interest, but I think one of the primary drivers is the proliferation of cloud-based vendors and the need to integrate disparate platforms.

I believe that Higher Education in particular will benefit immensely from the SOA way of thinking, since Technology, Departmental, and Administrative staff must work together to clearly articulate services and how they may be offered to constituents or end users. This can offer new, creative, and innovative ways for an entire community to work together. This beats the current method of IT engagement where IT writes requirements based on a meeting or their current knowledge, then goes away and delivers software sometime in the future. In that model, IT is nothing more than an order-taking organization that produces software based on the existing operating model. Leveraging SOA enables the entire community to think more broadly and have a say in the process which should result in an improvement over existing status quo.

For a little more background information, there are eight core principals of SOA that benefit IT organizations, including loosely coupled and open standards-based architecture design principles that leads to faster and more reliable software delivery. Following these principles will increase the agility of IT organizations to respond to changes in their software environment, such as an ERP or services provided by Cloud vendors. More information on the SOA principles may be found at the SOA Principles website. Additionally, a collective of SOA thought-leaders have crafted an SOA Manifesto. Rather than try to summarize the points, I will simply quote from the SOA Manifesto document:

“Through our work we have come to prioritize:

  • Business value over technical strategy
  • Strategic goals over project-specific benefits
  • Intrinsic interoperability over custom integration
  • Shared services over specific-purpose implementations
  • Flexibility over optimization
  • Evolutionary refinement over pursuit of initial perfection” (SOA Manifesto), [1]

Take a few moments to absorb how powerful and profound the impact these simple statements can have on a technology organization if put into practice and followed religiously. Following these principles put into perspective what may be achieved by altering the organization’s focus from building siloed applications with a specific and unique purpose to building broad-based business services that can be shared and reused across the entire community or enterprise. It also suggests that one can evolve an application over time so you don’t have to pretend to get it perfect on the first pass.

I have found these principles to be personally empowering as I work with my team to deliver on our SOA initiative at Yale University. It is very similar to any agile-based project methodology where the team (including departmental, administrative, and technology staff) work together to define the project outcomes and the delivery schedule. Think about it, project work is often done in ‘Waterfall’ (image below) fashion where requirements are defined up front with the expectation that you know all the answers before the work really starts. Then the project proceeds in a relatively fixed way until complete. Unfortunately, our world and work environments are so complex now that no one knows answers up front so projects that work in such a linear and prescribed manner often fail to deliver a viable product (or they end up being changed later based on what has been learned on the project!). Most people work more effectively by defining what you know, building and evaluating the resultant product, then evolving the end product in a series of incremental build cycles until the product is finished. This ensures visibility into the entire process so anything that is incorrect may be fixed early in the process. This manner of working also enables a team to learn from experiences and evolve their thinking to better approximate the true business needs. If this doesn’t describe the collegiality within higher education, I don’t know what does!You may have discerned from the description above that a SOA program requires an organization to change its operational paradigm. For some people, this means new and exciting input into current business practices. For others, it may seem like a loss of traditional control. Regardless of your perspective, a SOA program signals the beginning of a modular and more agile approach to serving customer needs and supporting the mission of the organization.

Here is a summary of the value proposition for various constituents and participants:

Technology Team

  • Opportunity to work closely with departments and business units to understand their perspective when building services
  • Increased quality from building applications with reusable services (less errors come from services that have already been built and tested)
  • Systems will be composed faster (with reusable services) so the time to deploy applications is reduced
  • Incremental build and deliver process enables team to focus on core capabilities within build cycles
  • As a result of deploying services for public consumption, the technology team will move from a linear development process (see Waterfall) to a circular or continuous one (see below). This enables the organization to focus on continuous improvement rather than ‘build it and forget it’ that was the mantra of many organizations in the past.

Departments and Administration

  • Opportunity to provide critical input into business services requirements
  • Priorities for software development are defined by these stakeholders
  • May evaluate current business practices to determine opportunity for improvement
  • Incremental build and deliver process enables visibility and transparency into product results early and often

Community at Large (including students and faculty)

  • Ability to leverage public technology services to access data needed for personalized applications (many organizations frown upon custom and personalized apps, but a SOA program actually enables this process. Important note: one must be authorized to access data since there is a strong Information Security model to protect private data).
  • Priorities for software development are defined by these stakeholders
  • Opportunity to provide critical input into business services requirements

In summary, there are many benefits that Higher Education organizations will receive from adopting SOA and initiating a program around these principles. At this time, I would like to point out that this is not a panacea and will not fix any IT issues that may exist. It can, however, assist an organization in defining a new paradigm for delivering IT solutions. In essence, SOA demands that business, not IT, drives priorities. If nothing else it should improve the level of customer service an IT organization provides. We are a service organization after all, so shouldn’t quality customer service be at the top of our list?

Much of what has been stated here has little to do with technology. Yes it is true that SOA is a technology program, but many of the principles lend themselves to the strengths of Higher Education: Collaboration, Collegiality, Cooperation, and supporting the higher mission of the institution, just to name a few. So, with very little investment in financial capital, some of the basics can be implemented immediately. Of course, some capital investment is preferred to really get SOA off the ground. I am very thankful that Yale has chosen to invest in this program because I believe it will pay big dividends in the future.

I will end with a statement I read a long time ago at one of the most innovative organizations on the East Coast (Stew Leonards grocery). I have always held these statements as one of my primary operating principles as I perform my job:

Our Policy:

  • Rule 1: The customer is always right!
  • Rule 2: If the customer is ever wrong, reread Rule number 1.

This happens to be carved in stone at the entrance to their stores.

Think about the relationships that can be developed by IT with that attitude!




Author Perspective: