Can SOA be justified?

Page Tools

Organisations across Asia-Pacific are struggling to articulate
clear business and technology justifications for pursuing SOA-based
initiatives, says Michael Barnes, Gartners vice-president of
technology research services.

According to Barnes, Service-oriented Architecture (SOA) is
neither a tool nor a technology, nor even a destination in
itself.

Rather, it is a way of using existing techniques, tools and
standards so that business processes can be not only automated, but
also ultimately optimised.

In SOA, inter-operability-as opposed to software-is the
fundamental design point for the system, Barnes says. Very few IT
systems were designed to enable inter-operability across an
enterprise. Instead, they were designed to meet the needs of a
particular function, and thus have created unnatural barriers
within the business.

"The key is making sure that people understand there is no
silver bullet or any shortcut to SOA," Barnes says.

"Understanding the basic principles and implications of SOA is
the first step. Unlike traditional object-oriented approaches,
designing for SOA requires that parts of a given system be viewed
as a set of relatively autonomous services, each of which is
potentially managed and implemented independently, and linked
together ultimately using a model-based approach via a set of
standard agreements and protocols."

"As a business, if youre not identifying your core
critical business processes, then you probably wont stay in
business very long. But the key difference is then taking those
processes and decomposing them into the components or services that
comprise those processes, and then identifying the technology, the
systems and the applications that support those services," Barnes
says.

Flexibility and agility
He believes that the flexibility and increased business agility
that SOA can bring will enable an organisation to reduce the cost
of changing, extending or optimising processes, and make better use
of its existing and future IT investments.

The other big benefit of SOA is productivity. For a raft of
political and legacy reasons, different departments in a company
often do not work together, yet their underlying services are
similar or overlapping. In a financial institution, for example,
different areas of the business receive customer and account
inquiries.

By implementing a directory of data in which each data element
is uniquely defined, but can be reused among processes and
departments, an organisation only has to program all these services
once. So if it starts a new business or new department with new
processes, it can reuse the functionality.

Barnes thinks the fundamental success factor in going down the
SOA path is effective prioritisation, and the ability to prioritise
the business and technology needs of the organisation with an
assumption that resources are severely constrained.

Although SOA benefits might ultimately be enterprise-wide,
transitioning towards SOA should be done incrementally, starting by
identifying the most appropriate business process or service needs
within the organisation, he says.

"You clearly cannot SOA-enable all your IT systems-its
simply not going to happen," Barnes says. "Nor should you even look
to that as a goal. This means that these [SOA] projects must be
driven by business process experts in conjunction with
enterprise-wide architects. You will not justify an SOA initiative
based purely on cost savings through technology or any other
technically driven approach. You need to justify it based on some
type of business process improvement."

Policies, practices Peter Bars, a partner with Deloitte, agrees
that SOA is not a specific product and admits to being cynical
about the IT industry when it comes to their marketing of SOA. He
thinks it is a mistake for people to believe SOA requires the
implementation of new technology.

"SOA is an architectural style of designing your systems.
Its about policies, practices, frameworks and standards. One
of the dangers is that we get too hooked up on the technology.

[But] if you do SOA right, you can improve your agility, get
better quality and drive some costs out of your IT systems. I think
it has potential to bring the delivery of IT closer to the business
and some people have really achieved some benefits," he says.

Bars thinks that financial institutions are leading the way in
SOA, followed by companies with extended supply chains and multiple
business partnerships. These organisations tend to have many legacy
systems, and because of the large investment in those systems, they
cannot throw them out easily, he says.

Through 2005-2006, Gartner expects most SOA projects to be
limited to augmenting existing middleware with web services
wherever possible.

Although these projects will not meet the full definition of
SOA, they will provide the foundation necessary to make the
transition towards an SOA approach to system delivery and
integration, the firm says.

Barnes adds that SOA-based initiatives should be viewed as an
evolutionary process that requires continued leveraging of existing
infrastructure, technology, and tools. "Much like how business
processes span across and outside the organisation, IT systems must
do the same," Barnes says. "Thats a fundamental change in how
we think about, how we design and how we deliver systems."