Take up the gauntlet! (It's Under the Grid Lights…)
In continuation to A Hell of a (SOA) Day, there are two issues I would like to discuss:
The first is related to the WS-*: who said that SOA and web Services are interchangeable? I know of a fabulous SOA realization, linking 250 applications through 300 services with millions of invocations a day – yet nothing in this implementation is prefixed with "WS-". Given that the WS-* standards are work in progress for already so many years, there's a point in questioning if they are doing any good to the SOA cause which, as you could deduct from the case I mentioned, can do pretty well without them.
The second point I'd like to raise concerns the so many pieces of software needed to be purchased and integrated in order to implement Enterprise SOA. Why's no one taking up the gauntlet of providing a single, unified, [service-oriented!] life-cycle SOA management framework? Clearly, this is preventing SOA from being adopted on a strategic, Enterprise-grade level, as you could well see in the previous post.
So first things first: SOA is Web Services? Web Services are SOA?
Let's do a bit of semantics on Service and Architecture (as in Service Oriented Architecture). The idea behind "Service" is that APIs are no longer adequate. In the past, where applications used to run on the same room-size Big Blue, the APIs were everything - channels to the Enterprise Information heart. But nowadays, in the stateless, asynchronous and distributed Enterprise, APIs became intangible, like atoms. We need a higher-level material to build with our cross-applications, cross-companies business processes. Hence, the Service: a Darwinian artifact, evolved from the lower-level, small-sized brain (aka, business-logic) API.
Trickier is the definition of "Architecture", as it depends on the eyes of the beholder. For a programmer, the Service Architecture instructs how to build a service. The first Web Services standards - SOAP & WSDL - changed our lives for good, by enabling any programmer, who's using any language, to create shareable Services.
If you remember, the trio of SOAP and WSDL (with UDDI) riding on XML, were enough to enflame the entire industry; IBM and Microsoft released, in a haste, IDEs that could easily create or consume Services. Web Services became Celebs over night, and Microsoft & IBM couldn't but get euphoric.
There's no doubt, though, that at a certain point in time the Gorillas got sober, having the worst hangover migraine ever; for they realized what a Golem they have created. Once Services were let loose inside an Enterprise, they became overly powerful and highly uncontrollable (see 1 vs. 100891344545564193334812497256, part I (on Enterprise IT, Disorder, QoS & SLA). Services had to be managed, ASAP - but no management framework was out there.
Therefore, when SOA is discussed from the eyes of the Enterprise, Architecture bears different meaning - that of Management. Services, being mini-Enterprises, must be under constant control. Uncontrollable elements cannot be strategically deployed on an Enterprise-grade level.
Here're some random control questions, out of many others:
- Which Services are out there?
- Which depends on which?
- What infrastructures, applistructures and software components are parts of the Service?
- Which is currently available, unavailable, having a problem?
- Who's waiting for a Service completion?
- Who received an error from a Service?
- Who's allowed to invoke which Service? When? Under what context (or policy)
And so forth.
Do pay attention to a simple fact: most of these questions cannot and should not be answered on a single Service context. These questions are Enterprise concerns, and as such they should have their answers by some Enterprise controller. Enterprise SOA should be, therefore, defined as "The architecture for managing Services in an Enterprise context".
From here it is easy: in order to manage you have to have knowledge. The more knowledge you acquire, the more powerful and in control you get. Overall knowledge can be acquired only by following the entire life-cycle of a Service, i.e. from inception to retirement (ownership, requirements, design, coding, implementation, testing, deployment, execution, monitoring, self-healing, problem resolution, retirement).
Still, no company has been taking up the gauntlet of providing a single, unified, life-cycle management framework for Enterprise Services. In the meantime the WS-* committees have been working [for years] on WS standards that have no reference point (i.e. a life-cycle management framework to which they should refer); it seems that every quarter or so someone says: hey, didn't we forget something? And a new committee is launched.
I strongly believe that this state of things prevents SOA from being adopted in the Enterprise, and thus the question of why we don't have such a management framework is most pertinent.
Well, I might have some answers.
Startup: I have discussed the possibility of launching a startup on this matter with a VC named Greylock. "Boiling the ocean" was their answer. And indeed it is. So startups won't do it – it's too big for them and for their bankers.
I have discussed the life-cycle management approach with the VP R&D of a major international software company. "Oh, no", he said. "We cannot compete with IBM, Microsoft and SAP – these are the SOA execution platform vendors". I didn't have enough time to tell him that not even one of the companies mentioned has an SOA execution platform following the Enterprise requirements.
Well, if neither startups nor big ISVs can take this challenge, why don't we see such a product from IBM or Microsoft? Are they really waiting for the WS-* standards to be completed? Or did they climb up too high on the WS tree?
Actually, I think we will have such a solution soon enough; but surprisingly (or not), it will not come from the applistructures vendors but rather from the infrastructure vendors. More precisely I believe that Grid Management Frameworks will provide the missing piece of SOA management and will allow strategic, Enterprise-grade SOA deployments,. The arguments behind this statement deserve their own post, but I'll, nevertheless, mention some now:
The GRID has tasked itself with the management of virtual and distributed resources. Indeed, the very first idea was to manage infrastructure resources. Yet soon enough someone at the grid community figured out that (Web) Services are nothing but virtual, distributed resources and that therefore they can be treated as GRID components.
My second argument is that the Enterprise Grid Alliance (EGA) has well learnt the lessons of the bitter SOA failure, i.e. that managing virtual, distributed resources requires life-cycle approach. I am recommending, again, the EGA reference architecture; it could be well used as the missing reference architecture for SOA (and OASIS could well save 3-4 committees here...).
My third and last argument is based on the sayings of John Chambers, Cisco. I heard Cisco's GRID program manager speaking about Cisco's view of the world. In two words: "Intelligent Network". In a simplified nutshell, GRID, SOA and Semantic Web will be part of a Cisco's Router. And here's how John Chambers indirectly justifies this Intelligent Network vision:
“It's going too fast and (getting) too complex, and it's getting harder and harder to get our arms around it. You can't approach this problem with pinpoint products that IT professionals have to integrate”.
John Chambers, CISCO, RSA Keynote, Feb 2005