Introduction
SOA maturity model is a term that I coined in an
attempt to help organizations define architectural
guidelines and a process for achieving a greater
level of maturity and predictability in their overall
information technology (IT) architecture initiatives.
The model described here is designed to enable
your organization to identify itself on a scale
of 1 to 5 (with 5 being the most advanced, or mature,
level) in terms of architecture maturity. The model
also helps pave your path to achieving a true Services
Oriented Architecture (SOA), which is defined as
a Level 5 on the maturity curve. An iterative application
of the SOA maturity model allows IT organizations
to evolve to meet rapidly changing business needs
in a cost- and time-effective manner. Using this
model, I show how at each level of maturity you
can achieve more architectural goals.
Importance of a Maturity Model
At lower levels of maturity, individual project
teams define their own architecture using nonstandard
techniques. These techniques lead to less-predictable
and less-repeatable solutions that are difficult
to manage and do not adapt to change. As the organization
matures to Level 3 and 4, a strong Enterprise Architecture
(EA) group presence emerges that acts like a governing
body for architectural principles. Elements of
a reusable architecture appear, and are flexible
to the needs of each Line of Business (LOB) that
it serves. This solution tends to be effective,
provides some level of interoperability, and paves
the path toward service orientation. I define a
Level-5 organization as one that has implemented
and been successful in its SOA initiatives. This
type of organization has bought into the concepts
and has evolved to the point of truly building
and sharing services among the LOBs and maybe even
with the customers, partners, suppliers, and possibly
even competitors.
This model applies to all aspects of a company’s
IT architecture. It not only has a strong impact
on the development side but is equally important
to the physical, logical, deployment, and process
architectures within the IT organization.
The SOA maturity model
The Capability Maturity Model is used to measure
the maturity of the software development process
at an organization. The SOA Maturity Model is targeted
at measuring the maturity in the SOA development
process. I define the SOA maturity model with the
same five steps outlined by CMM. Figure 1 shows
the basic SOA maturity model:
Figure 1. The SOA maturity model
Level 1: Initial
Organizations at the Initial SOA maturity model
level are typically those in which no formal
processes for architecture exist. There is
no separation of architecture from projects.
Typically, these organizations do not have
an EA team; each project team, generally broken
down by LOBs, works in a silo. The focus is
on delivering an individual project.
The result of this level is unpredictable project
schedules, budget overruns, and poor quality
code that is typically not reusable and hard
to maintain. Projects repeat the same tasks,
thus increasing the cost of delivery and maintenance.
At this level of maturity, or rather immaturity,
IT tends to dictate business agility instead
of the other way around.
Level 2: Repeatable
At this level, some elements of architecture
efforts emerge. Project teams tend to define
a reusable architecture that they use from
one project to another. Informal paths of communication
are established across project teams. However,
because there is still little to no presence
of an EA team, these levels of communications
are ad hoc and chaotic. At this stage an EA
team would help put structure to the chaos
and foster the communications between the project
teams.
The result is some level of reuse of architectural
components. Ad hoc processes and chaotic lines
of communication lead to some level of repeatability
in architectural solutions, thus lowering the
cost of delivery and the maintenance costs of
software. This reduction is hardly significant
from a dollar perspective.
The greatest advantage of this level of maturity
is the realization of benefits that a structured
process can lead too. Project teams are realizing
the potential benefits of a more synergetic approach
to software development. They realize that the
can prevent the huge cost overruns, create a
predictable software development schedule and
improve the overall quality of the software.
Advocates who are opening these ad hoc lines
of communication across project teams can make
a case to executives to gain sponsorship towards
an EA organization (or at least a formal recognition
for a greater architectural initiative).
Level 3: Defined
Level-3 organizations are typical organizations
that have made some substantial investment
in an EA initiative. A team is in place that
is tasked with standardizing architecture elements.
This team is responsible for creating a reference
architecture, educating project teams on this
architecture, and defining a governance and
enforcement policy. Typically the EA teams
tend to start with creating a set of technical
components and frameworks and standardizing
the use of these frameworks across project
teams.
I suspect most Fortune 500 organizations fit
into this level. The vision of organizations
at this level is that this overseeing EA team
can substantially reduce the cost of project
delivery. However, the reality seems to be that
EA teams lack the business knowledge and do not
communicate well with the project teams serving
each LOB.
EA team initiatives seem to cost more than
the value they add. The single biggest cost that
comes with an EA team is the ongoing cost of
architecture maintenance. In today’s tough
economy, as the core architecture team is moved
back to delivering projects, the EA is typically
not maintained, thus reducing its value and applicability.
Another issue at this level is the tug-of-war
between the project teams and the enterprise
team. Project teams do not really respect or
like the “prying eyes” of the EA
team. So what does this level of maturity really
get you?
In my opinion, this level is a first step in
recognizing the need for an SOA. EA efforts seem
to fail, because they are typically not nimble
enough to satisfy needs across LOBs. The EA team’s
lack of domain knowledge is the big issue. Those
EA teams that recognize this drawback will be
successful. It is imperative that they do not
consider themselves experts: They need to realize
that at the end of the day, they are serving
a business. This recognition will eventually
lead to their success and is what takes an organization
to the next level of architectural maturity.
Level 4: Managed
This level of maturity is achieved when EA teams
start defining a path to SOA. Today, every
big organization has a group of architects
talking about SOA. At the very least, these
architects seem to recognize the value of and
are trying to figure out an SOA strategy.
An organization can be classified as Level
4 if its SOA initiatives proactively seek by-in
from project teams that serve the LOBs. The project
teams and EA team need to work together to define
the organization’s SOA, including the processes,
technologies, and components. Governance and “reward” policies
should be defined. Support levels need to be
established with a clear understanding of whom
to call when and for what. A framework for analysts
to define services must be in place. How does
an LOB or a project team identify potential services
that it can expose or that it needs from another
project team? Who is responsible for building
and maintaining this service? Who pays for it?
These are the types of questions the SOA plan
at this level would answer.
This level of maturity comes with a lot of
risk as well as a lot of benefit. In particular,
it is important to realize that Level 4 has little
to no short-term cost benefit. Getting to and
executing Level 4 is a very costly effort for
any organization. If done right, however, it
leads organizations to Level 5 in the SOA maturity
model. If done poorly, an organization will most
likely drop to a Level 2, because the EA team
will be disbanded or have little support from
the business.
Level 5: Optimizing
Level 5 is nirvana. Architectural processes and
policies are instutionalized, and there is
a clear recognition of the value of services.
A framework is in place for each team to expose
and consume services. At this level, organizations
can truly explore the value of SOA. They start
figuring out how to exchange services with
their business partners, suppliers, and customers.
Business service level re-use -- not just technology
component re-use -- is core to the architecture
in order to achieve maximum business agility.
At this level, organizations see the cost and
time benefits of having a more nimble IT organization
that can quickly respond to business needs.
The key goal of this level is to define an
end-point for your architecture initiatives.
High standards and goals need to be clearly defined
to achieve them. Without the vision of this level,
organizations won’t be able to justify
the costs of getting past Level 4.
Characteristics and impacts
of each level
Now you’ve seen the five levels of the SOA
maturity model. Table 1 describes at a high level
the characteristics and impacts of each level of
maturity.
Table 1. Overview of SOA maturity model
levels
Levels |
Characteristics |
Impacts |
Level
1:
Initial |
No formal software-development
process
Minimal documentation of architecture
No communication across project teams |
No architectural
consistency across projects
Difficult to understand and modify resulting
systems
Minimal reusable artifacts
Teams “re-invent the wheel” for
each project |
Level
2:
Repeatable |
Some level
of architectural documentation
Architecture enforced within a project
team
Ad hoc communication of architecture across
project teams |
Minimal improvements
over Level 1
Some successful practices are repeatable
Recognition that an EA effort might be
valuable |
Level
3:
Defined |
An EA team
is in place that defines a reference architecture
and some software-development practices
Project teams are encouraged but not rewarded
to use this architecture
EA does not meet all the needs of each
LOB |
Difficult to
get consensus: EA teams and project teams
don't work well together
Architecture maintenance is a big concern
Architecture has a shelf life of 6-12
months at most |
Level
4:
Managed |
SOA is considered
the end point for the architecture initiative
LOBs and EA teams work together to define
an SOA
Support and governance models are in place
LOBs are rewarded to expose and consume
services |
Up-front costs
seem to be prohibitive
Reduces risk of project delays resulting
from inconsistencies in the architecture
layer
SOA within the organization seems to get
some momentum |
Level
5:
Optimizing |
SOA becomes
a starting point
Organizations want to explore service
orientation with their customers, suppliers,
and partners
Continuous architecture optimization |
Business agility
Interoperates with services from customers,
partners, suppliers, and others
Faster time-to-market
Lower Total Cost of Ownership (TCO) |
Summary
Simply embarking on an SOA project is not always
the best way to start. An organization must determine
what the first steps are in its SOA initiatives.
To be successful in implementing SOA in your
organization, you first need to understand the
IT landscape and overall architecture of your
organization. The SOA maturity model is just
that: a means of helping you assign a level of
maturity to the IT architecture of your organization.
When this assessment is complete, you’ll
have the information you need to determine the
best path to an SOA for your organization.
In applying this model, EA groups can determine
what services they need to provide to individual
LOBs. In addition, consulting and out-sourcing
firms can use this model to build a list of services
that they might want to add to their service
offerings.
Other SOA / Web Services Maturity
Models
What
to look for in an SOA Maturity Model by ZapThink.
Loosely coupled has a good perspective on SOA
Maturity.
See the Web
Services Maturity Model from CBDI
See the Creating
a Strategic IT Architecture Competency:
Learning in Stages by Dr. Jeanne Ross
See Sonic
Software's approach to the maturity model concept
for SOA.
See SOA
Maturity Model: Compass on the SOA Journey by
Theo Beack, Chief SOA Architect, SoftwareAG
|
