Forensic SOA
One surprising but intriguing sign that Service-Oriented Architecture (SOA) is finally entering the mainstream is the increasing number of lawsuits over the perceived failure of SOA implementations. Here’s the scenario: enterprise hires large consulting firm to implement SOA. Large consulting firm uses their small handful of SOA experts to sell the deal, but brings in the large team of wet-behind-the-ear college grads to do the design as well as the implementation. Enterprise is unhappy with the result, and sues consulting firm, claiming they paid for SOA, but didn’t get it.
The reason ZapThink is tuned into this trend is actually quite fascinating: needless to say, the lawyers for the plaintiffs need someone who can step in as expert witnesses and say definitively what SOA is, and more importantly, what it is not. And where better to turn than ZapThink? Believe it or not, this is a growing part of our business.
As a result, we’ve spent some time thinking about just where to draw this line. Now, if there’s no lawsuit pending, then whether or not what you’re doing is actually SOA is somewhat of a pointless question; after all, what matters is whether what you’re building actually solves a business problem. It doesn’t really matter if you can call it SOA or not. But be that as it may, there’s still widespread confusion and ongoing misinformation in the marketplace as to what actually qualifies as SOA, so this question is more relevant than maybe it should be. Here, then, is how we go about making the line between SOA and non-SOA clear.
Minimum SOA Criteria
The first point to remember is that SOA is architecture, in other words, a set of best practices for the organization and use of IT to meet business needs. This criteria, however, sets the bar quite low, since virtually any implementation follows some sort of organizational principles. Whether those principles are best practices, furthermore, is open to interpretation.
The second point, then, is the fact that SOA is an architecture oriented toward Services, and thus the definition of “Service” and whether the implementation follows an architecture that is oriented toward such Services becomes the critical question. The problem here, though, is that the word “Service” has several different meanings, even in the context of IT — and defining a criterion that SOA must be oriented toward the sort of Services that we mean in the context of SOA is a circular tautology. We need to be more specific about what we mean by Services.
The next question might be whether Web Services have anything to do with the definition of SOA. Does SOA require Web Services? Clearly not. In fact, SOA is both technology and protocol neutral. We could implement SOA using CORBA if we like, or we could even create a completely proprietary environment — proprietary networking protocol, proprietary messaging protocol, proprietary infrastructure, the works — and we could still implement SOA with it if we really wanted to.
In fact, we mean something more by Service than a Web Service, or even a Service interface of any kind. The essence of a Service in the SOA context is the business abstraction — that is, a representation of functionality and/or data presented in a loosely coupled business context. So, is implementing an abstracted Business Service either necessary or sufficient for SOA?
ZapThink’s perspective is that yes, for an implementation to be a SOA implementation it must include at least one abstracted Business Service. Just how loosely coupled this Service should be, however, is still open for interpretation. After all, coupling is a complex spectrum, and comes at a price. If the business requires minimal loose coupling, the implementation may still be Service-oriented, as long as the business abstraction meets a business need. We would say, however, any Business Service should have some measure of loose coupling to qualify as a Business Service. Any implementation of Services where all the Services are tightly coupled would therefore not qualify as SOA. It seems, then, that a necessary and sufficient condition for an implementation to be a SOA implementation is for it to include at least one abstracted, loosely coupled Business Service.
The Three Axes of SOA-ness
Is this criterion the whole story, however? If we find a qualifying Service, can we comfortably bless the implementation as SOA, and go home? Likewise, if no such Service exists — that is, if the Services that do exist somehow fail to qualify as loosely coupled or abstracted, can we be sure that there’s no SOA to be found? Well, as with so many SOA-related questions, the question as to what qualifies as SOA is more complicated as it seems. In fact, there are three related questions to consider:
- We have only been considering this first question so far: is there some minimum set of necessary criteria for SOA? If so, what is it? Such a set would require that removing any criterion from the list would disqualify the implementation from being SOA. Alternatively, might there be alternative minimum sets of criteria, each of which should be considered SOA?
- We might also want to ask whether the target implementation is “bad” SOA vs. “good” SOA? Does bad SOA still qualify as SOA? Just how bad does it have to be before we shouldn’t call it SOA at all? In other words, would an implementation consisting of only tightly coupled Services just be really bad SOA, but SOA nevertheless?
- Furthermore, is the target implementation “immature” SOA vs. “mature” SOA? If the implementation is on the right track but simply immature, does it still qualify as SOA? How immature does a SOA implementation have to be before we shouldn’t call it SOA at all?
Let’s start with #1. Our minimum criteria for a SOA implementation is that there exists one Service that must be (a) a Service, (b) abstracted, (c) loosely coupled, and (d) a Business Service. For (a) we might say that there is a contract that specifies the interface for the Service. (b) requires that the Service masks the underlying complexity of the software for consumption in a business context. Criterion (c) requires that the Service respond to some level of requirements variability, either among consumers or over time. (d), then, implies that there is a business context for the Service. Furthermore, we would like to add (e), that the architecture supports the composition of Services.
For #2, then, we would say that as long as the four criteria in group #1 hold, then it doesn’t matter how bad, or low quality, the implementation is, that is, how poorly it meets the requirements set forth for the implementation. Also note that as per #1, if there are no loosely-coupled Services to be found, that’s not SOA at all. Now, chances are the lawsuit may also claim that the implementation is of insufficient quality, but that question should remain separate from the question as to whether it technically qualifies as SOA.
The resolution of issue #3 falls out of the fact that we are only requiring a single Business Service. The scale of the implementation can in fact be quite limited; a small SOA pilot project could very well qualify as SOA. But if the lowest level on your maturity model fails to meet (a) through (d) above, then that would prevent the implementation from qualifying as SOA at that level.
The ZapThink Take
Our minimum criteria for SOA are actually more notable for what the list is missing more so than what it contains. For example, we don’t include the following:
- Whether there is an ESB or not, or any other particular piece of infrastructure or other technology, for that matter.
- Whether there’s any XML in use. You could implement SOA with FTP and CSV files if you wanted to, and it would still be SOA — not very good SOA, maybe, but still SOA.
- Whether the Services you’ve implemented support composition. True, one of the primary goals of building Business Services is to support composition, and we require that the architecture allows for composition, but we don’t want to set the bar that high for the purposes of our definition. You can still be implementing perfectly good SOA without getting to the point that you’re able to compose your Services to support business processes. Alternatively, your requirements may simply not include composition, for example, when the business only requires data-centric Services. But if you’re architecture prevents all future Service composition, then it wouldn’t be SOA.
- Any mention of the design or planning work separate from the implemented Service. The court is asking if the consulting firm implemented SOA, and drawings on a page, no matter how good, don’t qualify as an implementation of anything. This absence is in line with the Agile principle of working software over documentation.
- Any reference to integration. If you can build a Business Service without having to integrate anything, that’s fine. If you’re not solving an integration problem, that’s fine as well. In many ways, integration and SOA have been too closely associated, perhaps because so many vendors in the SOA space are actually integration vendors. Clearly, you can do integration without SOA, and furthermore, you can do SOA without integration.
The bottom line, however, is that if you’re not battling over this matter in court, then the question as to whether what you’re doing is SOA is far less important than whether what you’re building solves business problems. What qualifies as SOA is an important question, though, for situations where an organization has deluded themselves into thinking that they’re building SOA, when actually they aren’t doing any such thing. Such situations are still quite prevalent, and when such implementations fail, they can undeservedly give SOA a bad name.