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.