The promise of Service Oriented Architecture

In his presentation on the Business Value of Service-Oriented Architecture (Ordeedolchest, 2004), Manoo specified 4 major business reasons for implementing a Service Oriented Architecture: Cost, Productivity, Partnership, and Agility. By using a service model in which individual services perform discreet functions based on a well-defined contract, developers can increase the reusability of their code, which in turn promotes a high return on the initial investment by allowing other business units to utilize pre-existing code.

While Manoo’s insights were useful, they were also somewhat predictable. In his blog “Industry Observer” (Juneja), Niraj Juneja made the point that due to the cyclical nature of Information Technology, there are frequent cycles of hype regarding specific technologies, leading to a tendency to talk about how “The next great thing” will boost everyone’s productivity, while decreasing overall cost.

A more interesting insight into the nature of SOA, in my opinion, came from Victoria Ho (Ho, 2008) in her article about the impact of the “Facebook Generation”. According to Ho, the emerging workforce expects business applications to function much the same as their Facebook or MySpace page. Employees expect applications that quickly and intuitively interact with one another, and that can be recombined to create new applications.

Keeping in mind the perspectives of both Manoo and Ho, it is clear that SOA’s biggest promise is Interoperability. However, this also leads into the largest challenge facing SOA developers and architects: Building a service that is both general enough to be reused, and specific enough to fill a business need.

The challenge of granularity vs. generality

In his article “Solving the Service Granularity Challenge” (2006), Schmelzer reminds us that the important question is not so much how to build a service, but how to define it such that it has the right balance of granularity and generality. As the architecture develops, Schmelzer advocates constant refinement of the services such that they eventually achieve the optimal balance of single\multiple use and fine\coarse granularity balances. “After all, building Services is not the goal of SOA – it’s building an architecture that allows businesses to continuously evolve their set of useful Services that the business wants and can leverage despite ongoing change” (Schmelzer, 2006).

John Crupi offers an interesting approach to determining roughly whether or not the service is too finely grained: Focus on nouns, not verbs. In discussing some examples he cites the “Employee Service”. This is a noun, and is a coarse-grained service. It would be composed of such items as “Add”, “Query”, “Update”, etc. However, Crupi’s argument is that if the service is the “Add Employee Service” it is too finely grained, and does not make use of the full benefits of a Service Architecture.

References

Crupi, J. (2005). SOA Service Granularity. John Crupi’s Weblog. Retrieved March 8, 2009, from http://blogs.sun.com/crupi/entry/soa_service_granularity

Ho, V. (2008). ‘Facebook generation’ driving SOA adoption : News : Software – ZDNet asia. Retrieved 1/5/2009, 2009, from http://www.zdnetasia.com/news/software/0,39044164,62047994,00.htm

Juneja, N. Industry observer: SOA adoption down from 2006 – are you surprised? Retrieved 1/5/2009, 2009, from http://www.gandalf-lab.com/blog/2008/08/soa-adoption-down-from-2006-are-you.html

Ordeedolchest, M. (2004). The business value of service-oriented architecture.

Schmelzer, R. (2006). Solving the Service Granularity Challenge. ZapThink:: Research. Retrieved March 8, 2009, from http://www.zapthink.com/report.html?id=ZAPFLASH-200639