IBM Hursley, SOA, ESB and Consulting
James Governor, co-founder of RedMonk, dropped me a mail today pointing
at a blog where
he comments on my recent posting
about how Microsoft is doing its best not to blindly jump onto the acronym bandwagon.
James raises several points in his article, namely:
- He appears to be offended by my comment regarding IBM Hursley
- He claims neither that IBM or any other middleware vendor claims to sell a SOA and
considers my stance on SOA to be FUD
- He seems to infer that Microsoft doesn't believe in architecture and does believe
in magic
- James also seems to believe that SOA is really really difficult
Firstly, I want to absolutely crush the thought that my comments are explicitly
aimed at dissing IBM Hursley. IBM Hursley demands great respect - it is the
place where CICS and MQSeries were created and the impact of the work carried out
at Hursley cannot be understated. My comment was meant to be tongue in cheek point
aimed more at IBM's deep technical capabilities and the fact that IBM's latest ESB
offering appears more as a blatant marketing release than a technical innovation
which the nomenclature of
WebSphere Enterprise Service Bus would infer. As a Brit, tongue-in-cheek
commentary is second nature, but it often gets lost in translation ;)
On SOA:
James states that he knows of nobody who claims to "sell a SOA". Interesting.
Whilst there may indeed be few claims that someone will sell you something called
“a SOA” (although there sure used to be a few), there are many instances of vendors
proffering SOA platforms. Let's expand this statement ... a "Service Oriented
Architecture Platform" ... i.e. a platform upon which you build a Service Oriented
Architecture ... huh? How do you build an architecture?
On Architecture:
In my experience, an architecture lays out the relationships between applications,
systems, services and components and is expressed in a manner that is independent
from as many specific technology considerations as possible. The architecture should
define which components, services, etc., need to speak to which other services and
components and what information needs to be exchanged during these conversations.
The architecture lays out the grand scheme of things. Once the architecture is sound
and has been optimized to ensure the removal of unnecessary "chatter", the design
process begins where we translate the abstract architecture into technology-specific
implementation detail, defining what technologies are used for each piece of the
picture. The architecture MUST remain distinct from the design in order to ensure
that the overall concepts, goals and objectives are not lost and to provide a validation
of the eventual design. Once the design is done, coding can begin.
On SOA Platforms:
To this end, what is a Service Oriented Architecture Platform? What is soooo
very different in the architecture, design and implementation of Service Oriented
systems relative to other forms of distributed systems? What is is precisely that
makes Service Oriented systems so very much more complex or harder to build? In
a recent post, I commented
on the notion that Service Orientation does not in and of its self create any new
architectural concepts that we've never seen before. The key thing that Service
Orientation introduces, that is different from how we approach systems design and
implementation today, is that it fundamentally changes the assumptions that we make
when approaching the architecture, design and implementation of a given system.
When we're thinking in a Service Oriented manner, we are far more sceptical and
paranoid. We assume that all services might be running on different platforms, communicating
via insecure and unreliable networks and that the network is relatively constrained.
Just these assumption changes generally result in distinctly different approaches
to the design of a given system.
On ESB Platforms:
The same thing problem is now affecting the term Enterprise Service Bus: Today,
several companies offer an ESB ... or an ESB platform. I can't help but wonder what
happens in 2 years time when ESB is past its sell-by date and gets replaced with
the acronym du jour ... will we see WebSphere ESB being renamed to WebSphere SNMB
(Shiny New Message Bus)? Will SNMB convey any revolutionary new concepts that will
transform how we build systems? Who knows, but I can predict right here and now
that whatever the shiny new thing will be called … customers will be confused.
James also asks "What is traditional ESB?" Good question. What is the traditional
approach to a term that has been in existence for less than 5 years and for which
there is no standard definition? If you believe Tibco, theirs should be considered
the norm. If you believe Sonic, theirs is. IBM of course has their perspective.
But none of these definitions are quite the same. We're straight back to square
one!
Interestingly, in his blog, James
discusses his "Goldilocks meme" and refers to Ronan Bradley as the source
of this analogy. Ronan himself states in his post titled "IBM
and the two tiers of ESB" that "IBM has announced that the ESB is a product as well
as an architecture after all. What’s more it has not one but two ESB products with
which to bewilder potential customers. On one hand is a ‘fully featured’ ESB – which
is a not very subtle rebadging of some existing EAI products. On the other is a
‘lightweight’ ESB – effectively extending their existing Application Server product".
I believe this further vindicates my statements about the meta-issue that the IT
industry is infected with the malaise of coining some apparently new architecturally-related
term or acronym and re-branding yesterday's technology as this shiny new thing.
STOP IT! Unless there is truly something fundamentally revolutionary and useful
to say, don't make something up! Why not just call your new iteration of an existing
thing what it is and stop inflicting customers with FUD that makes it sound like
you've introduced a new thing? And if you DO have something new, clearly delinate
between the concept and the thing. PLEASE?
On Consulting Services:
James then goes on to ask "Who is this 'we'?" I am referring to We as in Microsoft,
our consulting arm Microsoft Consulting Services (MCS) and our partners.
James also states that "Rich's post also relies on the common fallacy that Microsoft
technology installs itself somehow, that problems are solved by magic." I don't
think that anyone in the world believes that their systems are installed nor that
problems are resolved "by magic". What I think James is getting at here is the following
statement from my original post:
We'd much rather work to help understand a custmer's requirements and objectives
and help the customer implement a solution that satisfies all the requirements rather
than try to confuse them to the point that they give up and resignedly hire a legion
of consultants to do for them what they could do for themselves.
To understand this statement, let's consider the different approaches to consulting
that differentiate Microsoft from the likes of IBM, Sun, Oracle, BEA, etc:
IT consulting organizations exist because customers need help navigating the path
of building complex computer systems. Many customers want to concentrate on running
their business rather than building an IT organization – they believe that IT should
be a commodity and don’t want to spend time and effort getting their business computerized.
This is a perspective that consulting organizations the world over have taken advantage
of. The boom in outsourcing in the 90’s is evidence of this. However, as computer
systems and software in particular increases in reliability, simplicity and ease-of-use,
the need for customers to have to rely upon consulting organizations for the mundane
should decrease.
So, what’s the point here? The point is best raised through a question: “which companies
are really committed to simplicity and clarity”?
IBM Global Services is a colossal organization of over 200,000 people that accounts
for almost 50% of IBM's annual revenues ($46.2B of $96.3B in 2004), and is by far
the largest revenue center in all of IBM. IBMGS is a well skilled organization which
is primarily geared to handling long-term depth consulting and outsourcing engagements.
I have had the pleasure of working alongside IBM Global Services consultants on
many an occasion. By and large they’re smart, dedicated intelligent individuals
that are passionate about their work and keen to deliver value to their customers.
The same applies to consultants from Oracle, Sun, BEA and many other consulting
organizations.
But, here’s the rub:
Microsoft’s business model is all about commoditizing what was yesterday’s cutting-edge
technology and making consumers of our products and productive, efficient and empowered
as possible. Microsoft Consulting Services is an organization of around 8500 people
world-wide (around 12% of Microsoft’s global headcount) chartered with one thing
- helping customers get the very best value from Microsoft's software and systems.
When I joined MCS in 2000 after forming and running my own consulting organization
for 5 years, I was surprised at the MCS modus operandi: to engage, to transfer knowledge,
to ensure competency and get out! If necessary, MCS will work with the customer
to engage a skilled partner to provide ongoing assistance.
While IBM and others claim that their platforms and technologies are extraordinarily
powerful and easy-to-use, they’re making extraordinary revenues from their services
divisions. Why? If their products and technologies are so powerful and easy to use,
why do customers need so much assistance? Further, what interest would a company
making around 50% of their annual revenue through services have in making their
products so easy to use that their customers need fewer services? I suggest that
there isn’t a truly b desire within many such companies to truly invest in making
their products and technologies easy to use. I also suggest that many such companies
perpetuate the concerns of some that new == risky and that new == difficult.
Is this approach appears to be why many vendors promote the notion that moving to
Service Orientation is complex and difficult – that it increases services sales?
I believe so.
In my experience, Service Orientation is not any harder than any other architectural
approach. In fact, I would argue that it is far simpler and far easier.
I have seen many customers begin the process of adopting a service-oriented mindset
and reaping the rewards through the simplicity, flexibility and power of the resulting
systems. Some of these customers have achieved this by building interoperable services
on top of Web Services stacks. Some customers have performance requirements that
SOAP/HTTP cannot currently meet and they’ve used proprietary/binary technologies
under the hood … but their systems are architected, designed and implemented in
such a way that migrating over time to something like WCF in the future will be
clean and simple.
Finally:
So, in closing, is Microsoft's position on "SOA" just FUD? I believe very bly
that it is not. We're not just dismissing the notion out of hand - we're aiming
to clarify many misconceptions and industry confusion (and FUD clearly created by
other parties) through consistent messaging and avoidance of pooly overloaded, badly
defined terms and concepts.
It is also important to remember that Service Orientation is evolutionary approach
to systems architecture. SO embodies a different set of assumptions than those that
we’ve held so close for so long and which aims to make explicit what has until now
been implied. SO is about simplicity and clarity and is more than achievable today.
