The Toolsmiths, The Manager, His Repository and Its UDDI Lover
This time I will explain why the ex-UDDI Registries, re-branded as SOA Governance solutions, have a disruptive potential to the SOA Management Market. This new Governance category might be on its way to realize Stephan Haeckel's Management-by-Wire concept, or in more conventional words: Management-by-Information. It is a Top-down approach to Management (and actually, the only reasonable one) focusing on Processes and Information, rather than on an endless collection of Tools - a Bottom-up approach, promoted by the Toolsmiths.
For decades now, the World of Tools has been dominating the IT sphere. Every Enterprise Class, be it a Requirement, a Test scenario, a Database, a Server, or an Application, has a set of specialized tools that together are (hopefully) covering the Life-cycle of that Class. A database, for instance, is created with one tool, monitored with another and backed up with yet a third one. An application is developed, tested, packaged, monitored and backed up by a whole set of different tools, most probably from different vendors.
No wonder, than, that Enterprise IT, consisting of hundreds if not thousands of Classes, is flooded with Tools.
"So?" One could argue, "This reality is inevitable and most probably highly logical. We're living in an era where specialization is necessary. Renaissance scholars no longer exist! We can not have few generic tools , let alone One generic tool, that will deal with every Enterprise Class. A Router, after all, is not a Database!"
This is true if we ignore Management and concentrate on Execution. But just in case Management is somewhat relevant to the well-being of your Enterprise, well, here this post-Renaissance truism loses weight, and the reverse is what, one day, will become true.
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them.
Unlike Execution, which lives on Tools, Management lives on Information; more precisely - on a constantly updated and fresh flow of Information. Only, in the World of Tools there's no Information flow. Each tool is built with an ego-centric view of the world: "L'État, c'est moi!" The Information is born, lives and dies inside the Tool. It's therefore the onus of the Manager to create the Information flow by consolidating the distributed Information from the different, "ego-centric", Tools. And only after the Information has been consolidated, filtered and enriched, that the Manager can start its analysis and decide how to react to the event that - once upon a time -required its attention.
In a real-time Enterprise, this state of things is no longer valid, for the Manager has to respond to that event in "no time". And standing on the shoulders of a giant, I will demonstrate the importance of fast managerial responses by quoting the Chuck Norris Facts' site: "If you can see Chuck Norris, he can see you. If you can't see Chuck Norris, you may be only seconds away from death".
The World of Tools is placing too many challenges on our Manager: if a Tool is not available – critical Information is inaccessible; if a Tool is not performing – the Manager will be late in its "no time" decision; if the Information is too distributed – the sheer access to all of the Tools will make the Manager missing its tea party. All these problems, and we didn't even start to discuss the hassles expected from the Integration project, in which the Manager will eventually gain constant access to the Information distributed across all those Tools.
In other words, Management in a Real-Time Enterprise must be decoupled from the underlying World of Tools.
The Real-Time Enterprise is similar to the Web (as a real-time Platform for doing real-time actions). What we see with RSS is a similar pattern - The Manager can no longer access each Tool/Site, and so the site is constantly adding its Information to the external RSS Information flow. I suppose that in the near future a site keeping Information to itself without sharing it (via RSS) will be black-listed, as Information unlocking will be considered essential to the normal, healthy functioning of the Web.
Stephan Haeckel, an ex-IBM Director of Advanced Market Development and Director of Strategic Studies, is the "Father" of the "Adaptive Enterprise" and the "Sense-And-Respond" paradigm. All the concepts of agility, flexibility, Enterprise Architecture, SOA and even Utility Computing stemmed from his work, beautifully aggregated into the now classic book from 1999 "The Adaptive Enterprise: Creating and Leading Sense and Respond Organizations".
In 1993 Haeckel coined the term "Management-by-Wire" as an analogy to the aviation "Flying-by-Wire", which means "flying an aircraft by controlling an information representation of the aircraft through the use of heads-up displays and electronic controls".
"Managing by wire is the capacity to run a business by managing its informational representation".
This is a million-dollar assertion. Management in a Real-Time Enterprise should focus not on the managed objects but rather on their Informational Representation.
"Coherent corporate behavior needs more than blockbuster applications and network connections; it must be governed by a coherent information model that codifies "how we do things around here," and "how we change how we do things around here.""
Well, here's my interpretation: The Management Requirements are manifested in two layers - the Management Processes and the Information Model. The Informational Representations of the Managed Objects are stored in the Management Information Model, which is CRUDed by the Management Processes.
You'll find all these ideas in my previous posts on SOA as a Management & Control foundation (SOA, Matrix and In SOA We Trust) .
The Management-by-Wire (or rather Management-by-Information) approach is Tool agnostic. Information does not only have precedence over Tools, it masks them altogether. If previously the Toolsmiths could sell a dozen Tools, with a feeble promise that Management will pop out somehow from their pre-integrated products' family, now, with the new SOA Governance approach, one can start with Management (Processes & Information Model) and later on pick the Tools that fit in. Whatever Tool, from whatever Toolsmith.
Here's a diagram worth a thousand words.
“The Role of Web Services Registries in Service Oriented Architectures,” Anne Thomas Manes, Burton Group, November 2, 2004.
Picture extracted from Miko Matsumura's Intentional SOA white Paper.
Registry, Repository, CMDB –it really doesn't matter how you call it; what matters is what it means. This is an unusual diagram, placing some kind of a Shared Information Repository in the center of the Universe. Based on its links, it is clear that this Registry holds the entire life-cycle Information, from design-time to execution, operations and post-mortem. Who's behind the application boxes - IBM, Microsoft, SAP? Suddenly it no longer matters. Any "box" providing the required Information will do.
Information got its Renaissance.
and its UDDI Lover
Once upon a time, say 6-7 years ago, there was a dream of the Web as a Platform("Coming soon: The biggest platform ever", David Chapppel, Jan 2001). Those who fantasized about this were "practical" and Execution-oriented: they wanted to do things and thought about the Tools that will realize their dream. So they invented a concept of a Web Service and three standards: WSDL to describe it; SOAP to invoke it and UDDI to store all the WSDLs of the World. They didn't think Management – after all, they were Toolsmiths and the Web was known to be a self-managed platform…
But the vision was not catching up as expected, so the Toolsmiths that already began implementing all sort of Tools to this brand new world, thought it would be wise to port this vision into a much more profitable place - the Enterprise.
Problem was that unlike the Web - the Enterprise is a Managed place. The 3 Web Services standards, as cute as they were, promoted point-to-point integration, or at least an unmanaged one. As the basic communication happens between a Service Provider and a Service Consumer, there's no one out there to manage (i.e. authorize, prioritize, log, handle exceptions etc.) that communication. Briefly, that's an unmanaged context, and therefore a "no go" in any reasonably architected Enterprise.
The UDDI vendors were stuck: no one needed just a repository. Think about it: when you buy a Customer Management System - do you need to buy a separate customer database, or do you get a Repository that holds all the customers' information as part of the solution?
That was my reaction to UDDI at the time - I expected the SOA Management vendors to come up with a repository of Services as part of their Management solution, as never before was I asked to buy an Information model and a database seperately from the COTS package.
The surprising thing - as I mentioned several times in the past - was that no one vendor was offering a SOA Management System that will cover the entire life-cycle of Services in an Enterprise. I believe the UDDI vendors understood that this lack is their new chance and then decided on promoting the unusable UDDI as the Information Repository of the SOA Management solution. The Information Model was extended to contain Policies, Security, SLA, Performance Data etc. etc. and next thing you know - Management Processes, branded as Governance, were provided on top of this extended Information Model.
That was a wise move. The ex-UDDI vendors were not competing with the Toolsmiths, they were complementing them. Thus, Enterprises could still buy from IBM (for "Fear Is A Best Man's Friend"), while adding a Management Layer on top.
I believe, though, that sooner or later, SOA Governance vendors will provide a pre-integrated set of Tools along with the Information Repository and the Management Processes, as Enterprises are yearning for an end-to-end SOA solution.
Yes - One solution to rule them all.
This is the last post in the UDDI series: You Only Live Twice - The Death and Life of UDDI, The Death and Life of UDDI, Part II, The Toolsmiths, The Manager, His Repository and Its UDDI Lover