Service Oriented Gridlock: Introduction

While you will find person after person who complains about the existence of stovepipes, applications that deliver function directly to the user and are not integrated with other systems, there is also a danger in becoming overly coupled to existing systems. Service Oriented Architecture (SOA) is touted as a way of ensuring that the coupling between systems is as loose as possible. However, moving from stovepipes to coupled systems, even relatively loosely coupled systems, represents a move from independent projects to dependent projects, and introduces a great deal of schedule risk into projects that are under development. A move from stovepipes to SOA can introduce what I refer to as Service Oriented Gridlock (SOG) to an enterprise, where no application can be deployed without affecting other applications, resulting in a dependency chain that greatly diminishes the ability of capabilities to be delivered to end users (the thing which stovepipes excel at doing).

This post will serve as the first of a series where I delve into factors that lead to SOG, explain a better process by which stovepipe applications can extended to provide services, and show how SOA can be achieved while still retaining the benefits of stovepipes.