There’s a webinar happening TOMORROW, 11/1 at
11:00am ET that explains the Sonic/Systinet/Amberpoint/BearingPoint SOA
Maturity Model. You can still register at – www.sonicsoftware.com/soamm
There you’ll find an overview of the SOAMM, links to
the webinar registration page, and a whitepaper that explains it in more
detail. Here’s the description of the webinar -
Topic: The Roadmap to SOA Maturity
In the first session of a two-part series, Forrester analyst Randy
Heffner will share his research on how SOA is delivering real-world business
value. He will also demonstrate how the barriers to entry are low, allowing you
to start today and evolve to higher levels of SOA maturity.
Following Randy will be the public introduction of "A New SOA
Maturity Model" – an initiative sponsored by SOA experts at Sonic,
Systinet, AmberPoint and BearingPoint. The new model provides a tool to help
you assess your staff, manage projects and set the vision for corporate SOA
adoption.
Dave
From:
[email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Gervas Douglas
Sent: Monday, October 31, 2005
4:08 PM
To:
[email protected]
Subject:
[service-orientated-architecture] Jason on Maturity & SOA
What to Look For in a SOA Maturity Model ZapFlash
By Jason Bloomberg
Document ID: ZAPFLASH-20051031 | Document Type:
ZapFlash
As companies move beyond the "what" and
"why" of SOA to the "how,"
they are looking for any tool or approach that
will accelerate the
adoption and lower the risk of their
Service-Oriented Architecture
(SOA) implementations. In response to this need,
several SOA
Maturity Models have cropped up that aim to help
companies find out
how far they have progressed on the SOA journey.
Since SOA itself is
still a set of emerging best practices, the main
challenge with
these models is that they all have different
angles on the issue of
SOA maturity, in many cases adding to the
confusion over SOA rather
than clearing any of it up. In this ZapFlash, we
aim to cut through
the noise and confusion, not with our own SOA
Maturity Model (there
are probably enough already), but rather with
advice on how to
understand what the differences are among the
various models, so
that you can evaluate whether such models will
help you be
successful with your SOA rollouts.
What is a Maturity Model?
Most of the SOA Maturity Models currently under
development hearken
back to the widely popular Capability Maturity
Model (CMM), and its
update the Capability Maturity Model Integration
(CMMI) , both out
of Carnegie
Mellon University's
Software Engineering Institute. The
CMMI is a method for evaluating and measuring the
maturity of an
organization's software development and
integration processes. The
CMMI describes five maturity levels that identify
the
characteristics of increasingly mature processes,
giving an
organization a sense of their current progress
with IT and where
they need to improve.
SOA Maturity Models are only loosely related to
CMMI, because while
they take the notion of a maturity model from
CMMI, they don't have
much else in common, because CMMI measures the
maturity of IT
processes, while SOA Maturity Models should
measure the maturity of
an organization's architecture. After all, since
CMMI applies to all
software, integration, and IT processes, CMMI
would arguably apply
just as well to Service-oriented approaches. We
may argue whether
CMMI is the best tool for measuring such
processes, but that's not
the topic of this ZapFlash.
Instead, it makes sense to discuss and measure the
maturity of a
company's architecture. When architects develop or
use a SOA
Maturity Model for this purpose, they should be
looking for a
checklist of features or capabilities their
architecture might
exhibit. The goal is to identify gaps or missing
elements in the
architecture to better rank the remaining
priorities of the
architectural initiative. The SOA Maturity Model
should have levels
similar to CMMI's (although there may be more or
less than five),
which serve as groupings of architectural features
and capabilities
that the architect can use to compare their
progress to another
company's, or to provide milestones for funding or
executive buy-in
purposes, or to guide their purchases of new
software.
It is vitally important, however, for a SOA
Maturity Model to
measure the maturity of the architecture itself,
not just its
implementation. ZapThink has seen some so-called
SOA Maturity Models
that don't measure the maturity of architecture,
but rather how
advanced an organization's Services are, or possibly
how mature
their runtime infrastructure might be. One such
model gaining steam
is the poorly named "SOA Maturity Model"
from Sonic Software,
Systinet, AmberPoint, and BearingPoint, which
falls into this trap.
It's a good model for measuring the maturity of
the Services an
organization develops as part of its SOA
initiative, but not for
measuring the maturity of the architecture itself.
As a result, this
maturity model is really more of a Services
maturity model, as it
fails to address architectural maturity.
What's In a SOA Maturity Model?
So, if the maturity of a company's Services is
neither necessary nor
sufficient for a SOA Maturity Model, what should
such a model
contain? The understanding of SOA in various
organizations ranges
from virtually no conception of architecture all
the way up to a
broad, multi-viewed Service-oriented enterprise
architecture. The
SOA Maturity Model should contain, for example,
how well a company
has fleshed out the various views within their
architectural vision.
At the lower levels they may only have a technical
architectural
view of SOA, but as they move increasingly into
higher levels of
maturity, they should be able to add data
architecture, information
architecture, and process architecture (among others)
into the
enterprise SOA as interrelated views.
Another aspect of SOA maturity is how well a
company leverages
architectural models, in particular the Service
Model that should
represent both the Services in production as well
as the
requirements from business for new or modified
Services. At lower
maturity levels, companies may have no Service
Model at all, or at
best a sketchy model that serves as a limited
design-time artifact.
At higher levels, however, organizations leverage
the Service Model
at both design-time and runtime to represent
Services as they
continue to evolve.
A third measure of SOA maturity that should find
its way into the
SOA Maturity Model is the scope of the application
of SOA. At the
lower levels, a SOA will often have pilot or
departmental scope. As
companies increase their SOA maturity, their
application of SOA will
typically spread across departments, and finally
at the highest
maturity levels, the application of SOA will be
enterprisewide (or
even multi-company).
A SOA Maturity Model may also contain measures of
the maturity of
the implementation of the architecture, as well.
Clearly, a purely
theoretical architecture is not likely to be as
mature as one you've
fully implemented, tested, and put into
production. However, don't
miss the forest for the trees -- a mature
implementation is
primarily a result of a mature architecture.
Without measures of
architectural maturity, a maturity model cannot be
a true SOA
Maturity Model.
Which SOA Maturity Model Should You Choose?
To help you decide where to turn for a SOA
Maturity Model, it's
useful to understand why various companies would
create such a thing
in the first place. Software vendors, for example,
would create a
SOA Maturity Model as a sales tool for their
software. Such models
will likely focus on capabilities their creators
offer in their
products, and deemphasize capabilities they don't
do well (or don't
offer at all).
Consulting firms, on the other hand, are likely to
produce SOA
Maturity Models that help them identify their
clients' needs. Yes,
such models also serve as sales tools to some
extent, but no more so
than any other assessment tool a consultant is
likely to use, and
they necessarily focus on customer value in any
case. Professional
services firms that offer comprehensive SOA
consulting will produce
SOA Maturity Models that are likely to be more
complete than
specialists who focus on one aspect of SOA or
another. A good
example of a reasonably complete model is the
"Service Integration
Maturity Model" from IBM Global Services.
A third place to look for a SOA Maturity Model is
from an industry
group. The advantage of such models is that they
likely won't serve
an alternate role as a sales tool, but on the
downside, they will
probably not be as complete or detailed as one
coming from a
consulting firm. You may also find analyst firms
producing such
models -- but those models will always promote the
firm's particular
spin on SOA. So be sure you buy into the analyst
firm's overall SOA
story before using their model.
Finally, you can always create your own. ZapThink
has seen
enterprise architects hammer out their own SOA
Maturity Models, and
such models have the clear advantage of being
specific to each
company's particular situation. However, such
models will only be as
good as the individuals who put them together.
Strong architects
tend to produce strong SOA Maturity Models, but
weak architects,
well, usually don't.
The ZapThink Take
This ZapFlash begs the question as to whether
ZapThink will produce
our own SOA Maturity Model. We might someday, to
be sure, but we've
found our SOA Implementation Roadmap to be at
least as useful in
helping companies understand the direction they
must go to
accelerate their SOA adoption as a proper SOA
Maturity Model might
be -- and arguably much more practical for many
people. Our roadmap
focuses on real-world advice for companies looking
for a way to
reduce the risk of implementing SOA. In fact, our
2003
Implementation Roadmap was so popular, we just
published a new
version of ZapThink's SOA Implementation Roadmap,
available for free
download today. If you run into us in person or
take one of our
certified training courses, be sure to ask for a
print copy! But
more importantly, help us focus the industry on
producing practical
SOA Maturity Models that don't simply serve to
sell products or
services, but help to accelerate your successful
adoption of SOA.
SPONSORED LINKS
YAHOO! GROUPS LINKS
