Wednesday, February 22, 2006

Meant for Each Other: Enterprise Architecture and SOA

Enterprise Architecture is an infrastructure and a set of Machines constructed in order to manage a chaotic, dynamic, unpredictable, complex, organic, prone to error, frustrating, Enterprise IT, which has to support an ever increasing, dynamic portfolio of products and services, through constant "ASAP, Now, Right-Away" modifications of business processes.

That is a formulation of my practical experience, as described in The Rise of the Machines: A new Approach to Enterprise Architecture. The outcome of an Enterprise Architecture is a Management Framework upon which, or rather, inside which, the Enterprise lives; physically.

Yet, if you consider the usual approach to Enterprise Architecture, you'd normally find committees, standards, governance, and smart people being in the confirmation pipe of business and technological initiatives.

Under this paradigm, the success of an EA Office is measured by the popularity of its staff members and of its guidelines and procedures. And see this Extended Enterprise Architecture Maturity Model to have an idea of what I mean.

Nevertheless, some recently published articles (see References) started a discussion around the differences and the similarities that exist between Enterprise Service-Oriented Architecture and Enterprise Architecture.

I believe these thoughts will finally change the perception of both EA and SOA: EA will shake off its image as a "documentation, procedures and guidelines" body, repositioning itself as a practical, implementation-oriented discipline aimed at the creation of an Enterprise Management Infrastructure, while SOA will be repositioned, no longer as an Integration/Interoperability architecture, but rather as an Enterprise Management architecture.

That being said, it's no wonder that hardly a week goes by without an industry expert maintaining another piece is missing in the current SOA offerings (which are still integration-oriented). Recently in the Lost & Found section one could find Registries/Repositories, Information Management, Events, Semantics & Ontologies and so forth.

But for "SOA as the ultimate foundation for Enerprise Management" – an approach I've been practicing for years now - there's nothing new in all these experts' discoveries. One cannot manage without knowing what the managed objects are, including their inter-relations (=repository/cmdb). To manage heterogeneous and distributed objects, an agreement must exist on the managerial language (ontology) and its different, contextual semantics (policies); the manager should make its decisions based on pre-defined rules (Business Rules Engines, policies) and if a real-time managerial response is required, it must be listening to events (event-based).

There are, clearly, other infrastructures and machines to add to this picture. For instance, grid/utility computing is an essential part in the real-time Enterprise, for the Manager has to dynamically allocate and decommission resources (any kind of resource: human, software, hardware) as the need arise. Don't be surprised than to find, any day now, grid in the SOA lost & found – it is a natural progress for SOA in its way to become an Enterprise Architecture.

I would like, therefore, to proceed from the EA/SOA convergence point and propose a new acid test - a simple requirement, that if met, we can mark √ on our Enterprise Architecture (as an Infrastructure and a set of machines :) ) endeavor. That will be the subject of my next post.

The sequel to this post is An Acid Test for Enterprise Architecture


Koch's IT Strategy: Enterprise Architecture vs. SOA: Pick the Winner
Real World SOA: Is SOA a Part of Enterprise Architecture, or Does it Replace it?


By Anonymous Shahar Kaminitz, at 3:53 PM  

Muli - Just discovered your blog and it's great. Looking forward to the next post, when the acid test is unveiled...

By Blogger Robert McIlree, at 4:48 PM  

Muli - Excellent post and EA definition. I added your definition to my soon-to-be-expanded list of EA definitions...:)

By Blogger scott, at 4:26 PM  

Great summary, and interesting thoughts on the evolution of EA - help keep it moving away from it's ceremonial past...

By Blogger François Tricot, at 4:07 PM  

Great Blog. I like your article about social pressure.

You said 'there is nothing new'. Every time I present S.O.A. to architects they say that there is nothing new and that they never have done their job differently. At the end of the day, why are current EA so complex, not flexible at all ?

I think that there is something new with Web Services & SOA : the same standard worldwide, and the benefits are much more important than a service oriented approach. This lead to the same revolution as the Internet. S.O.A standardize machine to machine interactions the same way HTML standardize man to machine interaction.
It has never been done before.

By Blogger Muli Koppel, at 7:17 PM  

Shahar, Scott, François: Thanks for dropping by. Robert, Dan and Aurélien, you're "returning customers" already :), so double thanks here for your company.

François, as to your comment: assuming that by "standards" you referred to WS-* (and not to REST, POX, RSS… which all assist in the machine-to-machine interactions), I do not share your enthusiasm… it's too complex for me. Still, I do think that the idea behind "Web Services" is fabulous and that together with XML (this time not as an idea, but rather as a concrete, working standard) they are as dramatic in their contribution to our life as HTML was. As for the WS-* - well, I have written in this blog some detailed posts about their angst.

By Blogger François Tricot, at 1:47 PM  

I share your opinion. By "standards", I referred to HTTP, XHTML, CSS (real standards widely deployed), so REST/RSS.
WS-* are more software vendors standards rather than real standards. Let's read my comment with this in mind and I think we share the same enthusiasm.
The fact is that software vendors quickly understood that to continue to sell their infrastructure products, they had to add 'standard' and 'open' on the boxes...
Neither let someone say that Web Services = SOAP. Web Services are XML over HTTP calls. :-)

Post a Comment

Sunday, February 19, 2006


OK. I am abandoning the direct injection, highly-limited version of my Podlinks feed and open an annexed blog, Technopod. I warmly invite you to visit me there as well.

I decided to migrate from the direct injection feed into a separate blog, after receiving some mails from Juice users who subscribed to the feed and expected to have the podcasts automatically downloaded to their laptops. The direct injection podlinks feed was limited in that sense. Also, as I said, the blogging platform allows me to elaborate with references, technorati searches, details on the people mentioned and more. As always, your comments are welcomed.

Those who already subscribed to the old feed (Muli Koppel's Podlinks), please re-subscribe to the new one (Technopod) – see side bar.

That's it. Back to the old business soon (concluding the endless saga on SOA, Web2.0 and the Future of Telecom), and hopefully, no more podcasting stuff on this blog.


Post a Comment

Thursday, February 16, 2006

A Human Filter: My New (startup, the) Podlinks Feed

I have created a sub-feed named Muli Koppel's Podlinks to which you can subscribe here:

There's no site behind this feed - I will inject the Information directly to the river...
The post content will be standard-enabled, i.e. incredibly simple: a URL to the podcast, a short post-listening commentary/description and my personal rating. I added my last 10 Podlinks to this blog sidebar, so you could have an idea how the feed looks like.

This Podlinks idea popped-up after I figured out that the following conversation repeats itslef too often:

Colleague/Friend: What do you think about "X"?
Me: You know what, I heard John Doe (2.0) talking about "X" just two days ago, and he said...blah blah blah…
Colleague/Friend: Cool! Skype me the link to the podcast, ok?
Me: Sure, sure.

So, instead of searching, cutting, pasting and sending links to my friends, I decided to stream my post-pod impressions to them, and to whom else it may concern.

Also, I was listening recently :) to three podcasts about RSS, and tech.memeorandum - an RSS aggregator/filter - was mentioned over and over again. Undoubtedly, there's an urgent need for aggro-filters, and authority-based, FoaF (Friends of a friend) and other social filtering techniques will soon change the way we peep into the endless flow of Information.

So here I am, a human filter, releasing the knowledge I have about the podcasts I've heard, adding some commentary and a rating. Until, of course, my automated, social, web2.0 Podlinks startup will launch its beta version.


p.s. It's a trial. I might turn this Podlinks feed into a formal (seperated) blog for two reasons:
a. give more information and links on the subject
b. allow other readers to post their own post-listening impressions on the same podcast.

I would love to have your feedback.


Post a Comment

Friday, February 10, 2006

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.

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.

The Manager

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.

His Repository

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


By Anonymous Yodke, at 9:06 PM  

There will be one solution to all only when we'll reach Marx/Lenin's Highest Stage of Capitalism. That is, one gigantic capitalist company will rule the entire IT world. Until then, its all about different vendors, and different vendors (toolsmiths) integration is about standards. And as you so beatifuly show: standards are never what they claim to be. Hence, no one solution for you. Which is good, BTW, life is more interesting this way.

By Blogger Muli Koppel, at 9:13 AM  

Hi Yodke,

Thanks for your comment.

Just to make myself clearer – there's nothing in my sayings that suggests that One Vendor will rule them all. Gosh – just not that. What I am suggesting is a Top-down architecture, that has three layers: One Manager, One Shared Information Layer (providing the Manager with the decoupling it needs from the Tools), and lastly as many Tools as needed. The Manager, the Information Layer and the Tools could come from as many different vendors as you'd like. And to that I add two, implicit, sort of guidelines: the Enterprise SOA project should start with the Manager – not with the Tools; and that Enterprises would be thankful having a Manager, an Information Layer and Tools pre-integrated from the Manager's vendor.


By Anonymous Aurélien, at 6:23 PM  

Muli, stop posting such brilliant post.

You're going to kill the toolsmiths! The bottom-up approach is a much better way to lock-in the customer.

By Anonymous Aurélien, at 6:39 PM  

This post reminds me of your Mind the gap post were you explain how and why architecture is superior to technology.

Here Management-by-Information is a functional architecture approach and the tools are just technologies.

Post a Comment

Wednesday, February 01, 2006

The Death and Life of UDDI, Part II

This is a sequel to You Only Live Twice - The Death and Life of UDDI.

On mid December last year, I met a colleague from Mercury Interactive who was part of the Systinet acquisition process. "Did you hear?" I told him with a large "told you so" smile on my face, "UDDI is dead!" Several hours later we met again and he tried to explain: "that's just the Internet UDDI. Inside the Enterprise everything's still on track". And my reaction was: "Yeah, sure…"

At that time, Mercury went through its worst moments as a company. I assume that some Mercury executives thought that an acquisition at this stage, when the future was unclear, was not a wise move. Undoubtedly, other executives maintained that the Systinet deal should happen, in any case – as Mercury desperately needed some big positive headlines to stop the stock from crashing and to communicate that business is as usual.

This was the moment that IBM, Microsoft and SAP chose to step in and announce the UDDI Business Registry shutdown. It was too good a moment to miss, and here are my assumptions as for the reasons behind the move:

1. SOA Management Leadership

The UDDI market shifted recently from an inventory of services to a disruptive and innovative SOA management infrastructure. This disruption mostly impacts IBM, Microsoft, SAP and other major SOA platforms providers, such as Oracle (as for why it's a disruptive concept see The Toolsmiths, The Manager, His Repository and Its UDDI Lover).

By announcing that UDDI is no longer operative, IBM et al. launched a low-intensity combat against the UDDI vendors (Systinet, Infravio and others). I can assume that my reaction to the excuses given by my Mercury friend was as skeptical as those given by other potential customers of the UDDI vendors (and see Dave Linthicum's reaction, titled "UDDI is a Dead Parrot").

2. Hitting Mercury

We can assume that the M&A teams of IBM et al. knew that a deal was shaping up between Mercury and Systinet. Shutting down UDDI and consequently putting a question mark on the approaching deal would be killing two birds with one stone – the UDDI-based Enterprise SOA Management market and... Mercury – which desperately needed positive and impressive headlines (as the payment of 105M$ cash(!) to Systinet proves). I don't find these news headlines now, but I remember that at the time there were several rumors claiming Mercury itself might become a target for an acquisition if its stock prices keep on dropping.

If Mercury wouldn't have acquired Systinet these rumors could well possibly come true.But Mercury did acquire Systinet and thus the two birds (Mercury and the UDDI market) of our story were not only saved but also regained their power.

All the above is naturally a sheer speculation on my part and I wouldn't have bothered writing about it, unless I was intrigued by the dynamics around the nascent SOA Management market, based on UDDI. It is surely going to be an interesting play.

This is the second 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)


Post a Comment