A maturity assessment allows the key decision makers to evaluate the current state of SOA maturity within their organization. A maturity assessment consists of evaluating the as-is and the to-be levels of the SOA implementation within the enterprise, and then quantifying the gap between the two. There are many ways by which this can be achieved, and there are several maturity models in the market that can be used for this purpose. However, this book recommends that a maturity assessment is conducted using the Oracle SOA Maturity Model along with the Oracle SOA Maturity Model calculation tool that has been provided in conjunction with this book.
The Oracle SOA Maturity Model was designed by Oracle to help the customers to achieve SOA Maturity. Customers evaluate their current state of maturity within their organization and define a roadmap to achieve the target level of maturity. The model consists of five levels. Each level represents a particular state of maturity for an SOA implementation, ranging from ad hoc use of services to a very mature business-focused implementation. In addition, Oracle makes use of eight different capability domains that must be evaluated within each level when defining the maturity of an SOA implementation.
The five levels of the Oracle SOA maturity model defined as follows:
SOA Capability Domains identify the different areas of an Enterprise that have a potential impact on the readiness of the SOA initiatives. The following diagram depicts the eight capability domains covered in the approach:
Capability domains are described as follows:
The SOA Maturity Model calculation tool provided along with this book delivers a robust model with more than 300 capabilities for all capability domains. The tool can be used to quantify the as-is and to-be levels of SOA implementation and to identify the gap between the two. Once all the individual capabilities have been evaluated, the tool will produce a diagram similar to the following:
The outcome of the maturity assessment should be carefully evaluated in order to identify what actions are needed to reduce the gap between the as-is and the to-be (target) SOA implementations. Once all actions and their dependencies have been identified, these should be used as the foundation to formulate and elaborate an SOA Roadmap.
When elaborating an SOA Roadmap one must ensure that it is comprehensive and easy to interpret. This is because the target audience of the roadmap will be not onlyIT but most importantly the business. If the business fails to understand that roadmap, it is possible that they will raise impediments when or if more funding is needed.
It is also worth highlighting that an SOA Roadmap is not a project plan. The aim of a roadmap is to be broadly right and not accurately wrong. Details are not needed in a roadmap as a project plan can (and probably will) be defined to manage the execution of the different projects.
The following diagram depicts the different aspects that define a comprehensive SOA Roadmap:
This phase underpins the entire governance implementation as it is responsible for elaborating the governance objectives and the Design-time and Runtime Governance assets that are required to implement the Oracle SOA Governance solution.
The following sections enumerates the minimum set of assets that should be delivered as a part of the elaboration of the SOA Governance framework.
These artifacts are created to support the implementation of Design-time Governance. The artifacts are:
The following diagram depicts a conceptual reference architecture as defined in Oracle's reference architecture for SOA (Document ID E15827-03). As can be appreciated from the diagram, the main concerns addressed are enterprise development, interactions, information management, infrastructure, security, and management. There is no mention of what technology should be used.
This sample logical reference architecture specifies among other things that Oracle SOA Suite will be utilized as the main application stack and that Oracle BPEL Process Manager, Oracle Business Rules , Mediator and Technology adapter components within a composite will be used to provide the business processes, business services and application services layers. Furthermore, this architecture implies that Oracle Virtual Machine Server (OVM) will be the core virtualization platform on which Solaris OS instances and WebLogic Servers will be deployed.
These artifacts are created to support the implementation of Runtime Governance. The artifacts are:
Promoting code using tools such as JDeveloper or Eclipse is highly unreliable and not recommended as this approach requires a high degree of manual intervention that can introduce human error.
A runtime deployment framework should standardize and centralize the way code is promoted between all environments. SOA Suite as well as OSB comes with utilities (for example, the ANT utilities or the WSLT scripts) that can be used and extended in order to create a robust deployment solution.
An exception handling framework is a set of runtime component that are built with the sole purpose of standardizing the way exceptions of all types (for example, business faults, systems faults, remote faults, binding faults, composite and BPEL faults, among others) within the SOA Suite 11g or OSB 11g stack are handled, reported and diagnosed. By providing a consistent way of handling exceptions in different scenarios and for different message interactions patterns (for example, synchronous request/reply, asynchronous fire and forget, asynchronous call back, and so on), the complexity of supporting an SOA production system is dramatically reduced.
This phase consists of the implementation of the Oracle SOA Governance solution in combination with the defined design-time and runtime Governance processes and standards. The result of this phase should allow projects to make full use of the SOA Governance framework in order to successfully implement the SOA solutions.
The next section will focus on providing more details on design-time and runtime governance.
Design-time Governance can be defined as the combination of processes, tools,and people needed to support the analysis, design, and build phases of an SOA implementation.
Design-time SOA Governance should support the following project phases and SOA Asset lifecycle activities:
During this phase, as the name suggests, the requirements for the project or project iteration are elaborated. For an SOA project, requirements are usually captured in the form of use cases, requirement backlogs (if following the Agile/Scrum methodology), user stories, and process models (for example, Level 1 to 3 BPMN models).
Requirements are meant to capture, in plain English, what the business expects from a particular solution (a system, a business process or even a single SOA service). Clearly, without properly documented requirements one should never proceed to other phases of the project. Unfortunately, as obvious as this may sound, many projects end up doing exactly this.
Once all the functional and non-functional requirements have been identified, they must be validated, clearly documented, made unambiguous, actionable, measurable, testable, and traceable. Once this has been completed, the process of identifying candidate services to support the required functionality can commence.
For an SOA Asset, this means two things:
The SOA Governance framework should provide templates for service catalog and capability analysis to capture the outcome of this phase. The use of templates can dramatically improve the outcome and quality of this phase as the scope and expectations in terms of content and detail are known upfront.
The output of the analysis phase will include a list of candidate services that will deliver a particular and traceable set of business requirements. The design phase translates these proposed services into actual service designs that are suitable and fit-for-purpose and that deliver the desired business functionality.
When designing a service the following assets are usually delivered:
Service versioning is not to be confused with version control. The latter, also referred to as revision control or source control, is a discipline for managing code throughout the asset lifecycle. For example, a service at Version 1.0 may undergo to several code revisions before it even reaches production. Whereas the service version has a direct impact on the consumers of the service, consumers are unaware of the several code revisions the asset went through.
The following diagram illustrates the different Assets within a service that can be versioned:
Regardless of what asset is being versioned it is fundamental to consider the following principles:
SOA Governance framework artifacts such as architectural principles, reference architectures, and most notably design standards are critical to enforcing the quality of the design phase. Usually design standards deliver rich service taxonomy and a pattern language that can be leveraged to deliver rich functional/technical contracts and service detail designs.
During this phase, services are constructed and unit-tested as per the service design. It is during this phase that the main assets of a service are created (for example, JDeveloper and Eclipse projects, test suites, XSLT or XQUERY transformations, BPEL processes, among others).
Following are some of the assets that are created while implementing a service:
Ensuring that standards such as programming standards, exception handling frameworks, deployment frameworks, and continuous integration frameworks are adopted during the build and unit test phase are crucial to obtain the expected quality of code and to streamline the build and unit test phase.
Runtime governance can be defined as the combination of processes, tools, and people needed to support the deployment, testing, and production support phases of an SOA implementation project.
Runtime SOA Governance should support the following project phases and activities of the SOA Asset lifecycle:
This phase covers the promotion of code between the different environments of the project (for example, development, system integration test, user acceptance test, and so on).
Service deployment is achieved by executing the predefined processes and techniques that are required for deployment SOA Assets between environments. A deployment framework should ideally be employed during this stage, to automatically compile and promote services between environments without having to worry about manually changing the settings, such as environment specific endpoints or internal service dependencies.
The testing phase can be divided into different stages depending on the objectives of the tests being executed. In a typical project the testing phase consists of:
In the SOA Asset lifecycle, the three main activities that take place during each testing stage are:
It is during the test phase of an SOA project that the effectiveness, quality, and robustness of the SOA Governance framework become obvious. Should all the design-time and runtime components of an SOA Governance framework be successfully delivered, and the design-time standards properly enforced during development phases, then the tasks of monitoring and testing the services should be fairly straightforward and the complexity of this stage should be kept to a minimum. This is because the complexity of such tasks should have been hidden by the framework, and the project should be following a script and not trying to reinvent the wheel. For example, a robust testing framework should allow a project to test different types of services (request/reply, fire and forget, call backs, publish/subscribe, and split/join) with the minimum amount of effort. Furthermore, monitoring and troubleshooting tasks should be fairly straightforward, if features such as composite sensors and e-mail notifications were taken into consideration during design-time.
Once a service is promoted into a production environment, it officially enters the support phase. The support phase is most definitely not the end of the service lifecycle, however; in fact, far from it. SOA Governance should also include monitoring of the SOA infrastructure to feedback critical information that can be used to optimize SOA Assets (services and automated processes). For example, BAM dashboards should be employed where it is appropriate to monitor the efficiency of processes. Activities such as service testing, service monitoring, and service improvement should remain active during the operational lifetime of service.
Once a service has served its purpose and has been deprecated or is no longer needed, then the following activity should take place:
As described earlier in the chapter, it is only when the processes and tools are combined with people and appropriate decision making, that the governance is fully realized. Having an accountability and responsibility framework is crucial for people to acknowledge the scope of their duties, and their participation on an SOA implementation.
The diagram describes an accountability framework that mainly consists of two categories of roles:
The accountability framework suggests that the following people and roles are required in order to implement end-to-end design-time and runtime governance:
As can be seen in the preceding diagram, the SOA design authority should encompass all of the capability domains. An SOA design authority group should have well-defined terms of reference and should meet at least biweekly with the objective to cover topics such as SOA pipeline, project issues and status, review and approval of the designs, and definition of roadmaps.