Jan 122010

I was recently involved in a debate with my colleagues on the Cutter Business Technology Council about whether SOA has reached a tipping point. I do not believe that such a point has been reached. SOA isn’t a product, technology, or service. It is just a body of useful techniques for designing shareable, reusable, interoperable Web services. Perhaps the acronym should really be “GSA” or “good software architecture,” as the “debate” is really about the challenge and promise of good software architecture. The term “SOA” has become very confusing and possesses all the clarity of Web 2.0 (another term that drives me to distraction). Successful SOA is really about rearchitecting the application landscape and, as such, represents a massive shift in how most organizations work and think. It is much more than building service interfaces to existing applications; SOA requires a redesign of the application portfolio. It is not about adding layers of service-oriented integration, which mostly makes the landscape more complicated. Layering up services is not a replacement for good software architecture. At the end of the day, SOA is about the merits of GSA.

I travel quite a bit and work with many development organizations. My anecdotal assessment is that many are struggling under the weight of large legacy application portfolios, batch feeds, middleware, and spaghetti architectures. The presence of a useful solution to a problem may not guarantee its adoption. I recall a terrific cartoon from some years back that featured a medieval king preparing for battle as he rejects the efforts of a Gatling gun salesperson to help him achieve victory. (I was hoping to include the image here but couldn’t find it on the Web.) Though SOA has great promise and represents much progress over OO, much of the development community is battling with complicated portfolios, high maintenance cost, insufficient staffing, deficient SDLC frameworks, and other quotidian issues. Oddly, by exploiting SOA, an inspired and disciplined IT leader could more effectively tackle the challenges that these very factors create. However, for many organizations, the opportunity to harness SOA or even explore SOA may not exist at the moment. Business partners are uninterested in funding more technology panaceas during these challenging financial times, and IT shops haven’t the time or, in some cases, the skills to recognize/exploit the inherent power of SOA.

Though it saddens me to say it, I do not see the development discipline having reached the tipping point on GSA. If you are really doing architecture, then you have analyzed your existing applications architecture and determined why your portfolio of applications and data warehouses has so many redundant and overlapping elements. And then you build a business case to simplify the mess (hint: use SOA principles). Find the customer master, supplier master, and product master across the plethora of COTS applications and their bespoke cousins. One look at the application landscape within contemporary enterprises tells you that the tipping point remains beyond the next hill.

Good software architecture is a concept that has been and continues to be overdue. Like good design, GSA is difficult to achieve. How many of us have been frustrated by bad bottle openers and quirky corkscrews, let alone challenges associated with software interoperability? We know good design when we interact with it, but most efforts fall far short of the satisfaction you get when you pick up an Oxo Good Grips vegetable peeler, use a Swiss Army knife, pour water from an Alessi kettle, or place a Post-it Note on a colleague’s desk.


Ron Blitstein

Ron Blitstein was Director of the Cutter Business Technology Strategies Practice and a member of the Cutter Business Technology Council. His 25-year career includes extensive international operations experience and spans all aspects of information management.


  4 Responses to “It’s About “Good Software Architecture” not “SOA””

  1. avatar


    You said a lot of good things in this article. I like the term GSA and the theme behind it. The definition that you gave for SOA is simple and catches the meat of the Paradigm except the term Web services instead services. The other thing that I do not agree about SOA is it is not just designing shareable, reusable and interoperable services. My understanding is that SOA does include the identification of these services with in an enterprise or across enterprises, which is really the most challenging part of all. Could you please share your thoughts on service identification?

  2. avatar

    Hi Ron,

    I agree with you on the demerits of getting stuck with SOA as a concept. I also support the view that a solution architecture cannot be assumed as perfect just because it is designed around web-based services. SOA may perhaps have reached a tipping point in terms of usage (or in fact, abuse) of the term in all the wrong places. I have seen a couple of companies abusing this term to market their IT products bundled with expert services as service-oriented solution.

    Moreover, while it’s true that a more precise nomenclature (such as GSA) would do us good, we will also need to have a consensus on its precise definition. The industry has to agree upon the benchmarks that makes a good software architecture.

  3. Hi Ron,
    I’m a long time software developer/architect who has just recently jumped up from the trenches into Enterprise Architecture. It took me a while to understand SOA as a concept. Then one day, I stepped back and understood. SOA is nothing more than software development best-practices applied at the macro scale, to an enterprise full of applications.

    Consider a single application. You would never design an application…

    …that required the user to have multiple accounts.
    …that required the user to move data from one part to another manually.
    …that required the user to manually trigger an event across application modules.

    You wouldn’t do those things, not just because it would make for a unwieldy application, but because when developing a single application, you don’t need to do those things. Software developers have all sorts of tools to send messages from object to object, across the network even, without much work. So software developers don’t even think about communicating across modules or sub-systems because they usually just need to make a method call to a library and bam, data moves.

    Now with the advent of web services (and more importantly, good working web service standards…) it is becoming easier to move data around between applications. Now enterprise architects need to start thinking like software developers, to learn those fundamental best-practices that have been used by software developers for decades. The enterprise will soon become a large and organic collection of applications, with data moving as easily and readily as it does in a single application.

    So my advice to enterprise architects? Start thinking like a software developer. If I’m looking for a library to use when developing an application, I’m pretty sure I would stay away from a library that would require the user to login to separately and copy data manually. So don’t purchase a piece of software for your enterprise unless it has standardized hooks, ports, buses, etc.

    That email server doesn’t support IMAP? How then will you pull email into your portal? Skip it…

    That accounting tool doesn’t have a web services interface? How then will you connect it to your invoicing system? Skip it…

    That invoicing system doesn’t support SAML? How will you connect it to your authentication service? Skip it…

    No standardized interfaces? Skip it… save your money. Put your money into the companies that create applications that meld into your enterprise, not ones that live on an island or only work with other products from the same vendor. It’s really that simple…

    As a methodology, SOA is just the completion of a great circle. The best part about a mainframe and monolithic application is that everything is in one place, right there, easily accessible. From the users perspective, that is the ideal model. From the developer’s and systems architects perspective, it stunk.

    So the developers invented OO to break apart their applications and the systems architects broke apart their enterprises so they could pick and choose best of breed applications. Users lost out and have been miserable ever sense.

    Now with SOA everyone can be happy, at least for a while. Developers get fine grained modularity with easy access to external systems through standardized interfaces. Systems architects get a modular infrastructure, with the ability to choose solutions across vendors. User will be happy once again, when everything they need to do is back where it was originally, in one place. At least from their perspective.

  4. avatar

    Ron, good article and I agree that the focus should be and always has been GSA. I do want to comment on one point in your article. Specifically;

    “Business partners are uninterested in funding more technology panaceas during these challenging financial times…”

    Business partners are interested in investing in things like;

    – Legacy risk mitigation
    – IT agility where it improves responsiveness to business change
    – Operational efficiency
    – Information, not just data where it helps the business sense and react.
    – Reinforcing the company’s brand through a first rate web experience.

    We keep the acronyms to ourselves and sell the business value of GSA to our business partners
    — DJL

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>