The SOA governance lifecycle

SOA governance relates to all activities which are not immediately required to build working services, but to increase overall quality of the SOA and to enable control in complex environments. This relates:

• People – Making sure that responsibilities are put in the right location, and that people are trained to have the necessary knowledge and capabilities.
• Processes – Making sure the right processes are in place for quality assurance and monitoring of services.
• Products – Setting requirements for services and their documentation; policies are a common example, but also templates for service documentation fall into this category.

We have addressed these topics in a SOA governance lifecycle model. This model defines six main processes which need to be executed to perform good SOA governance. The lifecycle represents one iteration, a scoped project to achieve a concrete goal in implementing a Service Oriented Architecture. SOA development takes place in many iterations of the SOA governance lifecycle. Through these iterations, the maturity level can (and should) increase.

The first two processes have a focus on the business, where the SOA vision and organizational impact is addressed. The next three processes form the focus of architects: service portfolio management, service lifecycle management and service portfolio management. The final process, service level management, is on the system administrator’s domain. However, all parties active in SOA governance should be involved in the entire lifecycle. How these parties are involved is described for each of the SOA governance lifecycle processes.

Vision on SOA

The first part of an iteration is to formulate long term goals for SOA, or to revise existing ones. This process specifies the organization’s perspective on SOA, but also the goals set for the current iteration on the lifecycle. The vision on SOA is a product of business and IT, where alignment is facilitated by the architect.

Creating the SOA organization

In this process the roles and responsibilities for SOA governance are defined. Often this leads to the initiation of some kind of SOA governance board (or Center of Excellence). This board should represent the stakeholders of SOA governance; from business and from IT. The SOA governance board decides on how the SOA governance lifecycle is implemented. Some guidelines are given later in this article. For the execution of the current lifecycle iteration, the right people need to be in the right place. This may not only require some extra training, also funding or incentive programmes are possible activities in this process. The SOA governance board should improve adoption of SOA principles by imposing standards and advocating SOA principles in the organization

Service portfolio management

Together with business representatives, consensus is needed about the services that will be developed. The architect should weigh IT arguments against business arguments for developing specific services. By being involved in portfolio management from the start, the architect should be able to point out services that are suitable for reuse and are therefore preferred to be developed early on. A services roadmap, listing current and planned services, is a possible product of service portfolio management.

Service lifecycle management

This process addresses the implementation, updates and retirement of enterprise services. Lifecycle management should not be addressed in projects, but is something to be done by the SOA governance board, where changes to the SOA are managed. Changes to SOA relate to conceptual, enterprise-wide services, which are reused and perform a business function. The architects in the SOA governance board should help in ensuring that all services are in scope of lifecycle management, to prevent the presence of ungoverned services.

Policy enforcement

This process concerns the design and enforcement of policies. For example, the architect needs to make sure that people are posting their services in the repository, so that these services are governed and can be reused. Attention also needs to be spent by the architect on policies applied at design level. Design level policies are standards on the development of services, and usually take the form of principles or best practices. In contrast to run-time policies, design-time policies usually cannot be monitored automatically. Therefore, developers need to be convinced that they should adhere to standards. Architects should review the delivery of new enterprise services, and in this review adoption of design time policies should take an important place.

Service level management

SOA requires different service level management than other IT architectures, because of the finer granularity of services, compared to applications. Also, the flexible consumption of services developed by others requires good understanding of service levels by consumers. Service level management is a task of system administrators, but architects should listen to the responses on service levels, in order to discuss with the business whether the levels are still suitable for the business users. Also, by reviewing the use of services (possible with registry tools), possibilities for service reuse can be found.

Using the lifecycle to increase maturity OF SOA Governance

The processes in the proposed SOA governance lifecycle can be very helpful in combination with a maturity model. There have been numerous publications about (SOA) maturity models; basically any maturity model can be used in combination with a SOA governance lifecycle. The maturity levels need to have some kind of specification of what to expect from SOA governance in each stage. This can be done through a matrix where the scope of the SOA Governance lifecycle processes is determined for each maturity level. In the example below we have used the Deloitte Business Maturity Model[ii]. This model was derived from best practices and interviews and relates to the scope of SOA governance. It argues that maturity should be equalized amongst subjects, in order to achieve benefits from a mature process. Although it was not developed with SOA in mind, we think that the organizational scope is a good indicator for requirements on SOA governance.

• Pioneer– SOA consists of small-scaled projects, meant to offer flexibility to determine the best practice. These efforts are often quick-wins and incur a low organizational complexity. SOA Governance is minimal, and focuses on the scope of the project. As there is usually one owner of the SOA, control is not very complicated.
• Process– here an organizational unit, product or process is fully committed to SOA. Often SOA is implemented with a specific purpose, e.g. inventory management. One owner is in the lead here, and funds the majority of the SOA. However, the architecture is related with IT elsewhere in the organization, so SOA governance needs to be agreed upon with other parties. This leads to an increased governance demand, as there are more people involved.
• System– Here the SOA is controlled by multiple business owners. This means that support at CxO level is needed, and SOA governance needs to become centralized. SOA governance dictates standards for consequent implementation of SOA in all parts of the organization.
• Network– SOA is coordinated by different, actively involved, organizations. These organizations provide services for each other, which are connected to support end-to-end business processes. This means that SOA governance between these parties needs to be aligned. Without proper governance, service changes will have a major and unpredicted impact on the business operations.

In the table below, some hints are given on the changing requirements on SOA governance lifecycle stages for each maturity level. These are not necessary steps, but possible ways of improving SOA governance along the way. These hints can be used in similar matrices with other maturity models. The advantage of having such a matrix is that it forms a simple overview of the development path of SOA governance. This can also provide the organization with a kind of “health check” concerning the maturity level of SOA.

Table 1: Scope for governance processes related to maturity levels

Using maturity to develop a growing SOA

Besides changes in the SOA lifecycle processes, increased maturity also changes the impact of SOA in the organization. In the model below, this transition between governance maturity levels is displayed. It shows that in the first maturity level we cannot speak of “one SOA” in an organization. Different small-scale service oriented solutions are built and governed separately. In order to achieve more enterprise-wide benefits, governance on these pioneer SOA’s is grouped. These groups can be made by business processes, as suggested by the name of the process maturity level, but a division by business unit or geographic region is possible as well. As the SOA becomes an enterprise wide solution, the governance is aligned into one central governance model. Even the system governance control sphere shows borders, meaning that there it is possible to extend governance on specific parts. In the final maturity level, governance control is aligned with network partners. Governance boards from different organizations may meet and frameworks and methodologies can be shared and aligned to each other.

Figure 1 - The SOA governance lifecycle continues, as SOA control spheres are maturing

There may be different SOA projects in an organization at the same time. One SOA may be at a more mature level than another SOA. Multiple SOA domains may be developed and governed separately. When they have matured, they can be incorporated with another SOA control sphere. Based on function, process or organizational unit, the maturity level may vary. For example, the purchasing department may show network maturity level features, by incorporating services from suppliers and setting standards for service development lifecycles. At the same time, HR may still be using its own governance structure from a lower maturity level. This may not be a bad thing; isolated environments can have separate governance.

On the other hand, the maturity within a SOA domain (or control sphere, in governance terms) needs to be equalized between governance processes. For example, governance of the service lifecycle should be consistent with policy enforcement, because immature enforcement will not work in a complex, more mature environment.

This then relates back to the SOA governance lifecycle. In the “Vision on SOA” process, the purpose and maturity goal for SOA governance should be determined. An organization can then have a system levelSOA governance board, but standardization can also exist on smaller scale by domain architects. This helps in making SOA governance efficient and fit for its purpose. Tailor-made governance is also more likely to be effective, system level boards do not have to discuss issues that are only relevant in one control sphere.

Guidelines for architects in a maturing SOA Governance environment

Architects are important initiators of SOA efforts within an enterprise, and remain important as they typically have the best overview and are able to see practical implications, but can at the same time also act from a strategic vision. Architects are also important communicators between IT and business. Because of this strong position, architects find themselves in a position where they advocate the SOA paradigm within an enterprise. However, not all architects are suited for all SOA related activities.

Based on the above maturity model, we will give some practical guidelines for architects to allow them to help the enterprise to maximize the SOA potential at the current maturity level and also supports them in advancing the SOA maturity level. Since there are many types of architects, with different responsibilities, we will first give an overview of relevant architect roles in SOA environments. For this we will stick to the practical list of architecture roles, introduced by Mike Kavis[iii].

• The chief architect connects these SOA architects, and is responsible for answering the CxO’s. The chief architect is obviously involved in deciding the SOA vision, but should also point out the direction of SOA governance.
• The enterprise architect role should align business and IT requirements in SOA. This type of architect talks with the business to obtain requirements. Enterprise architects are strongly involved in managing the service portfolio.
• Solution architects have hands-on technical experience. They can be SOA advocates, because of technological advantages of service orientated technology.
• The domain architects have contextual knowledge of the business domain they are involved in. The architect should advocate principles and relate them to the business situation. Domain architects are good candidates for setting standards and to decide when exceptions to the standards can be made.

The table below shows some possible focus areas of architects for each of the maturity levels. We have added the architecture board, which consists of different architect roles, and serves as the body responsible for making long-term decisions on architecture in an organization. As we focus on governance, the responsibilities of the architecture roles are different than during the design of SOAs.

 An overview of the focus of these roles by maturity level is displayed in the table below.

Table 2: Focus of architect roles in different SOA maturity levels

Conclusion

In this article, we addressed the issue of SOA governance in relation to its maturity. This was done by:

• A framework of main processes that SOA governance should relate to
• Using a maturity model, and linking this to all SOA governance processes
• A description of how we think architects should be involved in SOA governance processes

The responsibilities of architects in these efforts are not fixed. We provided some practical guidelines on how architects can lead or provide support at the various processes of the lifecycle and maturity levels. Architects need to address different governance issues in different maturity levels, therefore the demands and required qualities and skills of the architect change with the level of maturity. Also, the guidelines as given in this article are by no means universal. The expectations of architects will be different in each situation.

Architects are good initiators of SOA projects and they can take responsibility for the first maturing of SOA and its governance within an organization. However, for SOA solutions and governance to mature, business needs to take control. The architect shares responsibilities n the governance board with business and IT representatives. Perhaps the most important responsibility for the architect is the alignment of business and IT and this requires special communication and coordination skills. When business and architects have a good understanding and agreements, codified by governance, SOA can go the extra mile and realize all the business benefits promised to the enterprise.

If you want more information on this topic, feel free to contact us at tschepers@deloitte.nl and bkratz@deloitte.nl.

References