The Essense of SOA

Anne Thomas Manes’ recent article proclaiming the death of SOA has started a firestorm across many SOA and IT-related blogs and forums. I wrote about it here. In the post, Anne refers to the severe disillusionment some feel towards the over-hyped term, “SOA”, and proposes we drop the term altogether and simply refer to the core concept as “services”.

The term “SOA” is at the same time ubiquitous and ambiguous. So much energy has gone into molding it into a marketing story that it seems no two people share the same definition.. The truth is, SOA is really just a simple evolution in IT development strategy. I believe the essence of SOA is building software components as “interchangeable parts”, an idea preceding Eli Whitney himself. It is evolutionary (not revolutionary), because we’ve tried to do this for decades, culminating in object oriented and component-based software development. SOA is simply the next stepping stone, which loosens the chains of platform and vendor lock-in, catalyzed by internet and XML-based standards. It’s still about interchangeable parts, components that can be recombined and reused to either build new systems, or rapidly change existing ones. And it’s a superior strategy even if you don’t plan to reuse or recombine, because componentized systems are easier to build, manage, troubleshoot, and support.

In the software industry, I believe we are travelling a similar path as other industries, and finding that interchangeable parts are easy to design in the small, but exponentially more difficult to design in the large. Wiper blades and radios are easily replaced in your car. But I would just love to install a new hybrid-electric engine in my beloved ’96 Jeep Cherokee. Interchangeable parts on such a grand scale are much more problematic. I’m sure there’s marketing mechanics at work here, too. GM wraps their latest electric engine in the Chevy Volt, available next year for $42,000. They don’t want to sell just an engine.

So, I think the term we use to describe the concepts behind SOA is less important than agreeing on the core, underlying essence of SOA. I believe this to be extending the idea of “interchangeable parts”. Personally, I find myself avoiding the term “SOA” more and more, perhaps in a subconscious effort to avoid the pained or befuddled look on those faces in the room. Instead, I gravitate towards the term “service” or “service oriented”. Above all, we need to understand and accept that we are not revolutionaries. We are just carrying forward what others have already set in motion. By communicating this point, we gain credibility in our conversations with business people who control budgets. The alternative is to position this concept as “the next big thing”, something business people seem to immediately distrust.

Extreme Governance?

There was a lot of talk about governance this week at Gartner's Application Architecture, Development & Integration Summit in Las Vegas. What is SOA governance? Simply put, SOA governance defines the policies, procedures and rules of how an organization implements and manages its SOA. Just like we have a development process guiding how we develop core software (XAware uses Agile/Scrum), SOA governance defines the process for SOA development initiatives across the enterprise. Issues to be managed include who can define services, who implements services, permissions for who can access them, on what platform they run, and who pays for development and maintenance.

At the show, I talked with many enterprise users to get reactions to the governance talks. The message from Gartner is clear - Paulo Malinverno stated in one presentation that an SOA with no governance is doomed to failure. But most of the companies I talked to, in trying to implement SOA, are either not implementing governance, or are still struggling with how to do it. I am convinced many others have governance, but are calling it by a different name. The common strategy seems to have a single point of authority, such as an enterprise architecture group, which defines the policies and ensures compliance.

In a conversation with Gartner analyst Roy Shulte, I asked his thoughts on SOA governance. In his view, governance is merely "the workflow in IT". Again, this sounds like nothing more than a process to manage services and other components in the SOA.

Just Enough Governance

Paolo and others caution against too much governance, which might smother and cripple a fledgling SOA initiative. In this respect, I look at agile development processes as the model for appropriate levels of controls. Scrum and XP both value working software over documentation and heavy-handed processes. In fact, I like the term "extreme governance" as a moniker for SOA governance in an agile environment. For developers, the connotation is light-weight, as-needed controls. For the executive who skims over details, the company's "extreme governance" process should win bragging rights in the fight to maintain firm control over the IT rebels. We'll fill him in on the play on words later.

For my part, I would simply recommend to users to stay pragmatic. Services are becoming easy to build, so the number within the enterprise will naturally grow rapidly. The key is understanding that some of the services should become "investment engines" that deserve more oversight to extract meaningful, enterprise-wide value. Services on the edge of an enterprise require more control than services deployed for departmental use. Services with broad use potential within the enterprise should be institutionalized and deployed on enterprise-scale, operationally sound infrastructure. To me, staying pragmatic and applying controls in the proper contexts is the definition of "extreme governance".