SOA Governance Systems

PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The reader
is available for free
download.

SOA Governance Systems

by Faulkner Staff

Docid: 00011560

Publication Date: 1906

Report Type: TUTORIAL

Preview

Service Oriented Architecture (SOA) is
built on the principle of reusing Web parts.
It is not a technology but an architecture, and not a single event
but an important and widely recognized process for building an IT
infrastructure. The construction and management of such an
infrastructure can be facilitated by a governance system designed to help develop the SOA
and maintain it.

Executive Summary

[return to top of
this report]

Service Oriented Architecture (SOA) is not a technology but a
framework that uses Web
parts in modular ways to gain efficiency and shorten the time
required for
change and development within the system. The Open Group SOA Working
Group defines SOA as an architectural style that supports
service-orientation. Service-orientation is a way of thinking in terms of
services and service-based development and the outcomes of service.

A service:

Is a logical representation of a repeatable business activity that has a
specified outcome
Is self-contained
May be composed of other services
Is a "black box" to consumers of the service¹

SOA governance involves
the processes
through which crucial decisions regarding SOA are made and carried
out.

Related Faulkner Reports

Service Oriented Architecture Tutorial

Service Oriented Architecture
Platforms Tutorial

SOA governance software is used both to create the SOA and to
maintain and enhance
it. Although SOA governance software has not been in existence for
long,
its use continues to grow as the enterprise comes to see SOA as an
essential
element of the enterprise architecture.

Unlike other
parts of the industry, the field of SOA governance systems is not
dominated by
a few large vendors, principally because SOA is a process of
customization
with a great deal of exception management involved. Participants
in the
field increasingly include testing and quality assurance
modules in their
software because the ease of introduction of new systems and their
modification is part of the essence of the SOA approach.

The success
of an SOA will depend to a great extent on the success of its
governance
system. Any SOA must be aligned with the goals of the enterprise
and must allow for the implementation of those goals. An SOA is not a
“quick fix;” almost certainly an extensive period of time will be
required to complete it.

Description

[return to top of this report]

There is general agreement that any mid- to large-size enterprise should
implement a
Service Oriented Architecture (SOA), if only to maintain a
competitive
advantage. SOA is not a technology but a framework based primarily
on the
technology of the Web service. The ability to reuse Web services
in modular
fashion has led over time to an understanding that the network
architecture of
the enterprise can be based on reusable Web parts. Saying this,
however, is
only to begin to understand the complexity of the SOA. Few
enterprises will
implement SOA “from scratch.” Instead, the organization will more
likely
find itself balancing legacy systems and innovative Web products,
all the while
maintaining its production environment and keeping an eye on ROI.

There
is not a
single standard for SOA governance systems. Rather, SOA governance
refers to
the range of activities that create an SOA and maintain it. This
process may be
implemented using software designed for the purpose, which is
increasingly
available in the marketplace. However, since SOA is a framework, a
number of
governance decisions must be made by the organization, both
initially and
continuously. Different experts have pointed out their own principles
for SOA so any list tends to vary. According to IBM, elements of SOA governance are:

Service definition (the scope, interface, and boundaries of a service)
Service deployment lifecycle (the lifecycle stages)
Service versioning (including compatibility)
Service migration (deprecation and sunsetting)
Service registries (dependencies)
Service message model (canonical data models)
Service monitoring (problem determination)
Service ownership (corporate organization)
Service testing (duplicated testing)
Service security (including ranges of acceptable testing)²

Not all these
functions can be
managed by software provided by a vendor and not all can
be included in
one piece of software. However, the construction and maintenance
of an SOA can
be greatly enhanced by the use of third-party software. Among
the components of
a typical SOA governance system are:

A central listing or catalog of Web services, often referred
to as a registry.
An archive or repository of policies and other guidance
essential to the SOA.
A series of agents that control design, implementation,
production status, and change of components of the SOA.
A rules agent that enforces SOA policies.
Management tools that span the entire SOA.

In
selecting an SOA governance system, it is important to ensure
that the system
covers all these areas. In particular the system should cover
both development
and production environments.

Any
technology that is based on the use of Web services can
serve as a protocol for
SOA. Perhaps the best known and most widely used is SOAP
(originally Simple
Object Access Protocol), but others are possible including Common Object Request
Broker Architecture (CORBA) and Representational State Transfer (RST). Another
possible protocol
for SOA governance is the Governance Interoperability
Framework (GIF), an open
set of standards which was supported by Hewlett-Packard. GIF is not a
standard itself but
utilizes a set of available standards to achieve Control
Integration and
Service Data Integration.

SOA
governance is essential for increased business and IT
agility and the ability
to quickly and continuously translate and transmit business
strategy and
requirements into the policies and standards that will guide
the evolution of
the SOA and the enterprise.

Current View

[return
to top
of this report]

The field of
SOA governance systems has been gaining momentum since 2005. However, the potential efficiency and
flexibility of SOA make it
desirable for an enterprise of any significant size today,
if only because of
the competitive advantage it promises in adaptability and
customer service.
Increasingly, the enterprise turns to SOA because of
market pressures to
take advantage of the efficiencies that SOA offers. This
does not mean that an
organization is likely to scrap its current infrastructure
and start from
scratch; on the contrary, moves in the directions of SOA are
likely to be
incremental.

It is best not to think of the products from SOA vendors as turnkey
solutions, which are not practical in the world of SOA,
but rather as offering
tools for implementing and operating an SOA. In addition,
the largest vendors,
such as IBM, offer solutions frequently described as SOA-appropriate. These
often require a strong commitment to the company’s
additional products.

Among the main SOA vendors are IBM, Oracle, Rogue Wave
Software’s Akana Platform, RedHat’s JBoss SOA Platform, and TIBCO.

Outlook

[return to top of this report]

SOA is in
many respects a recent concept, and SOA governance
software is a fairly new
sector. Typically, SOA is deployed incrementally,
meaning that many
organizations that acknowledge its importance have not
yet completed their
implementations. The concept of the SOA itself is
evolving, and there is no
guaranteed “one way,” since, as noted, SOA is not a
technology
but an architecture. In addition, SOA is closely tied to
Web technology, a
field which, to put it mildly, is constantly changing.

Because SOA
governance systems are relatively new (they began to
proliferate under that
name in 2008-2009), they cannot be considered part of a
mature technology. At
the same time many of the components of SOA governance
have existed for a much
longer time. Nevertheless, volatility in the area can be
expected for some time
to come.

It
should be noted that SOA
governance software is not dominated by one or two big
software vendors, and is
not likely to be, because the field is quite
specialized. One reason for this
fact is that a great deal of customization is needed in
order for an SOA of any
scale to perform effectively.

The market
for SOA governance systems will continue to grow. There
is no economic
justification for not reusing Web parts where possible,
and there are many
reasons for doing so. As SOA governance systems become
more widespread and more
competitive, they will in themselves spur on the
adoption of the SOA strategy,
which will lead to the increased use of governance
mechanisms.

Recommendations

[return to top of this report]

It is likely
that failure to implement an SOA successfully will be
largely due to a failure to
implement proper SOA governance. An SOA that is not
properly governed will not
achieve the efficiencies available through this
challenging but worthwhile
architecture, and potentially it may also lead to
security breaches, outages,
and regulatory non-compliance. An improperly governed
SOA may also run the risk
of being misused on the principle that “everybody’s
property is nobody’s
property.” To avoid this situation, responsibilities
must be clearly laid
out and reinforced by an effective governance system. It
is not enough simply
to make policies; they must be put into practice and
enforced.

Any SOA must be implemented in accordance with the
fundamental strategies of the enterprise, and an SOA must
begin with the establishment of realistic goals that include
room for development and growth. A strong steering committee
will greatly facilitate this part of the process. Out of an
understanding of the company’s strategies, a plan can be
developed for moving from the current network state to an
implemented SOA. Issues to be addressed may include the
following:

Are decisions tightly controlled by a central authority or delegated to
many individuals?
Do the groups within the organization work in tandem or autonomously?
How do other governance program offices within the organization work?
How well does the company articulate and dissemination governance
precepts?
Do people strictly follow policies and practices within the organization?
What flexibility does management have to adapt processes to meet the needs
of a project?
What flexibility does management have to establish/modify incentive
systems?³

It will be
useful to discuss SOA governance systems with other
companies who have made or
begun to make the same transition. Their experiences
will differ in many ways,
but they will also be able to forecast important
pitfalls. Metrics to measure
the effectiveness of the SOA should, like the SOA
itself, be designed in
incremental fashion. An SOA governance system should not
impose an undue cost
or maintenance burden on the enterprise, which
should emphasize the
importance of product comparison and references in the
selection process.

In selecting
an SOA governance system, among the elements
increasingly considered standard
in an SOA are a registry service, compliance with UDDI
standards, an
appropriate level of platform independence, and the
integration of processes
whenever possible. A central repository is considered an
essential element.
With these elements in mind, vendors can then be
approached about SOA
governance systems, but not without a fundamental
understanding of where the
organization wants to go and the high-level steps it
will require to get there.
Many SOA governance systems are now emphasizing testing
and quality assurance
products, and these will provide significant help in
implementing the SOA.

Finally,
proper implementation of an SOA almost certainly will
take time. The enterprise
should visualize an SOA as a long-range effort and
resist the impulse to
“get it done now” instead of getting it done right over
a period of
time. A corollary to this principle is that an SOA
governance system should be
capable of re-scaling. The organization should make
certain that SOA governance
software is capable of adapting to the organization’s
time frames.

Web Links

[return to top of this report]

IBM: https://www.ibm.com
Oracle: https://www.oracle.com/
RedHat: https://access.redhat.com/
Rogue Wave Software: https://www.roguewave.com/
TIBCO Software: https://www.tibco.com

References

[return to top of this report]

¹ The Open Group. "Service Oriented Architecture: What Is SOA?"
² Bobby Woolf. "Introduction to SOA Governance." IBM.
June 13, 2006.
³ Thomas Erl, Stephen G. Bennet, et al. "Understanding SOA
Governance." InformIT. May 26, 2011.

[return to top of this report]