 |
|
|
 |
||
 |
||
 |
||
 |
||
 |
||
 |
 |
|
 |
||
 |
||
 |
||
 |
||
 |
||
|
||
 |
Your independent resource on business integration and network computing through middleware and message brokering
SOA - implications for change
Mike Beeston
Maven Associates
Management introduction
Working in IT these days you cannot miss the attention lavished on Service Oriented Architecture (SOA). Each day a fresh avalanche of news items and press releases concerning SOA initiatives from software and services vendors is likely to appear in your inbox or news reader. It would appear that the jury has finished and has returned its judgement - unanimously agreeing that SOA is the only way forward for IT and business solutions.
This is surely good news. If everyone agrees, then surely we can proceed with confidence as we move to create our own organization's SOA and reap the touted benefits. What can stand in the way of such self-ardent 'rightness'?
As Mike Beeston examines, there is more required than just the commitment of the IT industry to produce technologies that enable an SOA. Undoubtedly the availability of standards (such as Web Services) and technologies (like those found in the J2EE and .NET application frameworks) that help with a move towards service orientation are a start. But there is more to service orientation than technology alone.
Figure 5.1: Application integration legacy
Figure 5.2: Traditional EAI silos
Figure 5.3: The same applications in SOA
Management conclusion
SOA may not be entirely new. But, arguably, understanding it has now reached a maturity level that justifies the attention it receives.
Nevertheless it is important to be aware that introducing an organization-specific SOA is a long-term course of action. It is a course that requires changes across the organization in both IT and business constituencies and, ultimately, results in an overhaul of both application solutions and business processes.
To realize the full benefits of SOA requires an extensive commitment to change that will last for many years before SOA fully achieves the status of 'business as usual'. Fortunately wholesale change is not required in order to begin this change programme. Obtaining early benefits is possible - and such benefits will initially be found in areas such as improvements to integration along with efficiencies for in-house and bespoke application development solutions.
To achieve the full expected benefits of an SOA strategy requires a commitment to process improvement that extends beyond IT systems and into the heart of the organization. In addition application vendors must be pressured to continue to update their applications solutions and so improve their role as service providers. In the meantime hiding legacy, non-SOA solutions behind service facades offers a means to advance. In this sense, Oracle's Project Fusion offers an approach (yet to be validated in practice) which merits consideration by vendors and customers - alike.