SOA Pitfalls - Integrating your Legacy Apps

The Past: I can still remember the time when television was mostly black and white and color TVs were not widely available. One company constantly kept claiming in newspaper advertisements they had developed a color filter you just needed to place on your B+W TV set to transform it to a full Color TV set. What an easy solution! And the product did a perfect job given you enjoy random and constantly changing colors such as magenta faces or green skies. Sounds funny, but, of course, no one of us techno geeks would ever be so naive, right?

40 years later - The Present: Very often I am now involved in SOA projects.  And in many cases, even developers believe it is sufficient to simply wrap  existing application APIs using WS-* based  interfaces to open and integrate all applications into SOA wonderland. However, you might ask, if that is so simple, why do so many SOA integration endeavors fail?

The Future: SOA integration is not as simple as providing plain adapters. If business processes are the main reason for SOA-enabling an enterprise, it is much more effective to identify an appropriate partitioning of functionality into separate services that are then subject to orchestration. As a first step you need to obtain a consistent and prioritized list of business requirements from which you then define your enterprise architecture in a top-down manner. This might typically begin with simple company internal workflows and end in complex B2B scenarios. You'll need to refactor or even reengineer existing applications if securing investments is important in your company. This implies opening applications by providing service interfaces (in a bottom-up approach). Of course, qualities such as operational and developmental ones introduce additional levels of complexity. For example, opening up an existing intranet application for a B2B partnership scenario requires a whole lot of security considerations.

In summary, the adapter pattern might be simple but its concrete application can incur a whole lot of complexity. Building SOA applications naively will save a lot of time and resources in the short term, but imply a large amount of additional costs  in the mid- and long term.