Take a Serious Look at the “A” in SOA and Gain Flexible, Adaptable Architecture

  • by Dr. Volker Stiehl, Professor, Ingolstadt Technical University of Applied Sciences
  • February 12, 2010
Understand what the ideal architecture for an enterprise-ready composite application should look like. Discover the pitfalls involved, how to avoid them, and how your decisions influence the overall complexity of the final application. By following these recommendations, you can develop applications that are well prepared for your always-changing IT landscape.
Key Concept
The basic idea behind composite applications is to build completely new applications that cover business processes that are unique for your business or industry. In contrast to classic packaged applications where everything is built from scratch, a composite application tries to reuse as many existing business functions as possible by calling services that are accessible by standard means, such as the Web services standards. The developer can concentrate solely on new business logic and hand over responsibility to back-end systems where appropriate.

At the beginning of 2009, the service-oriented architecture (SOA) community was shocked to find that many felt that SOA was dead. It was a natural consequence of all the failed SOA projects: The SOA promises (reducing costs and increasing agility) were not achieved.

Instead of analyzing why the projects failed, SOA in general was questioned. From my experience, many SOA-based projects were simply started without sufficient preparations. The key aspect that caused most of the trouble was how the new composite applications interacted with the back-end systems. In most cases, the services were directly invoked out of the end application. Although this approach worked perfectly in the packed application area, this is not appropriate for SOA-based applications.

The goal of SOA must be to separate the business part from the technical part using a very special kind of application: a loosely coupled composite application. Although this sounds very intuitive, in the first SOA projects wrong architectures led to applications that lost all their promised flexibility and adaptability.

In a loosely coupled composite, you do not reuse any existing screens from running applications. You also do not call the back-end services directly out of the composite. These are all indicators pointing in the wrong direction. You should aim for a clear separation between the composite application and the back-end systems.

You also need an additional layer between the composite application and back-end system that mediates between the two. This creates timeless software that interacts with your existing landscape.

Dr. Volker Stiehl

Prof. Dr. Volker Stiehl studied computer science at the Friedrich-Alexander-University of Erlangen-Nuremberg. After 12 years as a developer and senior system architect at Siemens, he joined SAP in 2004. As chief product expert, Volker was responsible for the success of the products SAP Process Orchestration, SAP Process Integration, and SAP HANA Cloud Integration (now SAP HANA Cloud Platform, integration service). He left SAP in 2016 and accepted a position as professor at the Ingolstadt Technical University of Applied Sciences where he is currently teaching business information systems. In September 2011, Volker received his Ph.D. degree from the University of Technology Darmstadt. His thesis was on the systematic design and implementation of applications using BPMN. Volker is also the author of Process-Driven Applications with BPMN as well as the co-author of SAP HANA Cloud Integration and a regular speaker at various national and international conferences.

See more by this author


No comments have been submitted on this article. 

Please log in to post a comment.

To learn more about subscription access to premium content, click here.