Establishing a center of excellence is not enough to ensure success with your SOA governance and SOA adoption efforts. While governance begins with people, it cannot end there. If all decisions must be made and/or reviewed by the center of excellence, your efforts will not scale as the COE will become a bottleneck for all of your projects.
In order to allow your governance efforts to scale, the people must focus first on establishing policies. Policies are the standards and guidelines that enable the staff executing your SOA projects to make appropriate decisions and achieve the desired behaviors. There are three key timeframes for which policies are necessary:
|In this timeframe, the primary concern is with determining what IT projects
to fund and execute, which is frequently associated with the broader
subject of IT governance. While SOA governance should not introduce new
governance processes associated with deciding what projects to fund and
execute, policies associated with SOA governance should be included in the
criteria. This is the timeframe where the policies must aid in answering the
question, “What are the right services to build?”
|This is also referred to as design-time governance; however, the activities
in this time frame are concerned with much more than solution design. The
policies at this stage must aid in answering the question, “How do I build my
services the right way?”
|Governance does not end when the projects are complete. SOA adoption
can increase the number of moving parts in any given solution, and if
the dependencies aren’t managed appropriately chaos can ensue. You
need to have appropriate run-time policies to ensure the systems behave
appropriately while in use and that the relationships between service
consumers and service providers are managed.
There are key artifacts that can assist in defining policies at this timeframe.
Pre-Project Governance, Continued
|Can influence how funds are distributed in an organization,
and this can be a barrier to SOA adoption. The organization
chart must be leveraged and modified where necessary to
account for clear service ownership and funding approaches. if
the organizational issues aren’t discussed at the time projects
are defined and funded, it can severly hamper the efforts of
the project team.
|Business Process Models,
Capability Models and
|All are closely related. These are analysis artifacts that should
be used to guide the decisions on what services should
be created. Business process models and the application
portfolio provide excellent context on existing applications
and processes, but each on their own runs the risk of focusing
on application silos or process silos. By combining these
two with a capability map against the business domains, in
essence a heat map of business capabilities, the areas where
shared services will provide the most value can more easily be
identified. It is important to do this outside of the context of
|Business Process Models,
Business Domain/Capability Models and Application Portfolio,
|any project, as within a project, there is significant pressure
to constrain analysis efforts and avoid “analysis paralysis.” A
good reference for this approach is the book “Enterprise SOA
Adoption Strategies” by Steve Jones of CapGemini.
|The last artifact is a catalog of services that have been built
and are available in production, but it is much more powerful
when it is used as a planning tool. When the organization
has taken the time to perform business process analysis and
business domain/capability analysis, an outcome should be
the definition of key services that the organization needs to
create to fully leverage SOA.
Policies for Pre-Project Governance
The following are questions/policies that you should consider in your pre-project governance efforts:
|Has the proposed project identified candidate services?
|Has the proposed project mapped candidate services to the business domains as represented in the business domain/capability models?
|Has the proposed project reviewed the service portfolio against the list of candidate services?
|Has an appropriate team of project stakeholders been identified based upon candidate services?
|Has the proposed program/project been appropriately structured and scheduled to properly manage the development and integration of new and existing services?
|Have all funding details been determined based upon the services proposed and the organizations involved?
|Does the roadmap include the development of services with high potential for reuse?
|Are projects encouraged to reuse existing services, where appropriate, based upon the business domain models and business objectives?
|Are projects allowed to create redundancies, where appropriate, based upon the business domain models and business objectives?
|Have existing systems been taken into account in the definition of the proposed services?
|Is the organizational structure being reviewed on a regular basis based upon continued service analysis?
|Does the organization have a clear approach to resolving service ownership models?
|Are business processes properly leveraging services?
|Does your service portfolio properly account for any globalization impact?
|Does the service portfolio properly account for any planned areas for growth by acquisition?
In order to perform project governance, the following artifacts are recommended as sources of policy:
Service technology reference architectureHelps ensure that appropriate technologies are used for the service being developed. It should first define the appropriateservice types for the organization and then map those types to specific service technologies. Service types can include:
|These are services that are built by combining the output of two or
more services and aggregating the respective responses into a single
|These are services that are built by executing a fully automated
sequence of actions as represented in a graphical process model.
|These are services whose purpose is to enable a system that does not
support service standards to speak with service consumers.
|These are services that provide information in a presentation-friendly
format, providing information in such a way that it is easily consumed by
user interface technologies.
Service Technology Reference Architechture, Continued
|These are services that expose management and administrative
functionality. There are technologies, such as SNMP, JMX, and WSManagement
that have been tailored for this purpose.
|These are services that are used to retrieve information from a variety
of data sources, aggregating the results into a single response. These
services differ from composite services in that they are specifically
designed to talk only to data sources on the back end, rather than any
arbitrary web service.
|These are services that provide content feeds, typically adhering to feed
syndication standards such as RSS and ATOM.
|This is a catch-all category for any service that doesn’t fit into any of the
These service types are mapped to service technologies, defining both the service platform as well as the servicecommunication technologies. The service platformdefines where the service implementation will be hosted and executed, such as a Java Application Server or a BPEL orchestration platform, while the service communication technology defines the message formats and thecommunication technologies used to interact with the service, such as XML, SOAP, and HTTP. The mapping effort links service types to technologies.
The service technology reference architecture must also rovide policies on how the non-functional capabilities associated with services interactions will be provided by the underlying infrastructure. This includes:
- Routing and load balancing
- Transport and mediation
- High availability and failover
- Monitoring and management
- Versioning and transformations
These non-functional capabilities should be enforced through policy-driven infrastructure that is configured, rather than coded.
These non-functional capabilities are a key aspect of SOA, because they are the foundation of run-time governance. At the same time, they must be factored into the design-time decisions, because if the development teams don’t utilize the technology appropriately, the ability to enforce run-time governance policies will disappear.
Service security reference architecture The next artifact is the service security reference architecture. This can be included as a subset of the Service Technology Reference Architecture, or created as a standalone artifact. Regardless of the approach, there are two questions that must be answered by the reference architecture. What security policies must be enforced? What technologies are used for enforcing those policies?
Service Security Reference Architecture, Continued
These questions must guide the developers of services and their consumers on security policies for authentication, authorization, encryption, digital signatures, and threat prevention. This includes how identity is represented on messages, how it flows through a chain of service invocations, how and where authorization decisions are made, what type of data should be encrypted and where it should be encrypted, how and where incoming and outgoing messages are checked for potentially malicious content, and more.
Service blueprints and frameworks
Service blueprints are examples of common patterns that demonstrate a policy-compliant way of solving a particular problem. Their use can make the collection of policies associated with a reference architecture must less daunting to a project team. Common patterns may include integration scenarios with legacy systems, exposing services to external parties, and consuming services provided by external parties.
Service frameworks are reusable libraries that, when used, allow implementations to be compliant with the policies of the organization, such as using the correct security credentials on service messages. Compliance is easiest when it is the path of least resistance, and making it so a developer only needs to write one or two lines of code, or even none, can make that happen.
Standard information models and schemas
Standard information models and schemas do not present one universal representation that everyone agrees on, because it probably doesn’t exist. Rather, they ensure consistency in the way information is represented, minimizing the number of representations. Industry verticals, such as SWIFT (financial services), HIPAA (healthcare), and ACORD (insurance), can be leveraged as starting points, and are likely required when exposing services externally.
Policies for project governance
The following are questions/policies that you should consider in your project governance efforts, in addition to all those that were specified in the pre-project governance if not enforced at that time:
|Policies for project governance
|Have all services been mapped to an appropriate type?
|Are the service technologies chosen for each service consistent with the type to technology mapping specified in the reference architecture?
|Does the service use the standard communication technologies specified in the reference architecture?
|Does the service interface comply with all naming conventions for URLs as specified in the reference architecture?
|Does the service interface properly reference all external schema definitions, rather than copying them locally?
|Does the service interface use the standard schema definitions properly?
|Do external facing services only expose industry standard schemas, where they exist?
|Is the service interface compliant with industry standards, such as WS-I?
|Does the service require identity on its messages?
|Are all service consumers properly specifying identity on outgoing requests?
|Have appropriate authorization policies been established for the service?
|Is the service communication infrastructure being leveraged appropriately?
|Are all internal consumers properly leveraging the standard service frameworks?
|Is all sensitive information properly encrypted according to the service security policies?
Policies for Project Governance, Continued
|Have service contracts been established between all consumers and providers?
|Are all aspects of the service contract fully specified including message schemas, versions,
delivery schedule, points of contact, and expected usage rates?
|Have all services been thoroughly and adequately tested, with testing results available to service consumers, if required by the service contract? For internal consumers, testing results
should always be available to help counter the natural tendency for developers to resist using things they didn’t personally write.
|Have service managers been assigned for all new services?
|Are the service boundaries identified in the solution consistent with the business domain models?
|Has the solution incorporated existing services appropriately?
|Has the solution properly published information about new services into the Service Registry/ Repository?
|Has the solution avoided creating redundant services where not appropriate according to the business domain models?