Enterprise SOA: cool, sexy and so-o-o doomed!

Enterprise SOA: cool, sexy and so-o-o doomed!

Summary: Services Oriented Architecture is climbing the hype cycle. Amazon's S3 and Elastic Computing Cloud are exemplars of a brave new world of SOA.


Services Oriented Architecture is climbing the hype cycle. Amazon's S3 and Elastic Computing Cloud are exemplars of a brave new world of SOA. Modest success stories are making the rounds. IT folks are getting excited and starting to make promises they won't be able to keep.

This isn't going to end well.

Remember ILM? For several years storage vendors were beating the drum for Information Lifecycle Management. Simply classify data by its value over time to efficiently manage the data and its infrastructure. Who could argue with that? I did (see ILM is Bunk) and now, with SOA, here I go again.

ILM wasn't even a solution in search of a problem. It was a marketing idea spawned by storage vendors desperate to justify their costly and underutilized enterprise storage arrays.

Like ILM, enterprise SOA's business justification is theoretical, not practical Call me a Mammon-worshipping MBA, but there is no way for enterprise IT to monetize the advantages of SOA. Without that, it is game over. Although most people won't realize it for a couple of years.

Let me sketch it out why enterprise SOA is a hard sell:

  • IT services are paid for by taxes, not prices, so users have little incentive to support SOA
  • Since IT can't relate costs to service prices, any SOA cost advantages are buried
  • SOA means uncertain application execution, so users will hate and fear it

Bottom line: don't bet your career on SOA.

The demand side of the equation Enterprise IT is a tax-supported institution. The tax is paid by the Lines of Business or LOBs. The LOBs would like to pay less in taxes, but only if their service levels are unchanged. The chance to save a few bucks isn't compelling.

If IT priced its services it could say to the LOBs "this new architecture is more efficient and will allows us to offer you more and better services at a lower cost. Interested?" Of course!

No way to show a return SOA is about providing services for applications. So how do you measure success? When does enterprise IT start getting cheaper? Or better? Under a taxation-based revenue model, never. Why? Because there is no way to measure success.

You invest in SOA upfront while the payoff waits for other applications to use the service, spreading the cost. Just as Object Oriented Programming failed to make reusable code work, the idea that generic "services" will be reusable is just as unproven. OOP code reuse failed because code contains implicit assumptions that other applications didn't share. Are services really so different?

SOA increases execution variability SOA assumes a data-flow architecture. New inputs drive new outputs. But what happens when a service goes down?

If an application is relying on a dozen independent services whose timing and delivery are dependent on a dozen different infrastructures, that application can only be as fast as the slowest service. At the very least application response time variability will grow. Ask yourself, "do my users want less variability or more?" I think you know the answer.

"They make you feel cool. And hey. I met you. You are not cool." Almost Famous Enterprise IT is not cool. High volume, low variability workloads can't be cool, because there is very little room for the playfulness - bopping iPod users! - that coolness requires. The internet data centers of Google, Amazon and MySpace are cool because they are pushing the computing envelope with radical architectures and clean-sheet designs.

In Amazon's case they are also monetizing a public SOA by selling it. The services are priced so businesses can figure out an ROI. Conversely, enterprise data centers are centrally planned economies like the old Soviet Union. How well did that work? Without prices for their services IT can never align themselves with their customer's needs.

The Storage Bits take SOA is fundamentally about making enterprise IT cool like the web, which is a lost cause. If you really want to change the culture of IT, start competing for LOB dollars. Put very granular prices on IT services. Give lower prices for computes and network bandwidth on nights and weekends. Charge higher prices during the end of quarter crunch. Make users pay more for a Fibre Channel I/O than an iSCSI one. The technology is there and is implementable today.

Prices aren't a perfect method of allocating resources, but they are the most effective tool we've got. SOA isn't the answer, just as ILM, OOP, client server and all the other nostrums peddled through the years weren't either.

Agree or not, let me know in the comments. I'll try to respond.

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • I think you skipped a buzzword, Robin

    In between ILM (thanks for that memory, btw) and SOA there was the brief "web services" phase. You'll still hear "web services" and SOA used interchangeably in some discussions. Sometimes further confused with "software as a service." A lot of the confusion may stem from marketing reps, themselves not aware of the differences, using the term that the customer seems to react to the best. Another one that sets my teeth grinding is "enterprise best practices." Has anyone seen my copy of the Big Book of Best Practices? I seem to have misplaced it.

    That may be why many of my customers are responding very favorably to Google providing enterprise services. Much excitement about Gmail, less about Google Apps and Google Desktop...I'm sensing some confusion there as well...but still a lot of interest. I would describe Gmail as software as a service. That could easily morph into a more SOA type model in the future, but the same questions remain regarding backup and what happens if you can't get to your service provider.

    But I'm not sensing those are deal breakers anymore. Outages happen outside a connected environment, hardware goes bad, operator error...choose your poison. My sense is there's so much relief at being able to offload a large service like email that it overcomes the transition stress and normal desire to keep critical services on a short leash.

    Maybe that's where SOA falls down. It's nebulous. Gmail is concrete. Replace all your email servers. Bang, done. Measurable savings short and long term. Bean counters rejoice, bonuses flow, everybody happy.
    • Isn't that pretty much the point?

      Chad_z, you said: "Maybe that's where SOA falls down. It's nebulous. Gmail is concrete. Replace all your email servers. Bang, done. Measurable savings short and long term. Bean counters rejoice, bonuses flow, everybody happy."

      It seems to me that makes Robin's main point. Outsourcing by any name -- whether it's email or any other aspect of IT -- instantly monetizes whatever was just outsourced. As soon as you monetize it, you can charge the Lines of Business for it based on real prices, measure its performance against its cost and make the bean counters happy.

      It has another perceived advantage; you can negotiate a service level agreement as part of the outsourcing. That also adds to the measurability.

      By the way, as Robin said, the Great Promise of OOP was reusable code. While many languages now are, or claim to be, object oriented, I don't see any great gains in reusable code out there, for the reasons Robin pointed out.

      Oh yeah ... I'm not an MBA. Just a crotchety old IT professional/manager of thirty-plus years.

      another ken
  • "application can only be as fast as the slowest service" - really???

    So what sequence of business processing can be faster in any sequential architecture. There was once OOA (not OOP just like mentioned in the article and BTW it did not fail - everybody uses it but there are different levels and types of reusability - I have been in it for last 15 years and so far sucessfull in quite large corporations). If you know OOA you know what is modelling. There is something about modelling that every business is creating sequences of activities and actions.

    SOA follows business - not the physical implementation (that's bad impression brought by bad IT people who cannot sleep without think of messages on their queues or database connections rather than how business for which they create software works). SOA however makes it clean what contract of business activities are. Tell me in what software in this world you do not have contracts?

    I will tell you where the contracts are blurred: They are not cleane when business cannot or does not want make clean decision what it is reposible for and what are the ways they perfom actions... or there are clumsy IT engineers who cannot focus on model of business and transale it into technical solution? That is frequently associated with excuse of type: "requirements change". Well they do, but what was done for years one way is not probably going to be rvolutionazid in a day so they is not good excuse to avoid modelling analysis and translation into IT concepts. That is where SOA comes handy.

    In other words we do not care to sell SOA appraoch to business - we want to use it to avoid our own hell and organize software in better structure. Business does not care how its "service"is provieded. Well it should not and it better not! This is area of IT. What should count for business is Service Level Agreement meaning how much they can make money out of daily activities regardless of what IT uses. You do not sel SOA just like you do not sell OO Programming (or any programming for that matter) or language or technology. You sell information service. How it is done by IT, SOA or non-SOA is completely out of business scope. If business goes into dthose details than it is same inappropriate as non-professional customer rumbling at technician in local car service about how to tighten bolts on engine.
  • SOA is as Old as the Hills

    From what I can tell data processing, information processing, and all of its other names have had services available since the middly 60's i.e. 1963 and on. The names were not a nice, and the descriptions were not full of praising vernacular. But all the same services were available and we used them in all of our applications.

    We now add interesting terms and make everything sound nice, but SOA does not add much past what we had available in those early years of information processing.

    Time after time new fangled descriptions were added to the information processing vernacular. Time after time these new fangled ideas failed. Why. The answer is simple. We create technologies looking for applications. We choak these technologies in glowing, praising terms. But we have not solve the nucleus of the problem.
  • SOA can work!

    Interesting article. It seems that SOA will have the same success that OOP did, that is, it's going to be pretty successful. Saying that OOP failed is a bit too much (all languages claim to be OO nowadays!). Before SOA succeeds, however, some progress needs to be made. I know SOA and web services are different, but I've noticed many organizations using web services extensively and "doing SOA" without even knowing it! SOA is an overloaded term, it covers a lot of stuff, so in that sense, yes, it may be pie in the sky. But I've seen very effective legacy application integration through web services. I've seen very well implemented orchestration between web services making B2B look like antiquity. The one thing that might kill SOA is XML, but that's a totally different discussion!
  • Perhaps you should do more research...

    I think the author is confused about the meaning of SOA
    and unaware of its long history. SOA is implicit in the
    notion of "architectural layering," and thus goes back at
    least as far as IBM's implementation of System360.

    SOA is also one of the conceptual foundations of the Common
    Object Request Broker Architecture (CORBA), as well as many other frequently-used software frameworks. CORBA is now
    something of a commodity product, and available in Open Source
    distrbutions, but I believe that to this day somewhere
    around 3/4 of the world's telephone calls pass through CORBA-based systems.

    And I'm sure that the fact that SOA is doomed will be a great
    disappointment to the many Fortune 1000 firms who, over the last 15 years, have used SOA implementations to integrate applications and remove stovepipes.

    The author may have been misled by the fact that SOA did not
    become an over-hyped buzzword until the advent of Web Services.
    Now, Web Services constitute a useful arrow in the quiver, but
    they were definitely over-hyped -- to the point where some people today think SOA and Web Services are synonymous. But SOA long preceded Web Services, and while Web Services can indeed be a useful part of SOA, they are not the same thing.

    The author does bring up some good points with respect to the
    problems of paying for an SOA. There are other concerns that devolve from the fact that SOA inarguably crosses an enterprise's internal boundaries.

    But that is really the whole point of SOA -- it is simply a matter of an enterprise's need to optimize globally rather than locally.

    I'm sure many LOBs would prefer good the old days, when they could each indulge their own preferences in hardware, software, middleware, and their own favorite architectural approach.

    But today's C-level executives would have to be howl-at-the-moon insane to let them indulge those preferences.

    • CORBA and SOA...A PR Problem

      You are so right...CORBA, a common SOA architecural implementation for the past 8+ years, has a PR problem. In fact, the Object Management Group (OMG), had to create a PR campaign with the tag line: "CORBA, Middleware, that's Everywhere", and literally show people that the BEST thing about CORBA was that nobody even KNEW it was around. The benefit of SOA isn't an ROI, its meeting the business expectation for flexible, agile systems...something they've always wanted, and we've never delivered...we were too busy maintaining our legacy mainframe monolithic boat anchors.
  • Strong points

    Large numbers of people are using the term "SOA" without knowing at it is. SAP, which has famously followed a closed architecture, all of a sudden wants to open its services to other companies. I mean do they really? I think the stongest points of this article are related to how there is no way for software companies (at least no reasonably simple way) to monetize their SOA services. Certainly a software company would like to leverage other company's services, but why should they make their services open for "exploit?" Nevertheless, the use of the term SOA will continue as there has to be a new paradigm for freshen up presentations. Does everyone remember the term "Java API."
  • Opportunistic SOA: An approach that has worked for our shop

    My reply was too long for this comment, so I have posted it to my blog. See http://geekswithblogs.net/chrisfalter/archive/2007/04/10/111342.aspx if you are interested in seeing how our shop has used and opportunistic approach to SOA with great effectiveness.
  • Responding to all the great comments

    Chad, I have a real problem keeping all the buzzwords straight. There have been so many! Non-techies just tune this stuff out after a few minutes. For the CFO and LOB GMs the issue is simple: show me the money. SOA isn't doing that today so it is a self-limiting trend.

    Ken, ditto, man.

    FirstNLastN - I agree that IT and everybody else shares a tendency to optimize our own piece of work. I've read for years about how IT "should" or "must" align themselves with the LOBs - but without prices there is no way for the LOBs to align themselves with IT either.

    Ptedesco, if everything is SOA then nothing is SOA. It seems to me that much of the excitement around SOA today is the idea that "services" can be provided across an enterprise as opposed to an OS. Great concept, but where is the business justification? There was no justification for PCs either, but millions of people in the LOBs bought,
    networked and applied them until finally IT had to support them. Enterprise SOA doesn't have that kind of support in the LOBs.

    Mchanliau, code reuse was the economic justification for investing in object brokers, the training, and so on. That hasn't panned out IMHO. Object orientation works at the language level, and I think there is promise in other areas, but OOx hasn't been very successful.

    JP, you refer to the long secular trend of turning IT into a commodity as if that is somehow a justification for "irrational exuberance" on SOA. We had dozens of CPU architectures, now we have 2.5? We had hundreds of OS, now we have a half dozen. A dozen network architectures, now, really, one. The fact that we can even consider enterprise SOA is a result of these processes, The cost of integration is dropping as the markets mature and dominant products emerge. But to call this capability SOA is a misnomer. Integration is becoming
    a commodity. SOA is the ability to provide a service rapidly, such as Amazon's S3. Enterprise IT is nowhere near that level of flexibility, nor is it a goal for IT people. The LOBs may want it, but the high volume mindset of IT people is not going there, anymore than it included PCs in 1985.

    MichaelDaugherty, thanks for the update on CORBA. As a marketing guy myself, I always love to watch when techies grapple with marketing. Nice tagline. Yet it is plumbing. There is a specific audience that cares about it and those are the folks they should target, along with some very basic messaging for the folks who approve buying whatever there is to buy.

    Ultra.snapp, I can see SAP's thought-balloon; "if we get a lot of other apps relying on our product we'll be so deep into a company's pants that we can charge anything we want! Bwa-ha-ha-hah!" And maybe they'll acquire the folks who come up something popular. Only the naive would confuse SAP's effort with "openness". It's all about
    making the closed more valuable and thus fending off real openness.

    Thank you all for commenting.

    R Harris
    • I certainly can't argue with [b]that[/b]


      If you ever get around to addressing the points I made, we might continue this discussion. In brief, they were:

      - CORBA is one of many long-lived SOA frameworks; it has
      become ubiquitous, and this fact alone is a refutation of
      your premise. (The irrational exuberance about SOA comes
      from ill-informed industry analysts, not from the long-term
      commoditization trend in IT.)

      - Fortune 1000 firms have been successfully using an SOA
      approach for more than a decade, often to integrate
      enterprise applications, as well as to assemble new apps
      from the business functions that are now sharable.

      - Companies do this because it is a global optimization of
      corporate resources, even though it might result in more
      work and expense at the LOB level.

      SOA is an architectural approach. Sure, software vendors are hyping tools to support it. But that doesn't change the fact that the approach has proven to be very successful.

  • Controversial

    You can see my thoughts in my blog (a bit extensive to put them here), click <a href="http://joshcruz.blogspot.com/2007/04/soa-stir-oats-acknowledge.html">here</a> to see them.
  • My take...

    See my posting ("Opinion: SOA? Another Doomed Concept for the Hype Machines") at www.tech-notes.info for my own take on this subject...
  • OOP code reuse failed? Are you serious?

    Your mention of "OOP code reuse failed because code contains implicit assumptions that other applications didn?t share" is really provocative. It is nice you contradicted yourself in subsequent phrase: "OOP produced lots of libraries that were useful to a single application". More accurate characterization would be "OOP produced few libraries that are very useful to a lot applications". Success stories are: .NET and Java -- their libraries are shared by millions of developers. In fact I would never re-write any code from scratch, rather re-factor/re-use parts of my own/other?s library code over and over again. Despite inaccuracies, it is a great article, and a bold attempt to bust common myths.

    Fakher Halim
    Software Architect
  • Follow the money

    I agree with the observations made by Robin. SOA is not to be considered successful once the service provider is done, it is only when there are sufficient service consumers that a SOA is a success. Sufficient means "so many that the total cost of running the services is less than the cost of re-developing the same service as a project-bound utility time and again".

    All the problems of SOA can be traced to coupling, dependency, and the trust in others (dependability?). Therefore, SOA can be a success only within a 'trust' domain, which usually aligns with the 'budget' domain. So as a rule, consider SOA within your own budget domain, and rely on a more loosely coupled information exchanges with parties outside your trust domain.