Enterprise Software

The unfulfilled promise of SOA

For years now, there's been lots of hype about service-oriented architecture, and many of us bought in. Did we get our money's worth?

Looking up at the bookshelf next to me just now, my eyes are drawn to one section in particular -- a well-populated shelf of books on service-oriented architecture. I think I could probably anchor the QE II with those books.

And it's not just the books: I've taught SOA for five years and left in my consultant's wake an SOA-based inventory system, service bus, and EDI reconciliation application.

Now, here's what's bugging me, and why I'm getting really irritated, looking at those books: I'm looking back at that service-oriented architecture, thinking about what it was intended to do and what it cost to put it there, and it's hard to see the ROI.

Service-oriented architecture is supposed to give me all kinds of stuff I didn't have before. The list of miracles that services supposedly offered me is so long I can hardly cram it into one paragraph: loose coupling (minimal dependencies between components); encapsulated logic (sequestered and minimized); reusability (plug the same service into lotsa apps!); statelessness (no overhead consumed by state management); autonomy (services are their own boss, independent of the app); metadata (all services speak the same language), and on and on.

It's more fun than Big Bang Theory, if you're a developer -- but what does it really buy us?

I've used service-oriented architecture for the better part of a decade, and I can honestly report the following ...

  • I have never seen the "contract" feature of any service I've written or designed be leveraged to enable its re-use;
  • I have never seen a service from one system be recoupled to another;
  • I have never seen encapsulated logic used in multiple applications;
  • I figure I have a right to feel a little gypped, at this point.

So I moped about this for awhile, and I briefly considered abandoning SOA as a design default. This isn't too great a stretch, because contemporary design implementation, while extremely modular and loosely coupled, isn't necessarily SOA-oriented per se. It's easy to design modular systems without resorting to services as core components.

But then there's the other side of the ledger ...

Looking back at those SOA efforts, there's a wonderful layer of benefits that aren't as obvious as the ones SOA's apostles claim. It's a layer so rich and substantial that it bears close examination and, ultimately, appreciation.

Here's what I really left in my wake, having designed SOA systems.

A higher class of coder

How good does a developer have to be to implement an SOA-based system? Damn good; SOA requires an economy and robustness that few other design paradigms call for. Services that meet the standard of excellence required by SOA design demand, to some degree, nonlinear thinkers, developers able to see in more than one direction at once.

No more monolithic assemblies

Remember COBOL programs that had 6,000 lines of code? Maybe you're not that old. All right, then, remember those early .NET programs that contained 30, 40, even 60 references? Remember what it was like to maintain them or, hell, to test them in the first place? Remember how easily they broke and how many evening and weekend hours you had to spend fixing them? That doesn't happen in the SOA world.

XML is now the courier of choice

Okay, whatever you might think of "contracts" or "loose-coupling" as a design concept -- how cool is XML? Hasn't it made all our lives a thousand times easier? Off the top of your head, can't you think of half a dozen ways you use it, and isn't it dirt-simple and effective, every time?

XML is a godsend, and while many architects and developers (myself included) have uttered a few unholy words over it in trying to bend it to our will, it beats by a light-year anything else we've ever had at our disposal for agnostic data transport. That agnosticism is the core requirement of SOA and has been a massive driver of XML's increasing presence and portability in the IT universe to date. I, for one, genuflect.

Developers write reusable code by default!

To write code that can be reused is an art in itself. The code must be abstracted; it must be as functionally self-contained as possible; and it must be written in such a way that changes have easily quantified consequences to its output. I remember a time, not so long ago, when developers changed code and crossed their fingers. That doesn't happen nearly as often in an SOA shop.

Fifteen years ago, the over-hyped technology that dazzled us all was ERP -- which hundreds of companies bought into, only to pay and pay, year in and out, for piddling, incomplete results. It's easy to characterize SOA as its successor, but ERP left us with nothing but piles of unused, overpriced manuals in some back room. SOA may have been over-hyped, but it gave us something much better: it carried us from reptile to mammal and left us well-adapted for the world that's coming.

About

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

12 comments
fdrbelford
fdrbelford

There are many benefits and SOA has taken off in my industry Core Banking applications. Web applications were difficult to get the industry to buy into initially. The Concept of Services Oriented has overcome much of the doubt and most banks if they havent yet embraced the concept of a Web application running their business they certainly have got the message on SOA. Many are defining and setting standards for web services definitions and are have at least embarked on introducing an ESB or the beginnings of one. The big test is yet to come.With no batch and low end of day processing times can an SOA based MVC web application exceed the performance of a main frame in terms of transaction speed, and time to complete the end of day processes. We can already outperform in terms of product to market, integration capability, process modification, workflow etc. We think the performance is also there and we are busy proving it. Our application is already satisfying high transaction demands and we are looking at being able to take on Mainframe Performance with a vengeance. Oh and by the way re-useability has real value when adding complex functionality to existing complex models. Where is the unfullfilled promise?

Tony Hopkinson
Tony Hopkinson

SOA not taking it off like it should have done is the developers fault? Skipping directly over who reccruited their less than stellar talent and why,and who encouraged the hideous dumb down of the discipline and why. We get to. Right what are we going to make a service? I know, how about our heavily customised, tightly coupled, linked to absolutely everything somehow, undocumented, one size fits none, used nowhere else highly visible and extremely expensive to maintain entire oojah system. Doesn't matter how good a concept is, if you let morons manage it.

Justin James
Justin James

Fill in your choice of techs which also made the same promises which didn't come true (or won't come true): * Web services * Object Oriented Programming * Functional Programming * UDDI * PaaS, IaaS They all keep promising the same thing, while ignoring reality. Truth is, "reusability" is a hoax outside of fundamental items (like UI widgets), because the only application that ever needs a piece of business logic is the application that the logic was written for... J.Ja J.Ja

scottrobinson99
scottrobinson99

fdrbelford, your point about the uptake of web apps is well-taken; are you making the argument that it's just a matter of time, where SOA is concerned?

AnsuGisalas
AnsuGisalas

The author wrote from his perspective, but that doesn't mean that his experience invalidates yours, or yours his for that matter. I think there are people around here (probably including the author), who would like to hear more details, if re-usability is more than myth in some niche markets. Would it be possible for you to describe in general terms how you implement re-usability in your business environment? Maybe that can help others to find similar applicabilities in their own areas?

scottrobinson99
scottrobinson99

Didn't mean to imply that developers were the reason SOA hasn't taken off ... from my point of view, it's a matter of marketing hype and not enough time for a new design paradigm to really take hold.

seanferd
seanferd

I meant to add a +. mea culpa

AnsuGisalas
AnsuGisalas

while dangling a carrot perpetually out of reach. That's a well-proven model for getting the ass to where it needs to be - so what if the carrot is plastic? ;)

scottrobinson99
scottrobinson99

AnsuGisalas is correct, I'd have a lot of interest in hearing more details here ...

Tony Hopkinson
Tony Hopkinson

but not the not enough time bit. We had plenty of time to choose the wrong thing to make service, to find out it would be difficult, to desperately wrench and bodge over, around or under those difficulties because there was no resource to it properly. We had enough time to test and try and implement, and decide, maybe not. We had enough time to look at our new service and think this is crap, we'll stick with what we have and not use it. Commercial IT, we've never enough resource to do it right, but loads of time and money to do it wrong.....