2006 was the year of SOA governance and 2007 is the point when SOA gets owned by the business. That was supposed to be the take-home from IBM’s Impact SOA conference this year.
All right, what do you expect? It’s a marketing message, and of course, there’s still plenty of SOA governance left to do. But as time and technology moves on, IBM says it’s time to get the business driving SOA.
Let’s clarify that. A business analyst is not going to ask for a services-oriented architecture, they are going to ask for a solution to a B2B integration, a partner management, or sales force automation bottleneck. But if you listen to IBM, the solutions may in fact be based on SOA. But please don’t call them applications – hold that thought for a moment.
IBM’s betting on that the business will drive SOA is based on several assumptions. First, that services can more effectively align the things that software does with what the business actually needs. The flexibility of loosely-coupled services that can be orchestrated or blended into a composite app means that IT should be better able to keep pace with the business’s changing needs.
Second, and more importantly, IBM is betting that the balance of power in deciding which projects get done, and how they will be done, is shifting over to the business. They pointed to the emergence of a pivotal new role, the business architect, with deep domain expertise plus tech savvy, who would help steer technology decisions, plus the fact that more lines of business are formally or informally beefing up their IT expertise.
Yet, at this point IBM’s message gets a bit confusing. They say that the line of business is driving more of the technology decision, yet they also maintain that the most successful SOA initiatives occur when you have a strong IT group whose enterprise architecture role is more than advisory. That leaves us with a bit of a riddle, and for technology providers like IBM, a need to sort out to whom they actually sell SOA.
Let’s get beyond the who buys SOA to what they will be buying. IBM says the key to successful SOA is to verticalize it. That is, don’t make it a raw technology buy where the IT organization must construct the services from scratch, but one that has frameworks that spell out the core services, templates for building or assembling those services … or more.
So IBM is gradually rolling out vertical service content, starting with frameworks that specify generic business processes, component business models spelling them out, so-called “content packs” coming from its Webify acquisition (the product is now called WebSphere Business Services Fabric), plus more targeted content that would be developed by its Global Business services (GBS) consulting group (the operation that IBM acquired from PwC).
Of course, those of us in the room hearing this had a field day bombarding the poor GBS guy on why this isn’t a new breed of software application. Two things to remember: first, customers embraced packaged enterprise apps back in the 80s and 90s because they didn’t want to write yet another homegrown accounting system. And second, that IBM declared a decade ago that it was no longer in the apps business – it would instead help customers implement or run their apps.
Now, in GBS’s defense, none of this is terribly new. Integrators have always sought to build frameworks – and promote the fact that they have them – to convey the message that customers can get ready-made solutions configured to their needs much faster than if every effort were from scratch.
GBS says it’s a consulting firm, but when you look at the history of software vendors, many of them started out as consulting firms who productized a solution that they had developed for a particular client. In GBS’s case, the business model would be turning that over to Webify.
Ratcheting up the argument, there’s a great difference between CORBA components (or C++ libraries) that make the service-based frameworks that GBS and IBM are developing look more like apps. It comes down to the fact that, if implemented as web services, they can be far more readily cobbled into whatever you want them to be, and in all likelihood, are likely to be much higher level software assets than what the older, less connectable component technologies provided. So when you look at that claims processing service that GBS is proposing (atop Webify), at what point does this become a claims application?
There’s more to this issue than plain semantics.
Maybe IBM is targeting virgin territory not covered by the SAPs or Oracles of the world – there are certainly many sectors that never bought into ERP. But even in ERP territory, there’s plenty of waterfront real estate still available. And that’s where things get interesting.
Take the example of a BPO (business process outsourcing) provider that performs claims administration for multiple insurance companies. It uses SAP for accounting, but relies on an IBM SOA framework for claims processing. Then the company wants to expose a payment service to its insurance clients that consumes functionality from the IBM and SAP sides. With that functionality residing in the middle tier, it sets up an interesting showdown that in the end will dictate whether IBM sells more WebSphere or SAP sells NetWeaver. Keeping in mind the fact that most of the growth in the ERP space is occurring at the edges, where you extend the ERP system, this is where the next battle for dominance of the enterprise market will be fought.