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:
Opportunistic: SOA implementation focuses on quick win projects and service enabling some applications. At this level, it is expected that the IT department starts to get familiar with the service orientation by consuming and exposing services. At this level, business benefits are measured from small wins such as the reusability of some business logic that is embedded in a legacy system. This reuse saves on the acquisition or development of a new application.
Systematic: Service orientation is considered as a fundamental building block of the solution architecture for projects. SOA standards are introduced and there is more focus on the governance and service lifecycle. Reuse of assets becomes a fundamental aspect of the SOA implementation. With the increased number of SOA projects being commissioned, reuse of the SOA Assets can bring considerable benefits to the business in the form of cost savings in the development effort.
Enterprise: SOA strategy is now fully aligned to the business and is focused on enabling the business processes layer. Business process implementers can benefit from a broad catalogue of SOA services. SOA implementation is governed by the enterprise architecture, meaning that SOA spreads across the entire organization; it is no longer perceived as an IT department tool. SOA Governance implementation is central and a priority in implementing an IT strategy.
Measured: Process optimization and reporting become central to the SOA strategy. SOA can be measured in terms of key process indicators (KPI) and business intelligence (BI) reports that are able to drive the business process improvement. Furthermore, asset reuse (not only services but also processes) delivers considerable measurable benefits to the business.
Industrialized: SOA and BPM initiatives can deliver rapid and cost-effective solutions to the business. Event-driven technologies such as complex event processing are used to automate and self-optimize applications. Business relies on SOA and BPM to operate and to continuously improve.
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:
Business goals and strategy:
Defines the capabilities that provide the high-level constructs that allow the SOA initiative to proceed. This includes things such as business motivation, expected benefits, guiding principles, expected costs, funding model, and so on.
A key aspect of this domain is the identification of success drivers that can be used as metrics to measure success.
Architecture:
Infrastructure:
Defines the capabilities concerning the service infrastructure and tools that provide the technical foundation for the SOA initiative.
This domain defines the platform required to enable different views of the defined architecture (for example, integration, business services, data services, monitoring, among others) and also the topologies required to guarantee operation continuity (for example, high-availability topologies, disaster recovery, and grid, among others).
Information:
Defines the capabilities concerning the information aspects of SOA, for example, providing Information as a Service (IaaS). This includes shared data models, message formats and schemas, master data management, content management, and so on.
This domain also provides the definitions of canonical models and other data structures used across the SOA initiative.
Operations, administration, and management:
Project portfolios and services:
Organization:
Defines the capabilities concerning the development of corporate competency around SOA, including the organizational structure and skills development.
SOA is still seen in many organizations as a new technology and many users lack proper understanding and training around the SOA principles.
This domain should focus on providing the means to allow the relevant staff to embrace the technology by understanding its potential and the ability to utilize SOA proactively.
Governance:
Defines the capabilities concerning the governance structures and processes that support and guide the SOA effort. Maturity and adoption of an adequate amount of governance are a leading indicator of the overall SOA success.
Governance enables the enterprise to enforce the policies that will allow the SOA initiative to mature in each of the eight domains.
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:
SOA architecture principles: Lists the underlying tenets, restrictions that must be observed, and preconceived views that will guide the service approach, selection, design, governance, and ultimately the operations.
SOA reference architecture: It defines the different components or building blocks that shape the SOA landscape of an enterprise. Reference architectures can be defined to address one or multiple areas of IT (for example, SOA, business architecture, security architecture, and others). Usually reference architectures are defined in 3 levels of abstraction: Conceptual, Logical, and Physical.
Conceptual reference architecture: Describes the concepts and components that build up an architecture at the highest level of abstraction. A conceptual reference architecture does not specify what technology is used or how it is implemented. Instead its purpose is to structurally identify what concerns should be addressed by IT and what the relationship between these concerns is.
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.
Logical reference architecture: This architecture defines at a high level what technology is used in order to address the different concerns described in the conceptual reference architecture. Sometimes this architecture is also referred to as a vendor-specific architecture because it starts to introduce vendor preferred technology stacks. The following diagram provides a sample logical architecture for the Oracle SOA stack:
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.
Physical reference architecture: This architecture is a detailed architecture that represents how the different applications within the logical architecture are to be implemented. Because each application can have a very complex implementation view, it is recommended that different physical reference architectures are delivered for each application stack. For examples of a reference architecture for the SOA Suite 11g please refer to the Oracle Enterprise Deployment Guide: http://docs.oracle.com/cd/E23943_01/core.1111/e12036/intro.htm.
SOA development standards: It defines the end-to-end software development lifecycle for the delivery of SOA Assets. Development standards should cover in some detail the end-to-end software development lifecycle including all the different assets that should be produced throughout the different phases of the lifecycle. These standards should cover key development issues such as source code management (for example, the use of tools such as subversion) and configuration management (for example, the use of trunk, tags, and branches folders, and all the guidelines to commit code and manage the line of development).
SOA design standards: This document describes the service taxonomy and a pattern language that the designers should adhere to when producing designs for SOA Services. For example, Oracle Application Integration Architecture (AIA) defines five types of services: Application Business Connector Services requestors (ABCSreq), providers (ABCSprov), Enterprise Business Services, Enterprise Business Flows, and Composite Business Services. Furthermore, AIA defines certain design patterns that must be followed when implementing the AIA services. The most common pattern used by AIA is known as VETORO (Validate, Enrich, Transform, Operate, Route, and Operate). This pattern describes how to combine ABCSreq-EBS-EBF or CBP-ABCSprov in order to deliver end-to-end business processes and also defines which design patterns are to be used within each service type. AIA serves as an excellent example as to what should be addressed by the design standards.
SOA programming standards: It defines conventions and rules that the developers should adhere to when constructing an SOA Asset. For example, naming conventions for JDeveloper would include conventions for applications and projects, composites, mediators, and BPEL components. These standards also cover programming guidelines and best practices.
SOA metadata standards: It provides the standards and constraints that a designer and developer must adhere to when creating schemas and other XML artifacts. For example, namespaces, element naming standards, and schema data models should be covered in the metadata standards.
SOA templates: All the SOA deliverables defined in the governance framework should have a corresponding document template. Document templates are very important because they define the content and scope that is expected of an SOA deliverable. Having document templates available means that the project can focus on delivering content and not defining it.
SOA deployment standards: It defines guidelines that that should be followed when releasing/deploying SOA-related artifacts into any environment. Note that these standards will be dependent on how the runtime deployment framework is implemented.
SOA error and exception handling standards: It defines guidelines that should be followed when implementing error and exception handling into the SOA services. Note that these standards will be dependent on how the runtime exception handling framework is implemented.
Security standards: It defines guidelines that should be considered when defining and applying security policies into the SOA services. Note that these standards will be dependent on how the runtime security framework is implemented.
Monitoring and SLA standards: It defines guidelines on the implementation of sensors and business activity, monitoring dashboards into composites and proxy services. These standards become particularly important at runtime as they enhance the search and monitoring capabilities of SOA instances once a service becomes operational.
These artifacts are created to support the implementation of Runtime Governance. The artifacts are:
Deployment framework: Creating a framework of components that standardize the way code is promoted to different environments is extremely important, not only from a configuration management perspective but also from a project point of view. Applications such as Oracle SOA Suite 11g or OSB 11g usually consume services exposed by the external systems within a BPEL or a pipeline flow. These external systems are expressed in the form of URLs that will change from environment to environment and should therefore not be hardcoded into applications.
Tip
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.
Exception handling framework: One of the key success factors of an SOA implementation is the ability of the business as usual team (BAU) or the operations team to be able to support the solution once it has gone into production. Although this depends on many factors (for example, infrastructure, networks, storage, external systems, and so on), it is essential that errors are reported to the appropriate teams quickly and efficiently in order to minimize the risk of disruption to a business. The team running productions systems must be able to conduct root cause analysis and search for errors and logs in order to rapidly diagnose errors.
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.
Continuous integration framework: Ensuring that the code stored in the code repositories is always working and testable is one of the golden rules of continuous integration. By implementing tools such as Jenkins (http://jenkins-ci.org/) or Cruise Control (http://cruisecontrol.sourceforge.net/) to support continuous integration efforts in the SOA development lifecycle, the quality of the code, and the speed of delivery can improve dramatically. Having such components in a governance framework means that projects delivering SOA will have to align to the practices and guidelines specified, resulting in better-quality solutions and a faster delivery.
Testing framework: Testing SOA Suite composites, OSB proxy and business services is not an easy task. Testing teams are not necessarily subject matter experts in the Oracle stack and, therefore, it is imperative that they are able to utilize standardized solutions to test the web services. There are several tools available that can help automate the testing of SOA services. Some of the most popular ones are:
SoapUI: It is a Java functional testing tool that allows creating and executing automated functional, regression, compliance, and loading tests against web services. SoapUI supports several protocols and technologies. For more information refer to http://www.soapui.org/.
Test Suite: It provides an automated test suite framework for creating and running repeatable tests on an SOA composite application. For more information refer to http://docs.oracle.com/cd/E28280_01/dev.1111/e10224/bp_testsuite.htm.
Code Compliance Inspector (CII): It is a JDeveloper add-on that checks for good coding practices in SOA Suite projects. More information is available in Chapter 3, Introduction To Oracle Enterprise Repository.
Provisioning framework: This often-forgotten component of a framework is, without doubt, one of the main reasons why projects fail to deliver on time and to budget. Manually installing and configuring an Oracle Fusion Middleware application such as Oracle SOA Suite 11g can be very complex and can take several days. Furthermore, all installations are manually executed, increasing the chance of human error. Furthermore, ideally the installation should be easily reproducible for creating further environments with identical topologies. Human error and configuration problems can be the cause of severe delays when testing code, as it becomes extremely difficult to identify the root cause of issues. To avoid such issues and the many others that can result in a poor infrastructure configuration management, a framework should be constructed to automate software installation. The framework should make use of response files, WebLogic Scripting Tool (WLST), and scripting languages (such as ANT) to automate the installation and configuration of Oracle Fusion Middleware (FM) applications. Oracle FM provides several features and APIs that makes this task feasible, and the benefits of having such a component framework in a governance framework can be considerable.
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:
Service discovery: This crucial phase of an SOA Asset lifecycle consists of identifying the SOA capabilities that are required in order to deliver a particular requirement, or set of requirements.
Service cataloging: During service discovery all defined capabilities should be classified and mapped to the existing SOA Assets where possible. This process is defined as service cataloging. For example, if a new capability is needed and there isn't an existing asset that could be used or extended, then a new potential service is identified and should classified as a proposed service. This process is repeated many times during this phase, meaning that the list of services will grow. A normalization exercise should then take place in order to avoid duplication of services and inconsistencies.
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:
Functional contract: A functional contract is a document asset that defines the functionality that the service should deliver and the desired non-functional requirements such as service ownership, service-level agreements (SLAs), and service operational requirements (such as service availability).
Technical contract: The technical contract defines signature (data elements that are needed in order to consume the service), protocols (for example, what binding will be used such as SOAP binding over HTTP) and policies (for example, message security or MTOM for sending attachments). A technical contract is usually defined during detail design and is reflected in the design document as well as in the WSDL and schema of the service.
Service detail design: Contains a component and sequence diagram that describes the static and dynamic views of the service. A static view defines the SOA composites and SCA components required for a particular service. The dynamic view shows how the information flows between the composites, what manipulation takes place to the data (for example, transformation) and what orchestration is required (for example, in BPEL). A detail design should also cover the definition of the technical contract that encompasses definition of data mappings, WSDL and schemas definition, and unit test scripts.
Service versioning: Versioning is a critical and fundamental activity required when designing services. Having the correct versioning strategy in place is critical for the success of an SOA implementation. All existing and/or identified assets should be subject to versioning.
Tip
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:
Minor versions: A minor version usually represents a change to a service that is backward-and-forward compatible. Minor versions are usually represented with decimals. For example, in an XSD of Version 2.1, the decimal (1) represents the minor version.
Major versions: A major version of an asset represents a change to a service that breaks backward and/or forward compatibility. Major versions are usually represented with digits. For example, in an XSD of Version 2.1, the digit (2) represents the major version.
Terms of service: A contract that formalizes the terms and conditions under which a service is provided and consumed. This will convey how clients and service providers deal with versions. For example, a term of service that communicates only three versions of a service that will be available—preview, current, and prior—and that clients are expected to move from prior to either current or preview within 1 year of the current service becoming prior.
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:
JDeveloper and/or Eclipse Projects (for OSB).
Composites.
Business Services and Proxy Services (for OSB).
XSD Schemas.
WSDLs.
XSLT's transformations.
Test Suites (for SOA Suite only) or SoapUI projects.
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:
System test: Targeted at testing the integrity of the system in isolation
System integration test: Focused on testing that all of the systems in context can in fact interoperate with each other to deliver the required functionality
User acceptance test: Business-driven test for business users to assert that the system delivers the desired business functionality
Performance testing: The non-functional requirements to ensure that the system can handle the amount of usage that is expected once the system goes live
In the SOA Asset lifecycle, the three main activities that take place during each testing stage are:
Service monitoring: This stage of the lifecycle spans across different stages of the project and its purpose is to ensure that all the services and core infrastructure components are fully operational and performing satisfactorily. This stage is also responsible for identifying any errors or issues that may arise as part of the monitoring process.
Service testing: Utilizes available testing tools in order to ensure that the developed services are deployed into the SOA infrastructure, and that they fully address the business and technical requirements.
Service improvement: Sourced from the outcomes of the service monitoring and service testing activities, this stage is responsible for implementing the changes that are required in order to ensure that the SOA infrastructure and/or the SOA services deliver the expected functional and non-functional requirements. Although this phase is really an extension of the service implementation phase, it is separated from it as the required tasks are executed by separate teams whose main responsibility is to apply bug fixes to the code and optimize system configuration settings.
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:
Service retirement: Service retirement encompasses more than just disabling and undeploying a service. It also covers the process of managing dependencies to ensure that no other systems, applications, processes, or services are negatively affected by the retirement of the service. This task can become quite complex, especially if for whatever reason it is not clear who the service consumers are, or what functionality is exposed. All of these dependencies should be properly managed in order to ensure that the business is unaffected during a retirement exercise.
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:
Owner: Responsible for the execution of a task (the creation and maintenance of an asset, or the execution of a task) and accountable for its proper execution
Contributor: Collaborates towards the execution of a task (the creation and maintenance of an asset or the execution of a task); however, does not share accountability for the results realized from it
The accountability framework suggests that the following people and roles are required in order to implement end-to-end design-time and runtime governance:
C-Level executive sponsors: Although not depicted in the diagram, C-Level sponsorship is imperative in any SOA implementation. Having the right level of sponsorship will ensure that the organizational, behavioral, and cultural changes needed to implement the governance processes and procedures are embraced by the enterprise and not ignored.
Functional/Business analyst: Responsible for producing suitable functional requirements such as functional design document, future process model, and/or business rules catalog. The functional analyst should, among other things, engage with the business to ensure that all the functional requirements are well understood and with the technical and solution architects to ensure that the requirements are presented in an appropriate format.
Enterprise architect: An enterprise architect is responsible for ensuring that the solution being delivered by the project not only delivers to the desired business goals and can be successfully traced back to its original requirements, but also that the overall solution aligns to the wider enterprise strategies and standards.
Solution architect: Solution architects are responsible for producing Solution architectures, capturing the non-functional requirements and also ensuring that the functional requirements are consistent with the solution as defined in the solution architecture. The solution architect may also participate and/or influence the definition of detailed designs, and may take part in the approval or rejection of these documents. Note that this is a well established role and this text only aims to provide a brief overview of the role.
SOA architect: The SOA architect is a subject matter expert (SME) in the technologies in context (for example Oracle SOA Suite 11g) but also understands and practices general architecture principles. The role of the SOA architect is to:
Analyze all of the requirements and ensure that these conform to the expected level of quality.
Discover and catalog the SOA Assets and ensure that these can be backward or forward traceable.
Provide technical leadership and guidance to the design and development teams.
SOA designer: Responsible for providing suitable detailed designs that successfully deliver all of the desire business and technical functionally. The designer is also responsible for providing further clarification and guidance to the development teams. An SOA designer will also the create XML assets such as WSDLs and schemas, and define the unit test scripts that should be executed by the developer.
SOA developer: Responsible for building and unit testing SOA services. The developer is also responsible for packaging the code ready for release, and for producing any relevant documentation that is required to support the deployment of the code (such as release notes). The SOA developer may partially contribute to the deployment and monitoring of services.
SOA testers: Test teams are responsible for defining and executing the test scripts to support different testing stages (for example, system test, system integration test, user acceptance test, performance test, among others).
SOA support specialist: Responsible for the deployment of SOA services between different environments and also monitoring of the SOA infrastructure. Once a service has gone live, the support specialist is also responsible for performing bug fixes and regression testing on the code.
Configuration manager: Owner and gatekeeper of code packs and releases. This role, among other things, coordinates and decides which releases can be promoted between environments.
SOA design authority: Not a single role, but instead a collection of different roles and people that together have delegated authority and shared accountability for creation of design-time and runtime governance frameworks, and the enforcement of these into different phases of a project.
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.