Once again the participants in the SOA discussion group have got themselves all riled up about what exactly SOA is and why it may or may not be working. Here’s my two cents. We’ll start with another history lesson. (Skip it and get to the meaty bits.)
Once upon a time, the employees of Example Corp. complained to the Finance department that they were tired of using spreadsheets to file expense reports. So Finance went to IT and said, “Build me an expense report management system — and I want it by the end of the year.” And IT went among the people in HR and Finance and the company at large and gathered requirements and analyzed business processes. After which they returned to Finance and said, “The end of the year’s out. How ’bout June?”
“Just get it done,” said Finance.
In December of the following year IT delivered a system that more or less met most of the requirements they had gathered. “Fine. Sure. Whatever,” everyone said.
Then one day, Finance came back to IT and said, “Hey, I need to pull all expense data into our new ERP system.”
“No problem,” said IT, “We’ll code up a batch process that produces a monthly report and then we’ll insert that information right into the ERP system’s database.”
“Erm, Okay.” said Finance, and went away bewildered. But some months later Finance returned to IT and said, “We’ve upgraded the ERP system, and now that expense thingy isn’t working anymore.” As it happens IT had just been visited by Consulting who had said, “My consultants are tired of entering expense data twice. Fix it.”
IT was sullen. How were they ever going to integrate all these systems? And shouldn’t they prepare ahead of time for the pending acquisition of Sample Systems?
“We could publish our database schema,” said one IT member.
“Won’t work. People will enter things wrong,” said the lead developer.
“Maybe, but that means deploying database client libraries everywhere.”
“We could create an API that we distribute to everyone who asks,” suggested another IT member.
“Too many languages, frameworks, and operating systems,” replied the lead developer.
“Didn’t someone just buy an EAI engine? Couldn’t we use that?” asked a third developer. Everyone laughed.
“What about CORBA?” queried the new guy.
“What about what?”
“CORBA. Look, see. Interoperable remote procedure calls. Keep the business logic over here, publish the interface, let the client worry about the rest. I’ve already built a prototype.”
The IT people were impressed. They showed the prototype to Finance and Consulting. The prototype was quickly moved into production. Flush with success, the lead developer said, “You know what, we should make everyone do this. From now on no more application silos. Everyone must make functionality available over the network.” But few listened. The Microsoft guys said that it sounded right in principle, but we should use DCOM. The mainframe guys went on building CICS apps. And, frankly, it went right over the heads of the PowerBuilder and ColdFusion guys. Worse, CORBA wasn’t quite as easy to use as it seemed. It was complex, nothing interoperated, it didn’t work through firewalls, and a bewildering number of specs were coming out of the OMG.
“Well, how about this new SOAP thing,” said the new new guy. “It’s simple, it works through firewalls, all the vendors are on board, and, look, there’s only three specs, and we don’t need this UDDI one.” There was much rejoicing. “This just has to work,” said the lead developer (now promoted to enterprise architect). “I can’t prove it, but I can feel it in my bones. We just need to give this idea a name.”
“I’ve heard it called service-oriented architecture,” said the new new guy.
“Service-oriented architecture, ay? I like it. Nice acronym too. SOA. Lets pronounce it soh-uh.”
Soon, the word spread throughout the land: No more silos. Make functionality available on the network using standardized, interoperable protocols. We’re service-oriented now. And, believe it or not, people got it. Now that they could see that it just might work, it seemed like a painfully obvious idea. Building silos is bad. Exposing functionality on the network is good.
And… Well, you know the rest. They picked the wrong technology again, despite the fact that the right choice was staring them in the face. Like CORBA before it, SOAP wasn’t quite as easy to use as it seemed, interoperability was problematic, and a bewildering number of specs were coming out of the W3C, OASIS, and the vendors themselves. Not only that, there was a big pile-on of suspect products, pie-in-the-sky promises, and ever changing architectures. But, really, all that’s besides the point. The point is that more people than not understood the value of deploying standards-based, network accessible business logic.
So, then, what is SOA? For one thing, SOA is misnamed. It’s not an architecture in any sense of the word. It is, to use a Burton Group phrase, a mind set. It is the generally held belief that when implementing systems one should expose system functionality for general consumption directly from the network, as well as or instead of burying it behind a user interface. It is, as well, the belief that there is a great deal of value to be generated by retrofitting network accessibility into most existing systems. And it is the belief that this can only work if the means of doing so aren’t locked to a particular language, framework, operating system, vendor, or network architecture.
Another problem with the SOA name is the “service” bit. At least for me, the term “service” connotes a collection of non-uniform operations. I don’t even like the phrase “REST Web services.” Certainly, SOAP/WS-*, CORBA, DCOM, etc. fit this definition. But REST? Not so much. In REST the key abstraction is the resource, not the service interface. Therefore SOA (and I know this is not anyone’s strict definition) encompasses the above mind set, but includes SOAP and similar technologies and excludes REST.
A better name for SOA, then, might be network-oriented computing (NOC). This encompasses both WS-* and REST (and most everything else from the socket level up). We can, if we want, make SOA and resource-oriented architecture (ROA) a subset of NOC. In which case the “architecture” bit makes sense again.
“But wait,” I hear my SOA-loving readers say. “SOA is not about exposing business logic on the network. That’s just a technology thing. SOA is about the business! CxOs and business units don’t care about technology, they will only pay for business solutions.” Which always makes me scratch my head. What exactly does IT ever do that’s not about the business? Do they not work for the same company as the other BUs? Is a firewall about the business? Of course it is; there’s a business requirement to maintain information security. Is a router about the business? Obviously, the business is demanding networked communications. Is an application server about the business? Yep, having someone else write all the plumbing gets systems out faster, and that’s a business requirement. How about Agile? That too is a business requirement, faster, better software. Testing? Yes. VoIP? Yes. SOA? Yes.
“No, no,” the SOA-is-business advocates reply. “It’s not just ‘business’ it’s better alignment with business. You see, if we can identify a business process such as ‘open new account,’ then we can create a service called OpenNewAccount. You see how those things line up there.” All well and good, say I, but as Stu and Steve say, “Things change. And besides, what if you’re in perfect alignment with the business, but the system doesn’t work? What if it doesn’t scale? What if clients can’t use it? What if the programmers can’t code it?”
“Well, it’s not just about business alignment,” another group of SOA advocates claim. “It’s really about governance.” Again, I’m scratching my head here. Everything is about governance! Software development (network-oriented or not) is about governance: ‘You must use a version control system; you must write unit tests.’ Moving systems into production is about governance. Updating a routing table is about governance. Hiring a new employee is about governance. Buying a plane ticket is about governance.
“No, no.” They go on. “With SOA there’s new things to govern.” That’s true, there are. But really, is it that much different than any other governance process? Not really.
(By the way, I’m also on record as saying that REST requires less governance than WS-*. While others might say the governance needs are the same. I stand by what I say by noting that if there’s any chance in hell of getting all this to work, it’s going to require a truck-load of governance.)
So, that’s it. As Stefan also points out, SOA today has a number of fluid definitions: It’s the notion of tearing down silos and making functionality available on the network (frequently with the WS-* stack implied), it’s the use of governance to ensure that people do this right, and its the alignment of business with IT. If any of these can be considered more right than the other (by usage or historical precedent), then I would have to say it’s the first.
No matter which definition works for you, though, SOA is misnamed. So I’ll leave you with some updates to your lexicon:
- Network Oriented Computing (NOC): An approach to computing that makes business logic available over the network in a standardized and interoperable manner.
- Service Oriented Architecture (SOA): A technical approach to NOC that has a non-uniform service interface as its principle abstraction. Today, SOAP/WS-* is the chief implementation approach.
- Resource Oriented Architecture (ROA): A technical approach to NOC that has an addressable, stateful resource as its principle abstraction. Today, REST/HTTP is the chief implementation approach.
- Business Service Architecture (BSA): An unnecessary term (also not an architecture) that tries to make the obvious something special. Aka, business analysis. Aka, requirements gathering.