SOA: The Cure for Accidental Architecture
1 Comments Published by Hanno Ekdahl on Sunday, June 01, 2008 at 11:08 PM.
The term Accidental Architecture was coined in a paper published by the University of Kent that discusses the evolution of IT architectures over time and the complex issues surrounding legacy systems. The term has come to represent how narrowly focused technology investments result in an enterprise IT infrastructure that is both complex and challenging to manage. In most organizations, functional units drive IT investments in areas such as procurement, operations, and service delivery. Oftentimes, these IT systems are built to meet ‘local’ requirements and are not thought of as an enterprise-class solution that will interact with other systems and platforms. The net result of these siloed IT investments is an “Accidental Architecture”.
This is not to say that each individual solution is not well-architected, nor that if fails to meet the defined business need, but rather that at an enterprise level the architecture becomes ‘accidental’ as it is dictated by the provincial IT and business decisions that created it. In essence, IT decisions are made without evaluating their full impact on the enterprise and without an eye to the bigger picture, thus creating information gaps in the value chain. This is a missed opportunity to improve information quality, drive new efficiencies, and enable collaboration to provide additional value to the customer or end user. The end game here is to eliminate the information gaps to improve decision-making about operations, investments, and the execution of the organization’s mission.
So how do we avoid the pitfalls of an accidental architecture? We take a move out of Steven Covey’s playbook and ‘begin with the end in mind’. If our goal is to eliminate islands of information and barriers to collaboration, then we require a solution that promotes interoperability. The way to achieve this goal is to adopt enterprise standards that specify how different applications will interact and that also bridges the gaps between different platforms. We recommend adopting the IT principles commonly known as Services Oriented Architecture (SOA). SOA is an architectural style that is based on a set of evolving standards (some of which are mature, e.g. SOAP) that provide a framework for the development of Web services.
SOA provides the tools to manage Web services and specifies the means for service integration and interoperability. This allows developers to create the applications they need to solve business problems without having to worry about application integration issues down the road. This effectively separates the infrastructure from the application, which provides flexibility, reduces development costs, increases re-use, and allows the organization to deploy solutions that work across the enterprise.
As organizations move toward a Services Oriented Architecture, they often take an incremental approach and work to meet a discreet need before implementing web services on a large scale across the entire enterprise. A case study of ING Bank’s first SOA implementation is discussed in “The SOA Magazine” and gives a good overview of the process and lessons learned.
This is not to say that each individual solution is not well-architected, nor that if fails to meet the defined business need, but rather that at an enterprise level the architecture becomes ‘accidental’ as it is dictated by the provincial IT and business decisions that created it. In essence, IT decisions are made without evaluating their full impact on the enterprise and without an eye to the bigger picture, thus creating information gaps in the value chain. This is a missed opportunity to improve information quality, drive new efficiencies, and enable collaboration to provide additional value to the customer or end user. The end game here is to eliminate the information gaps to improve decision-making about operations, investments, and the execution of the organization’s mission.
So how do we avoid the pitfalls of an accidental architecture? We take a move out of Steven Covey’s playbook and ‘begin with the end in mind’. If our goal is to eliminate islands of information and barriers to collaboration, then we require a solution that promotes interoperability. The way to achieve this goal is to adopt enterprise standards that specify how different applications will interact and that also bridges the gaps between different platforms. We recommend adopting the IT principles commonly known as Services Oriented Architecture (SOA). SOA is an architectural style that is based on a set of evolving standards (some of which are mature, e.g. SOAP) that provide a framework for the development of Web services.
SOA provides the tools to manage Web services and specifies the means for service integration and interoperability. This allows developers to create the applications they need to solve business problems without having to worry about application integration issues down the road. This effectively separates the infrastructure from the application, which provides flexibility, reduces development costs, increases re-use, and allows the organization to deploy solutions that work across the enterprise.
As organizations move toward a Services Oriented Architecture, they often take an incremental approach and work to meet a discreet need before implementing web services on a large scale across the entire enterprise. A case study of ING Bank’s first SOA implementation is discussed in “The SOA Magazine” and gives a good overview of the process and lessons learned.
Hi Hanno,
I liked your article on SOA. Do you have more info on that? If so, please send
Gwen Whitman