An interesting thing to note about this SOA Maturity Model is that it
in reality is a Services Maturity Model - that is it helps a customer
understand the maturity of their Services, but not their architecture.
As an architectural maturity model, the "SOA" Maturity Model falls
woe-fully short. In particular, it doesn't provide any guidance for
building policy-based, process-driven, loosely coupled, governed,
registry-enabled, or any other kind of architecturally-guided Services.
Rather it just helps you figure out if the Service you built is mature
as far as how it is individually built.
As such, the industry needs a different model for measuring how mature
a company's *architecture* is. Those interested in advancing the cause
of SOA should look to advance not only building Services, but building
architecture, and to do so, we have to get past the very vendor-centric
approach of only looking at the technology that people use to build
things and get to the point that we're looking at HOW things are built,
for architecture is not a set of tools - it's a discipline and set of
approaches, and any maturity model needs to look at HOW things are
done, and not the underlying products that people use.
A few cents. Feel free to flame away ;)
Ron
Gervas Douglas wrote:
<<A clear sign that SOA is facing up to the need to deliver
business
results comes in the release this month of the so-called SOA Maturity
Model by a small team of SOA suppliers.
Developed by Sonic Software, Systinet, AmberPoint and BearingPoint,
the Maturity Model is currently touring North America in a seminar
series, and will be released to the public as a white paper on
October 27th.
It's a timely attempt to help people figure out where they are in
their SOA strategies and how to get to the next stage. There's plenty
of evidence around now that enterprises have started adopting web
services and are persuaded of the need for SOA. But there's a lot of
uncertainty about how to move on from there, as well as how to
translate the concept of SOA into tangible business benefits that
will sell the concept to decision makers outside the IT department.
So what are the five layers, and at what stage are the majority of
customers?
Initial Services form the base layer. This is the classic first-level
adoption of point-to-point web services integration as a means of
testing out the technology and starting to understand what it can do.
Architected Services take over when IT decides to get a grip on the
emerging services infrastructure and impose an architectural
framework that offers some consistency and reliability when bringing
services together.
The next layer is segmented into internal-facing Business Services
and external-facing Collaborative Services. This is the point when
SOA breaks out above the IT and applications infrastructure and
becomes visible in the form of service-enabled business processes.
Measured Business Services refers to what happens when the services
created in the previous layer are monitored and analyzed to see how
they and the business processes they power are performing.
Optimized Business Services are the final result of feeding back the
monitoring and analysis of level four to make improvements to the
business services themselves. Rather than an end destination, this
becomes an ongoing continuous cycle.>>
No doubt many of you are involved in this. I like the idea of the
computer industry taking maturity seriously; I have seen many
examples of colleagues going from juvenile egomania to burnout with
out any intervening period of maturity.
Gervas
--
_____________________________________________________________
Ronald Schmelzer
[EMAIL PROTECTED]
Senior Analyst
ZapThink LLC
Direct: 781-577-2779 / Main: 781-207-0203
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
