In a direct comparison of the two approaches, a few differences are apparent. An SOA focuses on greater flexibility: it must be possible to adapt organizations and processes quickly, and the IT must be able to react quickly to new business requirements. The SOA should help an enterprise to reuse software, or reduce the total cost of ownership (TCO). For example, in an SOA, the effects on the organization, processes, and IT must be known at a very early stage for reasons relating to the time to market. Models that can be simulated as early as the analysis phase are more important compared to a normal application.
Another important difference arises from the aim of achieving greater integration enablement for the components that are to be created while at the same time integrating as many existing components as possible. This requires standardization of the component interfaces on the one hand and on the other, high service liquidity, that is the maximum possible number of services, both internal and external.
The life cycle of an SOA-based development is divided into five steps:
1. The model phase
Every analyzed business process – for example in the credit advice process – has to be modeled, simulated, and improved. The model phase therefore starts with the definition and analysis of business requirements: the actual and target situation, and the features of this such as throughput time, costs, error rates, existing or missing functions. The results of this analysis are used as the starting point for developing the required services with their service level features. This can lead to decisions to change the service granularities or include external services, for example. Many enterprises aim to be able to respond quickly to changes. Within this phase, it is therefore important to develop a precise model that can be used to create a simulation at an early stage and shows all effects. This enables errors to be avoided and changes to be included in a flexible way.
If a product developer wants to implement an innovative idea, for example, he or she creates a process model for the SOA-based application alongside the usual classic market analyses. This process model is based on assumptions and initially takes account of effects on the process structure and organizational plan as well as the IT infrastructure. This model and the corresponding simulations make it much easier to ascertain how economical a process is or whether it can be implemented from a technical perspective. Existing and new service components are brought together in the implementation. Once in operation, the process can be controlled and monitored from the business perspective and the IT process level perspective. The model can be investigated at any time using the defined critical factors for success, and optimized if necessary. The monitoring information obtained – both of a functional and technical nature, such as throughput times, costs, availability of the technical components, or the fulfillment level in the event of service level agreements – flow back into the model so that the process can be continuously improved. The process and model therefore continuously influence each other.
2. The assemble phase
In this phase, new services, such as the required credit standing scoring, for example, are created or compiled from existing components such as CRM and financial systems, settlement systems, or other components. Once available, these services can be incorporated at any point along a process model. As a result, a store of services, known as a repository, is an important element for publishing and finding services in this phase. To ensure process flexibility that meets all requirements, it is necessary to determine whether the process is to be programmed in the classical way or executed by a process machine on a model basis. The more likely it is that there will be subsequent changes, the more efficient it is to use the model-based approach for an SOA.
Integration enablement, an important aspect in this phase, is very much related to the subject of standardization. Functional and technical standardization are central points for integration enablement and thus the element of reusability. Open and above all globally recognized standards such as Web Service Definition Language (WSDL) or Business Process Execution Language (BPEL) considerably ease cross-enterprise or even just cross-area integration. Standardization also has a positive effect on test expenses, as it reduces the functional redundancy and thus also the complexity of the tests, so tests can be carried out more effectively.
3. The deployment phase
During the deployment phase, the developers configure the runtime environment so that the service level required by the process with regard to factors such as availability, throughput, response times, or restart after a failure can be met. This means that the operational model is implemented and the required resources – computer performance, memory, or network capacity – are installed or assigned. A major challenge in this phase is the creation and maintenance of an integration infrastructure – for example a portal, enterprise service bus, or process engine – which can be used to integrate people, processes, and information quickly and easily. These infrastructures have a considerable effect on both the speed of development and the service quality. They can therefore be compared to the transaction monitors of today’s legacy systems, which form the nerve system of many modern core applications. The virtualization of the required resources also plays an important role in the design of flexible system infrastructures, enabling the required resources to be made available on demand, so that additional resources such as computer, memory, or network capacity can be made available automatically for important processes in the event of bottlenecks or errors, for example.
4. The manage phase
The main element of the manage phase is to meet availability requirements and other non-functional service requirements, such as throughput times, error rates, or costs. Key performance indicators are monitored to prevent both functional problems such as organizational bottlenecks and technical difficulties such as insufficient computer capacities, or at least to identify and rectify such problems. If the fulfillment level for the business processes is continuously measured, this information can be fed back into the business process model and the necessary adjustments can be made in a targeted way. This gives rise to an ongoing learning process that helps to improve the business processes over the long term.
A functioning governance model has always been a critical factor for the success of every enterprise. This is even more true with an SOA approach, because the componentization based on functional standardization and the integration required as a result of this increase the demand for end-to-end management systems and clearly defined framework conditions. To achieve this aim, it is necessary to introduce clear responsibilities as well as quality, measurement, evaluation, and reporting standards within the business areas and IT that match the corporate culture and strategy, because the execution of the required guidelines is not an option but a prerequisite for successful SOA projects. This is the only way to also achieve enterprise targets such as increased sales and profits in the desired scope and period through ongoing innovation.