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.
