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

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. 


Join the discussion