The SOA Reference Architecture defines an ideal target architecture or architecture template for an enterprise or LoB. It supplies a common vocabulary based on shared experience and tries to decrease the complexity of the IT infrastructure. It consists of a list of capabilities as well as their interactions with each other and functions located outside the scope of the reference architecture. It defines the layers that can help the enterprise better realize the value of SOA by constructing a roadmap from the current state to the target state.
The vendor agnostic SOA Reference Architecture defined by SAP consists of three major building blocks:
- PLAN - Capabilities needed to outline the overall landscape
- BUILD - Capabilities needed to implement SOA
- RUN - Capabilities needed to run and manage the implemented software
- MANAGE - Capabilities that are required across the entire lifecycle (plan build and run)
Now the SOA Reference Architecture doesn’t offer an added value to the customer by definition; but provides the potential to support the systematical build up of your own SOA design, development and deployment, driven by both: business goals as well as IT strategy. In order to refine and instantiate it, SAP applies a use-case driven approach.
One of the most important benefits of SOA is the possibility to develop flexible composite applications on top of an already existing backend application landscape. But what architectural capabilities are needed in order to build up the requested composite? Many customers become already at this early stage very confused as there is a broad range of technologies available which offer the possibility and are needed to develop a composite application. In-depth knowledge is required to choose the right capabilities to solve a particular problem. For customers who are pretty new to the SOA topic, this is a huge challenge and it even sometimes makes it impossible to deliver a consistent IT blueprint.
Based on a long-term evaluation as well as multiple projects in various industries, SAP extracted and consolidated so called SOA Process Patterns. Needed architectural capabilities to meet particular business needs are derived from those patterns. Based on business requirements, vendor neutral SOA capabilities are discovered and then mapped to SAP specific deliverables and offerings that accelerate the respective composite application implementation. E.g. a bill of material with the needed SAP solutions or a customer showcase for validation purposes. Customers can focus their SOA deployment on their real business needs and on a minimal set of SOA capabilities.
One example of a SOA Process Pattern is the “Role-based UI & Backend”. It leverages composite applications used for optimizing user interaction. It focuses on the creation of tailored user interfaces for specific user roles and leverages the decoupling of interface from implementation.
This is the beginning of a series of weblogs, where I want to provide more details on SOA Reference Architecture as well as minimal landscapes derived from SOA Patterns. Stay tuned!
- SOA Reference Architecture Part II – Definition of SOA capabilities in detail
- SOA Reference Architecture Part III – Minimal Landscapes based on SOA Patterns (Examples)
