|
SOA - Breaking Down the Barriers
A Service Oriented Architecture (SOA) brings a new approach to IT functionality within an organisation. Whereas old approaches had to come from a starting point of an application providing the total solution to specific problems, the idea behind SOA is to provide a far more flexible system, based on discrete pieces of functionality being called as required from any business function to facilitate specific business requirements.
This approach has many benefits - for example, functional redundancy, where multiple applications carry out the same function within their own domain, is minimised, and the optimisation of any function provided in this way is immediately applied to all processes that use that function. The removal of functional redundancy also means that less hardware is required to run the function - no discrete resource is required for each of application a, b, c and d's version of the function; instead, the single instance of the function can be sized to meet the composite requirements of the multiple processes that will be calling this function.
Also, SOA can provide a much greater level of flexibility when it comes to resource utilisation. With average hardware utilisation running around 10-15% in a standard client/server or monolithic web-based application environment, SOA can provide the means to up utilisation to 60% + through the use of virtualisation and dynamic provisioning of functions.
The Real Business Starting Point
With all the benefits around SOAs, it feels as if SOA should have replaced existing architectures already and that old-style, monolithic applications should be ripped out to be replaced with new Web Services-base composite applications built from disparate functional components. As we all know, this is far from the reality, and ongoing business pressures will stop all but the very brave (or foolish) from carrying out a full "rip and replace" approach in the implementation of SOAs.
The main problem is that heavy financial and resource investments have been made in existing systems - and these systems were implemented for all the right reasons when client/server and application centric models were accepted as the norm.
Even solutions sourced in the past couple of years will not be fully SOA-enabled - the majority of applications that have been built to Web Services standards will still be monolithic in approach, and will contain all the functionality required to carry out the set of solutions that the owning vendor is trying to solve. With hard-coded internal connections between functions being replaced with tightly coupled Web Service-based connections, the end users are often little better off than before.
So, the real business problem is the perennial one of how to get to the future from the present; how to ensure that existing investments are protected while being embraced and suitably utilised by the new approach to business-centric computing.
The Need for Connectivity
Existing applications tend to have been architected to deal with vertical needs - ERP systems deal with specific areas of inventory, business asset management and so on, while CRM systems deal with customer issues. The expansion of the specific Enterprise Resource Planning (ERP), Customer Relationship Management (CRM) and Supply Chain Management (SCM) vendors into a greater range of coverage to try and tie in their own customers to a single vendor solution has forced the vendors into creating connectivity solutions into their overall portfolios to enable their disparate offerings, often built up through mergers and acquisitions, to interact with each other. In many cases, this interaction is carried out through hard coding of discrete adaptors from one part of the solution to the other. In other cases, the vendor will create more "open"connectivity for data exchange using technologies such as the eXtensible Markup Language (XML) for data formatting.
The biggest problems come when we look at the more heterogeneous environments, which may also include the need to connect mainframe and other computing environments into the distributed SOA environment. Here, with less abstraction between the application and the run time environment, hard coded connectivity tends not to work for long, and semi-proprietary approaches to "open" XML are little better.
|
