Today it seems that every organisation
of any significance either has or is planning a Service Oriented Architecture (SOA)
initiative as a key component of its IT strategy.
The rationale behind SOA
projects is largely understood and well thought out. Justification often stems
around the need to consolidate technologies and simplify support, enhancement
and development processes through the use of a standards-based, contemporary technical
architecture. The end goal of the initiative is normally to reduce the overall
cost of running the IT operation and to provide a better technical framework for
servicing the ongoing needs of the business.
In the modern world, business has morphed
and evolved significantly over the last 20 years in response to an ever changing
consumer market and higher degrees of regulation and scrutiny. Mergers and
acquisitions have significantly altered the business landscape and one-time
household names now trade under the brands of foreign parents or worldwide
conglomerates. Whilst this sort of M&A activity presents all sorts of well
documented challenges on the business side of an operation, the technology
implications are often not understood until the deal is done.
Too many times,
the newly formed company wakes up to find it is now running multiple lines of
business applications on disparate platforms and technologies. It has its new
customer base distributed across different sources of data and, in many cases,
the same customers duplicated on both the ‘old’ and new systems. SOA can help
to address the technology problems encountered when operating a business
running multiple disparate applications.
This is not a new phenomenon but one
that has been addressed in different ways over the last 15 years. Some
technologists argue that SOA is just Enterprise Application Integration (EAI)
with XML. In a simple sense, that is true. But it is the standardisation of the
whole approach that ‘ups the game’ in terms of flexibility and ease of
deployment. EAI and beyond EAI was first coined as a phrase in the mid 1990s,
giving rise to a number of application vendors specialising in integration
technology. In early EAI implementations, a degree of
‘clunkiness’ was often a by-product of
the inelegant integration methods
required to circumvent the closed,
proprietary nature of many legacy
applications. In the financial services
world, many key lines of business
systems were originally developed in the
late 70s and early 80s at a time when
standards were focused on coding
practices.
In those days, the entire IT
department often existed because of the
company mainframe. Even today financial
services companies rely on application
and database technology originally
developed 30 years ago. This clunkiness
came in a variety of forms and often
invited amusing terminology to describe
its characteristics. The ‘Lipstick on
the Pig’ term was often used to describe
the practice of screen scraping or
network spoofing a legacy application to
provide a slicker, apparently modern
user interface.
The term ‘Swan Syndrome’
is alive and well today as a description
of many technical architectures. To the
user the system appears elegant and
flawless as it operates with seemingly
effortless efficiency, hence the part of
the swan above the surface that one
sees. However, underneath the
‘waterline’ (where the swan’s legs are
feverishly kicking and manoeuvring)
there is often a variety of manual or
outdated operations and inefficient
processes which are keeping the entire
operation afloat.
Even with many modern
SOA projects, the difficulty encountered
by the technologists revolves around the age old issue of integrating with computer systems that were not originally designed to be integrated with. So various ‘devices’ are either purchased or constructed to sit in front of the legacy applications in order to make them easier to ‘hook up’ to a Service Oriented Architecture.
To be fair, it is certainly accurate that some organisations have replaced their legacy systems with shiny new technology that fits well in an SOA, however the reality for most companies is that budgets do not exist to rewrite systems that, simply put, still work. SO
A benefit s So where does all that bring
us in terms of delivering a successful
‘business friendly’ SOA implementation
that delivers the tangible business
benefits that the chief technology
officer promised the CEO when the
project started? A well implemented
Service Oriented Architecture can bring
significant benefits to the IT side of
an operation.
These may include: • Making IT generally more efficient • Reducing the complexities of maintaining and operating a myriad of technologies that are past their technical prime but, as discussed above, can’t be easily replaced. • Reducing and consolidating the personnel skills required in the IT shop to standards-based, easily hireable competencies.
• Setting the stage for more cost
effective outsourcing of technical operations by adopting accepted standards that are already in place at leading outsourcers.
• Establishing an architecture based
on standards such as Web Services and
JEE eases the pain of integrating third
party solutions into a company’s environment. • Because both the architecture and the technology being acquired support the same standards, the need to perform ‘clunky’, costly integration is reduced, if not eliminated. Theoretically, all of the systems should ‘play nicely’ with one another. In many cases the whole rationale behind investing in such a programme is to simplify and bring down the cost of running an IT operation.
What many organisations fail to recognise is that by embarking on that very process, all sorts of opportunities to reduce business complexity and costs open up as well. SO A and process ma nagement
Let’s illustrate how SOA and process
management can be complimentary. Consider
an Australian bank with a branch network
that wishes to sell and service a varied
portfolio of financial offers. This may
include mortgages, credit cards and
traditional mainstream banking products.
However, that bank’s retail customers
have become accustomed to the highly
convenient manners – branches, Internet,
ATM, mobile phone and so on – in which
they interact with the banking side. If
the bank wishes to provide similar access
to the IT systems that support those
other products, the inevitable
integration challenges arise. Without an
SOA (or even modern EAI) architecture we
are back to our Swan Syndrome and Pig
Lipstick situations.
This becomes
exacerbated when the systems that
deliver the functionality to the
branches have to be modified for the
inclusion of additional acquired business
units and compounded further when one
part of the enterprise is expected to
pay for a modification that will also
benefit another. Does this sound
familiar? Temptati on and planning ahead So
now we look at how to approach an
enterprise-wide SOA process management
programme and how to leverage the
investment in a way that all
stakeholders in an organisation can benefit
from the monetary and personal investment.
Knowing where to start is the key, and
often external help in the form of
experienced credible consultants with
industry and technical expertise can
accelerate the process in the right
direction. Adopting the right SOA and
process improvement framework is also
imperative. Whilst the IT department is
closest to the nuts and bolts of the
line of business applications, the
business management are the ones closest
to the operation of the company and the
expectations of an ever more demanding customer base and ‘cut throat’ market competition.
Fortunately, there are service definition frameworks available for purchase that defines a model SOA service profile for particular industries. Temptation comes in the form of the tendency to architect the service layer to suit today’s business processes. What would appear on the surface to be a business-friendly approach has proven to be erroneous in that it results in tying the processes and the service layer too tightly together.
This eliminates the flexibility that should be a hallmark of a well-developed SOA. It is also a mistake that is repeated with alarming frequency.
The future If there are
opportunities for business operations to
leverage benefit out of SOA investments today,
then what other current trends may
benefit also? Well, since 2006 the
emergence of SaaS (Software as a
Service) technologies has been gathering
pace. Indeed, an impediment to
enterprise SaaS-based solutions is the
challenge of integrating the service-based
architecture at the SaaS provider with
the legacy applications that reside at
the customer’s premises.
Early SaaS
deployments either deployed workstation
based adapters or avoided the thorny
subject of host application integration
as a whole. In the new SOA world with
the right levels of network connectivity
and security, the SaaS option for more
comprehensive application integration
becomes more viable. Additionally, we have seen the development of outsourcing and offshoring operations that have managed technology logistics through the use of VPN or dedicated networks.
If business potential truly exists for concepts such as mass collaboration and ‘crowdsourcing’, secure service-based access to organisations’ systems of record will need to become more common. Techniques will need to be developed to ‘anonomise’ human tasks so that secure information is not compromised. The use of process management and SOA technologies will need to evolve to support these and other potential trends in both customer expectations and workforce deployment.
