Published on 2012/07/17
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!

—-

References

[1] http://www.soa-manifesto.org/

Print Friendly
New call-to-action

Readers Comments

Rick Poston 2012/07/17 at 9:48 am

Thank you for this piece, Russell. This is a point I have been trying to get across to my superiors for goodness knows how long; sometimes the best way to perfect something is to put it to market and re-evaluate, repair and upgrade on the fly. That having been said, ensuring your first iteration is strong enough to go to market is a key element of this.

Working collaboratively across the institution will, without question, allow us to develop better, more functional tools that will serve everyone better!

    Russell Battista 2012/07/23 at 5:15 pm

    Thanks Rick. I agree completely with your point about delivering something of value in Iteration 1. In fact, we are in the process of doing just that right now. We are creating services around Student information that won’t be perfect, but folks can test them and let us know what is missing. Most people have difficulty telling you what they want but they can certainly tell you what is missing or what they don’t want!

    Thanks for taking the time to read this.

    Russell

Paul Speranza 2012/08/01 at 8:19 am

Hey Russell,

I totally agree with the whole SOA thing and what I think adds the icing on the cake is Agile. I see it bending a bit more towards REST APIs but if it looks like a service and quacks like a service…

What usually sells it for me is when I explain how apps on mobile devices and dektop browsers have no data and have to always call services (or APIs) to function. The best example you can give is the Facebook apps (multiple phones, tables and browsers). That just about makes the case once they grasp that.

Any way, nice article. I think you have explained it clear enough for all involved parties to understand the benefits of SOA and Agile, which will hopefully inspire everyone involved as to what is possible.

Paul Speranza

Russell Battista 2012/08/10 at 3:47 pm

Hi Paul,
Thanks for the comment. I agree with your points. SOA is such a great fit with Agile that I think they were just made for each other.

Leave a Reply

Your email address will not be published. Required fields are marked *

[if lte IE 8]
[if lte IE 8]