Does SOA Really Matter?

There has been no shortage of articles and blogs recently talking about the lack of success that companies are having with service-oriented architecture (SOA). While many people have seen the technology adoption curves from Gartner that show that all new technologies go through a “trough of disillusionment,” it still doesn’t prevent many people from proclaiming that all of the hype was unjustified and asking the question, “Does SOA really matter?”

To answer this question, let’s first revisit the oft-hyped benefits of SOA, which are greater agility and better business-IT alignment. The real question here is, “Does your organization need greater agility and better business-IT alignment?” If the answer is yes, then SOA does matter because something needs to change. The problem with many SOA efforts today, however, is that there really isn’t any change occurring. Instead, the SOA effort is buried within the IT department. At one extreme, despite many people advising to the contrary, there are organizations that equate SOA with technology, whether it is Web services and SOAP, an enterprise service bus, or REST. For organizations in this category, SOA is simply a new approach to integration. While there has certainly been incremental value in moving toward XML and HTTP-based integration technologies over the variety of platform and application-specific techniques of years ago, it is a far cry from increased business agility and improved IT-business alignment.

Moving away from the extreme, there are far more organizations that understand that SOA goes beyond the use of XML technologies, but the effort is still stuck inside the walls of IT. Unfortunately, trying to achieve alignment between two groups requires movement on both sides. So, while IT may have the best intentions, there’s only so much it can do if the business is still operating in the same way that it was before SOA. After all, the business units are the holders of the budget, and if the various business units do not have the same vision of services that IT does, IT is still left to operate within the projects and funding that the business gives it.

At best, in these organizations the SOA effort is going to follow a similar path to object-oriented technologies. Years ago, object orientation (OO) was the hot item in the IT press, making similar claims to what SOA promises now, but we all know that OO never really connected with the business as we had hoped. That being said, you would be hard pressed to find an organization today that isn’t using OO programming languages and concepts for a significant portion of its development. For organizations that have not yet come to an agreement that some fundamental changes in the way the business and IT operate are necessary, it doesn’t mean that there won’t be any services. To the contrary, the principles of service orientation can be applied to an individual application or project and will continue to be. Unfortunately, that also means that the potential benefits are also likely scoped to that application or project.

This now brings us to the third category of organizations. This group has recognition on both the business side and the IT side that there is room for improvement in the way the business leverages technology to achieve its goals. How do they improve? They improve by changing the way in which they operate. For example, if a business has multiple units that have their own customer relationship management (CRM) system, it’s likely that there will be a business need for integration across them. Changing the integration technologies used may produce some incremental gains, but it still doesn’t address the fundamental problem that exists—the business units can’t come to agreement on whether they should have one, two, or five CRM systems. By embracing SOA at both the IT and the business level, we can begin to understand where we need shared capabilities associated with customer management and where we need capabilities that may be specific to one particular line of business. Once we’ve done this, we can now invest appropriately in the technology solutions that support this. For organizations in this category, SOA is not about integration technologies; it is about achieving the appropriate partitioning of business capabilities into a manageable portfolio of independent, self-sustaining assets.

One could easily argue that most organizations today have an application-oriented architecture. That is, if we tried to characterize the suite of technology solutions that support the business, we’d most likely present a collection of applications. The typical application, however, is too coarse-grained. Boundaries are misplaced, and integration with other applications is, at best, an afterthought. As a result, the cost of supporting business change is expensive, and a large amount of redundancy in capabilities exists. A service-oriented architecture, on the other hand, begins with a finer grained concept: the service. A service, on its own, typically is not a complete solution. In order to form a solution, a service requires at least one consumer. This consumer and provider relationship is the key to achieving agility, efficiency, and proper utilization of resources.

Let’s look at this from a business perspective, rather than an IT perspective. Any organization is going to need to hire employees, manage benefits, etc. It is part of doing business. Think about the situation if an organization allowed each department to handle all of this on its own. That organization would likely have inconsistent policies, inconsistent benefits, inconsistent pay, and many other problems. If the federal government issued a new employment regulation, each group would have to implement that change. Now imagine that as part of that change, it wasn’t simply a matter of implementing the new policy, but also firing your existing employees who handle employment and hiring new ones. I think the point should be clear that this is not a situation that any organization would want, yet this is exactly what exists in IT today in many places. When an organization was able to recognize that human resources was a service, it created a human resources department and restructured appropriately, achieving cost reductions, efficiencies, and agility since now there was a one-stop shop where employment regulations can now be managed. At the same time, having a centralized HR department did not require that all groups adhere to one single way of hiring people. Depending on the job position, there may be department-specific variations of the hiring process.

I previously discussed the example of CRM systems. IT may easily be able to see that having five different CRM systems introduces redundancy and creates integration challenges. Simply going back to the business and asking, “Why do we have five different CRM systems?” isn’t enough. There may be sound business justification for having five different sales organizations, and in lumping the entire CRM space into a single application, it becomes impossible to gain agreement on a single one that is best. Instead, we need to break CRM down into constituent services that now allow both IT and the business to understand which domains of services need to be specific to a particular organization and which domains of services are shared across those organizations. This is a conversation that must be understood by both business and IT with appropriate organizational structure that matches the agreed separation between service consumer and service provider.

So, does SOA matter? Absolutely. If you are only looking at struggles currently within the walls of IT, there is still plenty of incremental value to be gained, as well as opportunities or larger projects to set the stage for bigger things. On the other hand, if you know that there are broader issues that are rooted in the way that IT and the business side interact, you need to make a fundamental change. If it is clear that the boundaries that are created by viewing the enterprise as a collection of applications are part of the problem, those boundaries need to change. Taking a viewpoint of the enterprise or some subset of it that characterizes things in terms of service consumers and service providers, showing where specialization and customization is best applied, and showing where sharing and commoditization is best applied can be a catalyst to that change. Change is not a short-term process, however; so you must be committed to seeing it not only through the top of the hype curve but also through and past the trough of disillusionment.

Todd Biske is a senior enterprise architect with Monsanto in St. Louis, Missouri. He is presently working on a book on SOA governance due out near the end of the year. He also is a frequent conference speaker and an active blogger on SOA and other strategic IT topics at www.biske.com/blog/