Why Service Oriented Architecture Won’t Work in the Corporate Environment

Warning: Geek post.

First off, please note that I purposely chose a contentious title for this post. (I was tempted to call this SOA Considered Harmful but figured that most people probably wouldn’t get the joke. Especially since I don’t consider SOA harmful; I just don’t think it will fly. But I’m getting ahead of myself…)

To begin with, from Wikipedia, a definition of SOA:

Service-oriented architecture (SOA) describes a software architecture that defines the use of loosely coupled software services to support the requirements of business processes and software users. Resources on a network in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation.

A service-oriented architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including REST, RPC, DCOM, CORBA or Web Services. SOA can be implemented using one of these protocols and, for example, might use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

SOA can also be regarded as a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services. These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. SOA-based systems can therefore be independent of development technologies and platforms (such as Java, .NET etc). Services written in C# running on .Net platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application. Applications running on either platform can also consume services running on the other as Web services, which facilitates reuse.

SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services.

High-level languages such as BPEL and specifications such as WS-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine grained services into more coarse-grained business services, which in turn can be incorporated into workflows and business processes implemented in composite applications or portals.

Now, as stated, I’m very much in favour of SOA. I think it’s the Right Thing; ever since I started seeing people talk about it, it clicked with me. (As mentioned quite a while ago, I even took a course on it, which is rare for me, because I never go on training.) An organization that can create this type of software architecture will be much more agile, and able to quickly meet business needs, than an organization that doesn’t.

But let’s face reality here: In order for an organization to implement Service-Oriented Architecture, it needs to be supported organization-wide. That means both bottom-up and top-down support. (And middle-out support, for that matter—there are a lot of middle-management bean counters out there.) The developers who are building software need to support it, of course, and start thinking in terms of “services” instead of just “applications”. But the people at the top, who control the dollars, also need to support it. And this is where it all falls apart.

Organizations simply don’t work this way. When an organization is beginning a new software project, it’s treated as just that: a project. The person running the project is given a specific task or set of tasks to perform—“create a new billing system” or “modify the call centre portal to support new ‘daylight savings time’ issues” or that type of thing—and given a budget to do it. The person running the project is going to be measured on how well the project meets the stated goals, and whether or not the project goes over or under budget.

Suppose you’re a Project Manager (PM), and you’re tasked with building a new web-based portal for the organization’s call centre. You’re given a specific budget, and a set of requirements that the system has to meet; it must be able to display customer profile information, perform billing transactions, etc. In fact, there will probably be a lot of requirements, for such a system, which will be ranked: Some requirements are “mandatory”, some are “optional”, depending on time/budget, and some are “nice-to-haves”. Because the new application will be for the call centre, the money is coming from the call centre’s budget.

When the PM goes to build this application, if s/he is familiar with SOA concepts, it will become evident that it would make a lot of sense to build a service, for retrieving customer profile data, so that it could be used by other applications in the organization, not just the one in question. Similarly, it would probably make sense to build services for performing billing transactions. But that would cost more; the services would have to be made more generic, to meet the needs of the application being built, but also to try and meet the needs of any future applications, which might want to use them. (e.g. the service which returns customer profile data would probably have to be built to return any and all available data for a customer, regardless of whether the original application needs it.) Which means that, instead, the PM could simply build something to be used only by the application in question, and use the extra money to implement extra features in the application, for the call centre client. Why build services for performing billing transactions—which may or may not ever get used by other applications—when the money could instead be used to implement some of the “optional” requirements for the application?

As far as the project’s budget is concerned, ignoring SOA, and implementing extra features, would mean that the project would meet, and possibly exceed, the client’s expectations. But the next time an application is built that needs to retrieve a customer’s profile, the PM for that project will now need to re-build the functionality; the organization as a whole is spending money twice, that it could have spent once, but there was no incentive whatsoever for the first PM to spend the extra money, since it would have harmed the original project.

As you read this, please don’t misconstrue what I’m saying as “blaming” the original PM, for being selfish. S/He is trying to make the project as successful as possible, and this is the only way PMs are typically gauged. If the original project had been built such that the customer profile retrieval was built in a service-oriented manner, it would save the organization money, overall, but it would make the project less successful. My inner geek would rejoice, but the PM would not be rewarded—quite the opposite! There would probably even be blame laid, for wasting the project’s money on what is, strictly speaking, an IT-related problem, not a problem that had anything to do with the project.

The best way, the only way, for organizations to overcome this problem is to do away with the project-oriented way of creating budgets, and allocating money. I’ve seen a lot of organizations talking about wanting their people to think as if they’re part of the larger organization, instead of just a member of a particular project or projects, but the reality is that they can’t, because they are forced to charge all time against projects. Time and time again, I’ve been on projects where we lent developers to other projects, to help them achieve some goals, but it always came back to bite us, because the developers needed to charge their time somewhere; if the other project didn’t budget for the extra people, then they couldn’t charge there, but if they charged to my project, then they were eating up my project’s budget.

But if there was only one budget, one big “budget for all IT-related activities”, that people could charge their time to, it would be much easier to do the Right Thing. The bean-counters would all develop ulcers, because they wouldn’t be able to track where their money was going the way they can now, but overall, my hypothesis is that the organization would get much better value for its money.

I think we all realize that the “one budget” solution is not going to happen. Organizations feel that they need to track their money as minutely as possible, to enable more detailed reporting, and track inefficiencies. But many of the people who advocate for SOA talk as if the “one budget” way of doing things is the the way things work. Any person I’ve seen talking about SOA talks about the need for organization-wide buy-in—especially the top-down type of buy-in—which is correct, but to make the leap from “buy-in” to “merged budgets” is simply too large of a leap to make. You may be able to convince the upper-management types that they need to support SOA, but you won’t be able to convince them to change the way they budget.

Instead, any organizations that are serious about SOA are putting together piecemeal solutions. They still allocate funds for projects, which have specific, project-related goals, but they also earmark some money for SOA-related initiatives. For example, they may dedicate money for SOA-related infrastructure, like a registry and maybe an Enterprise Service Bus (ESB), and maybe some hardware where the services can be housed, and centrally supported. Or maybe the organization might have some type of SOA “SWAT Team”, for implementing services; e.g. if the project realizes that it will need a “customer lookup” service, they might farm that work out to the SOA SWAT Team. (Of course, this would tie the project’s timelines to the timelines of the SWAT Team; if they’re not able to deliver, the project fails.)

These ideas are steps in the right direction, but they don’t solve the core problem: Any given project is still only funded for work related to that specific project. Any work on top of the project work would need to be justified, and funded, and, as things stand today, that’s not likely to happen. Even if money weren’t a concern, time still would be; you don’t want developers wasting time on the SOA-related development, when they could be building features instead.

I guess, fundamentally, the problem is that Service-Oriented Architectures benefit an organization, at the high level, but do not normally benefit projects, at the low level. If I build this functionality as a service, with the extra complexity that entails, it may benefit another project, down the road, but it’ll cost me more, and, therefore, cost my project more.

Oh, but I know what you’re probably thinking: “Sure, serna, it doesn’t benefit the initial project, but doesn’t it benefit future projects? Suppose you want to build a customer-facing application, where customers can do self-service over the web; wouldn’t it be quicker to develop, because you could re-use the customer profile and billing services?” In theory, yes; it would take less development time to get the next application up and running, and reusing the existing services. But there are two problems that still need to be surmounted:

1. Support: If you’re going to reuse the original services, it means that there will be an extra load on those services. The hardware, network, and other resources would need to be able to support the additional requests. Exactly what SOA is supposed to be about, right? Except that, as things stand now, the people supporting the original project would see this as a risk to the application they’re supporting, not a benefit to the organization. What if the new application puts so much load on the system that it takes down the original application? (If an organization has invested in core service-related infrastructure—and if the services in question are housed there—then this shouldn’t be an issue.)
2. Changes: What if the original services almost, but don’t quite, meet the needs of the new application? An extra parameter needs to be added somewhere, or an extra piece of data needs to be returned? They would need to be modified in such a way that the new application could use them, but the old application would not be broken.
   
   The original application may or may not still be actively developed; either way, there will be problems:
   • If the original application is no longer actively developed, it would be difficult to properly regression test it, once changes are made to the services. Most people would probably give up, and simply create a new version of the services—perhaps even using good ol’ copy ’n paste, to create an entire new version of the code base. The old service would be left as-is, so as not to break the existing application.
   • If the original application is still being actively developed, then changes to the services would need to be worked into its roadmap. The new project would also have to fund the changes. This brings us into all of the problems discussed above, about project benefits vs. organization benefits.

So, all of this being said, do I support SOA in concept? I sure do. As I said, developing applications in this manner, especially in large organizations, is the Right Thing. If all of the issues I’ve raised in this post were removed, developing services, instead of monolithic applications, would make future development much quicker, as services started to get reused. If technologies like BPEL were used, for implementing business logic in coarse-grained services, it would even make the business more agile, because they could change business processes much more easily.

The problem is not with SOA, it’s with the SOA advocates who don’t take the full picture of how an organization works into account, when espousing SOA’s potential benefits. (People do often mention “politics”, but this goes deeper than politics. This is about how organizations fund projects, and allocate work to developers.) We need to stop having a Star Trek mentality, when it comes to discussions about SOA, and start taking into account reality.

I’m sure there are solutions to the problems I’m raising. I haven’t mentioned any, because that will have to be an exercise for readers who are smarter than I am. But we need to solve these problems, so that SOA will become viable.