SOA Maturity Cheat Sheet

Version 2.4

Capability → Infrastructure Architecture Information & Analytics Operations Project Execution Finance & Portfolios People & Organization Governance
Maturity
Level ↓
1. Opportunistic - Basic service - Silos of infrastructure, - Low quality data - No operational model - Delivery teams structured - Each business unit funds its own - Development groups siloed by - Realization that Governance is
Build, consume Web infrastructure and tools applications across lines of for services traditionally around projects and services department or logical group a key part of driving SOA
services with support for core business - Rigid, brittle data applications and projects adoption but early on in the
WS standards wsdl, interfaces - Application logic bound - Inventory of current services - Architect collectives execution of the vision
Find low-risk soap, xml - Informal cross application to existing application - Development of services to
small-duration architecture collectives - Departmental, ad hoc specific hardware meet immediate project - No coordinated departmental or - Avoidance of restrictive policies
projects where - Web-service enabled approaches to data deliverables no architectural enterprise-wide business service early on ("do no harm
SOA will show portals - Clear view of enterprise integration, quality and - Application by review and limited reuse portfolio activities in place governance")
greatest value to architecture reporting application QoS consideration
business people - Dedicated management capability no shared - Packaged applications portfolio not - Policies around Infrastructure
tools for applications, - SOA strategy formulated - Monolithic inflexible ability to adapt to - Rapid application yet managed as source of business and technology standards at
HW, OS, DB applications with changing demand, development techniques services corporate level
- SOA infrastructure and minimal separation failure or disaster evaluated for SOA projects
- Transport level security tooling standards in use from data concerns - Projects in project Portfolio - Policies around key industry
for services across one or more - Security, logging and analyzed for application of SOA standards in place, e.g. industry
departments - No appreciation for auditing policies tools XML
- High availability and metadata as a separate captured in code rather
failover (QoS) - Key industry standards architectural concern than using a gateway
capabilities at the identified, e.g. industry solution
application level XML - Rudimentary and non-
repeatable analytics for
- Initial SOA-based decision-making
application reference
architecture defined - No common schema
infrastructure

2
 SOA Maturity Cheat Sheet
Version 2.4

Capability → Infrastructure Architecture Information & Analytics Operations Project Execution Finance & Portfolios People & Organization Governance
Governance
Maturity
Level ↓
2. Systematic - Initial project level use - Enterprise-Wide - Project level recognition - Web Services - Experimental SOA Project - Explicit plan and funding for - Nascent enterprise architecture - Governance with SOA becomes
Integrate services, of ESB and BPEL for Architectural Audit that data is crucial for Management solution Funding enterprise SOA Platform and group with responsibility across effective but it's tailored to
start managing service service integration and Completed SOA success to enable declarative foundation services multiple departments departmental needs
proliferation orchestration policy definition and - Initial list of patterns to
- SOA Roadmap Planning - Data design activities centralized monitoring enable repeatable solutions - Funding in place For implementing - SOA training for development - Policies put into place to ensure
Systematically - Service-level access to Initiated exist for data and enforcement leveraged in projects capabilities defined in SOA and SOA and EA training for delivery of the SOA Roadmap
apply SOA to Information Sources, representation standards roadmap architect communities
existing projects Enterprise Applications - Metrics to measure SOA and canonical formats, - Operational Model for - SOA project methodology - Policies in place to allocate
across through WS standards: adoption and success but are fragmented and Services covering adopted - Shared business services funding - EA Group sells business on EA projects some "seed money" to
departments WSIF, JCA, JMS identified without executive Deployment, policies in place (how the building benefits combine with project-level
mandate maintenance, - Project prioritization in cost of business services are budget to ensure steady
- Initial use of service - Infrastructure and management tune with SOA strategy allocated across projects) - Nascent foundation services progress On SOA Roadmap
registry applications standardization - Some schema/model group formed with remit to
across lines of business to standardization, but - Capacity planning for - Organizational SOA goals, - Funds for training business build and manage foundation/ - Initial Service Lifecycle
- Basic service address efficiency, and limited to processes or services and prioritized list of initial analysts, architects, developers, technical services Governance Policies with
management reduce fragility applications projects, and SOA roadmap operations teams on SOA supporting infrastructure in the
infrastructure for - Some cases in which - People aligned with SOA roles form of registries and
monitoring and - Nascent EA group becomes - Wrapper-style data multiple solutions and - Service ownership model - Inventory of existing cross- and responsibilities repositories
declarative application active in driving SOA in services applications operate in a established organizational services
of runtime policies, e.g. development and business shared environment - Key Metrics to Measure SOA
Message level security communities - Departmental analytics - Some delivery teams - Service portfolio plan covering Success Defined
and warehousing is not - Basic shared QoS organized around services business services, foundation
- Common Enterprise - Service identification, fully cross-process yet capability through services, and data services in place - Runtime Governance of
SOA Platform for interface Definition, policy clustering and enterprise - Service lifecycle governance Services
Service Delivery definition, service - Design has begun on SOA platform in place - Highly usable functionality that
includes foundation development guidelines metadata management can be turned into services - Common IT-decision making
defined solutions at - Registry is utilized during identified as part of the service and related policies that span
technical services such
departmental level project development portfolio plan multiple departments
as messaging,
- Candidate list of conceptual process to find and reuse
transformation, etc
foundation services, existing services and to - Guidelines for choosing projects to - Shared SOA platform funding
business services, and data implement candidate which SOA should be applied policies in place
services identified at services that have already
enterprise level based on been identified in the - Existing project portfolio(s) - Shared business services
existing projects service portfolio plan starting to be analyzed in order to funding policies in place
choose specific projects for
- Scoring framework in place utilizing SOA tools, techniques - Enforcement of platform
to evaluate investments decisions
based on adherence to SOA
Roadmap - Policies in place to ensure
reference architectures are used
- Enterprise SOA Platform in projects
strategy

- Integration & security

reference architectures

- Cookbooks for SOA Tools

3
 SOA Maturity Cheat Sheet
Version 2.4

Capability → Infrastructure Architecture Information & Analytics Operations

Operations Project Execution Finance & Portfolios People & Organization Governance
Maturity
Level ↓
3. Enterprise Reuse - Expanded use of service - Deep understanding of - Data standardization - SLAs, QoS - Understanding of business - Increased Centralized Funding for - Executive buy-in and active - Governance is Efficient
kicks in registry at design time business strategy in IT efforts are active and incorporated into strategy integral part of EA sponsorship of SOA initiatives Realizes vision of shared
and runtime organization driven by EA generally observed at service contracts project execution services Enterprise Wide
Focus on driving enterprise level - Funding for SOA Programs that - Active enterprise architecture
business - Enhanced use of - Strict enforcement of - Composite Application - Documentation of business are required to deliver on SOA group - Governing the execution of
improvement, registry to handle architectural standards - Reference information Management, including processes by business Roadmap SOA Roadmap
automation and versioning, external architecture includes ability to perform analysts - EA group have executive buy-in
change. publication and - Metrics on process metrics for quality and analysis to determine - Funding for reusable service for the role of EA in delivering - Policies in place to ensure EA
discovery variances, changes, service audit the affects of service - Business process & rules development over and above on business strategy group recommendations
reuse tracked outages on business lifecycle governance project costs enacted
- Use of Business Process - Best practices for data processes - Promotion of process-centric
Modeling Tools and - Application blueprints integration available, - Operational policies, SLA - Initial procedures to determine skills in IT communities - Policies in place to measure and
Standards (BPMN, defined and in use perhaps via competency - Advanced service considerations captured what portion of the project should drive up reuse, e.g. incentives
BPDM) center management during service development receive common funding vs. LOB - Ownership of business
- Guidelines for scoring monitoring, alerting, specific funding processes by specific - Cross department architectural,
- Advanced service projects for adherence to - Enterprise vision for logging and application - Mechanisms for creating, individuals, who sit across tooling and platform decisions
management architectural policies and analytics and reporting, of security policies storing, sharing artifacts - Formal cost allocation model for departments, and have executive governed by policies
monitoring, alerting, contribution to enterprise but only partial outside services IT resource usage in operation support for process automation,
logging and application SOA in place implementations - Design, code reviews to improvement and optimization - Enterprise Architecture Group
of security policies - Performance of services drive consistency in service - Funding set aside for SOA center efforts scores projects e.g. Positive,
external to services - Projects scored for - Master data and shared tracked against SLAs implementation of excellence Neutral, Negative based on
adherence to these domain models may - People aligned with SOA roles, their adherence to the
- Performance of services guidelines exist for data or registry - Policy automation for - Extensive use of model- - Support costs of shared services responsibilities and roadmap Enterprise SOA roadmap
tracked against SLAs style hubs in the form allocation of hardware driven tools to capture allocated across projects and
- Clearly defined reference of CDI or PIM resources based on business processes, policies, chargeback mechanism in place - SOA education for business - Complete lifecycle governance
- Metadata Management architecture covering service level metrics & events analysts and project managers for services, processes, and
infrastructure in use applications, information, - Inter-departmental without operator - KPIs defined to track rate of business rules
across one or more technology, security metadata management, intervention - Transition from project- service re-use; Reuse statistics to - SOA training for operations
departments architectures but restricted to XML focused RAD to determine the chargeback to each people - Policies for allocating support
- Operations architecture-driven department costs (operations, enhancement,
- Use of Business Rules - Business policies abstracted - Use of data quality consolidated across development that - Initial formation of knowledge bug fix) of shared services and
Engines For isolating out of application code and metrics some LOBs into a grid encourages reuse - EA community actively managing centers/ SOA center of doing chargeback
policies from captured as business rules environment cross-lob service portfolio excellence
application code and which are available as - Some cross - Best practices leveraged by - Service acquisition policies
enabling easier change services departmental - Operational service level project groups during - Packaged applications buying - Cross-department governance
to business policies warehouses used for metrics fed back into project execution decisions undergo a process of board (part of COE) that set - Data standardization policies
- Models for deciding what cross-departmental service registry to enable evaluation for conformance to policies and monitors their
to repeat (patterns), what to reporting - Best practices captured by SOA strategy and EA enforcement - Policies to ensure that process
developers to assess the
share (service reuse) project groups and owners are empowered
runtime behavior of
amalgamated by the EA - Co-ordination of application - Rewards and incentives for
services and their - Policies to ensure consistency
- Best practices coming group lifecycles to ensure consistency with developers to build and reuse
performance in service implementation
together and being SOA strategy and EA services
characteristics
disseminated - Composite application
patterns and blueprints used - Projects and programs to align - Creativity fostered in IT - Policies to address process
to build composite applications and infrastructure to community to better support variance
applications the milestones and goals of the business requirements
SOA roadmap

4
 SOA Maturity Cheat Sheet
Version 2.4

Capability → Infrastructure Architecture Information & Analytics Operations Project Execution Finance & Portfolios People & Organization
Organization Governance
Maturity
Level ↓
4. Measured Closed- - Business Activity - Substantial project - Data contracts/ - Shared services - Architected Rapid - Procedures to determine what - SOA center of excellence - Governance is pivotal leverage
loop automation Monitoring acceptance of EA practices bindings are tool operations environment Application Development portion of the project should established SOA to increase
infrastructure deployed and contribution to independent, giving utilizes virtualization (ARAD) techniques receive common funding vs. LOB competitiveness
Focus on real- to enable real-time enterprise SOA pluggable integration technologies evaluated to enable specific funding are commonly - Developers across project teams
time business monitoring of services applications to be built by used across enterprise completely on board with - Standards and policies are
and enterprise business - Business processes and their - Ability to detect rogue utilizing architectural composite application adhered to and there are formal
measurement processes and events supporting technologies - General purpose services on the network patterns - Metrics used to determine re-use development exception handling mechanisms
with a view to become modules that can enterprise data services rate of common business services in place
enabling - Federated security be reused for efficiency and are operational, and - All operations across all - Metrics on process changes, - Chief Process Officers/ process
continuous infrastructure to enable recombined for agility cross-process MDM in LOBs run on a single service reuse being - Formal cost allocation model for owners are empowered and - Focus for governance starts to
improvement seamless integration place unified grid, but No measured at both project IT resource usage (people and drive improvements and move to agility and innovation
enterprise-wide. with trading partners - EA a power house for fine-tuning of policies level and enterprise level infrastructure) optimization of business opportunities rather than
growth and alignment - Enterprise data quality for resource sharing and processes ensuring compliance
- Support for Service- automation at SOA tier: load balancing - Best practices for handling - Funding for SOA center of
Component cleansing, matching, process variations in excellence is expanded to account - Monitoring and enforcement of
Architecture (SCA) and correlating, and - Sophisticated exception processes for growth and additional many policies and procedures
Service Data Objects profiling management processes responsibilities are automated, and the cost of
(SDO) in Common in place for dealing with - Event lifecycle governance governance gradually declines
Enterprise SOA - Analytics function is policy violations in place - Service re-use metrics used to
Platform clear enabler for real- decide service and project funding
time and predictive priorities
- Infrastructure for decision-making
handling events sources, - Mechanisms put in place for
routing, transformation, - Using service metrics increasing reuse of services in
filtering, aggregation, and process analytics to services portfolios
correlation provide business process
visibility and - Packaged applications, custom
- Issuance of credentials optimization applications, SAAS strategies
in different trust closely aligned
domains (WS-Trust),
establishing security - Large proportion of projects are
context and derived executed using SOA
keys

- Enterprise SOA
Platform built out

5
 SOA Maturity Cheat Sheet
Version 2.4

Capability → Infrastructure Architecture Information & Analytics Operations Project Execution Finance & Portfolios
Portfolios People & Organization Governance
Maturity
Level ↓
5. Industrialized SOA - Wide spread use of - Adherence to architectural - Operational data - Wide scale use of - Projects largely consist of - Cost of application development - Mature SOA Centre of - Governance is transformational
part of the inductive and deductive standards and formal flexibility key enabler shared operations service assembly reduced Excellence focus on aligning business with
enterprise DNA event-driven exception handling for top-line business environment (i.e. grid) IT through SOA and driving
technologies such as mechanisms in place competitiveness with dynamic - Application maintenance costs - Mature SOA Organizational business transformation and
Focus on Complex Event performance and SLA reduced through increased SOA Structure competitiveness
Business Processing (CEP) to - Enterprise architecture fully - Intelligent enterprise support, with fine- maturity and legacy sunsetting
Optimization – enable automated sense transformed into business view, context- tuned policies for - Critical emphasis on - Defined business objectives for
react and and respond service delivery vehicle (i.e. dependent, resource allocation - Ability to fund more programs to continuous improvement evaluating SOA investments
respond. Be a applications aService and Event Driven performance-driven support business mindset and a culture of that business executives can
leader in the eco- Enterprise), with SOA business SLAs - SLAs for services testing, learning, improving and describe.
system. Enable embodied across maintained through - Complete service and event using business insight and
the virtual development, security, - Autonomic automated operations portfolio across all major and adaptable processes across the - SOA governance regime stable,
enterprise with management, and optimizations, quality environment second-tier internal business enterprise has well-defined exception
business insight, operations and change processes, customer and partner processes, and standard
and real time responsiveness at all interactions practices that work smoothly
information - Applications rationalized data interfaces
and migrated to services - Projects leverage SOA extensively
access. for legacy sunsetting
and composites - Enterprise data
integration, structured
- Critical emphasis on a and unstructured, semi
continuous improvement or fully automated, e.g.
mindset and a culture of by using dynamic
testing, learning, improving metadata-driven data
using business insight and integration
adaptable processes
- Analytics is fully SOA
native, open standard
metadata leveraged by
services

- Sense and respond with

analytics-driven
business processes

6
 SOA Maturity Cheat Sheet
Version 2.4

Notes

Maturity Level – Maturity Levels 1-5 denote steps in SOA maturity. Each level is primarily designated by a vision and strategy. For example, Level 1 is about opportunistic
application of SOA to high value business problems that can be relatively easily implemented using SOA. It’s also about learning. A company may start out on the road to SOA
with a Level 3 vision. In this case, our advice is to consider implementing some of the best practices captured at Levels 1 and 2.

Infrastructure – A focus on incrementally building out SOA infrastructure is key to any SOA strategy. Another key aspect is to utilize standards and define your own variations
on those standards and enact them as your corporate standards. We have attempted to capture some of the key infrastructures that you should be using at each maturity level.
You could use any of the more advanced infrastructures at any level, e.g. you can do complex event processing at Level 1 or Level 2. However, it’s a required part of your SOA
architecture and solutions at Level 5. Technology must be identified, sourced, and managed just like any other component of SOA; it is not a one-time “fire-and-forget” decision.
Hence, policies need to be enacted to ensure that 1) a technology foundation (often termed Strategic SOA Platform) that provides messaging, security, and other services is
centrally funded and leveraged by all projects; 2) consensus is built regarding the migration of legacy systems and platforms to SOA technologies; 3) SOA platform
enhancements coincide with the project portfolio plan and business service portfolio plan; and 4) the design and implementation of shared foundation services are a part of SOA
infrastructure. If each of your project teams uses its own separate infrastructure for SOA—without integrating or sharing components with the other teams—is there any chance
of building composite applications that are reliable and secure? Many architecturally mature organizations today have organizations and processes devoted to software and
hardware governance, and these need to be leveraged to build out the SOA Infrastructure.

Architecture – Every system must be built so that it both fits into your existing environment and reflects your organization’s future vision and SOA strategy. Architectural policies
provide the foundation and framework for your SOA and enable you to build such a system better, faster, and cheaper. Building out your SOA to enable change is best done
using an architectural approach that sets up a minimal set of constraints, thereby realizing consistency in service implementation and improved interoperability; realizing
stakeholder innovation; and enabling applications that are minimally developed, have no adverse effects on other systems, offer general-purpose capabilities that are useful to
other applications, and take advantage of and enhance a shared infrastructure. As part of your SOA journey, you should consider policies built around 1) standards
compliance—for example, WS-I Basic Profile compliance for service interfaces; 2) use of architectural assessments, including reviews and change processes; 3) utilization of
architecture documents and guidelines covering use cases, views, service interface design, and design patterns; 4) use of service-based application blueprints; and 5)
adherence to reference architectures.

There are a few things to keep in mind when planning your architecture policies. First, by keeping your enterprise architecture artifacts simple, you increase the chances that
your audience will understand them, project teams will actually read them, and you will be able to effectively enforce and update them over time. Second, timely guidance from
an enterprise architect who understands the current environment and the future vision for the enterprise—even when this guidance is imperfect and based on incomplete
information—is often far better than the uneducated guesses that a project team will make on its own while it waits for the official architecture to be published. Organizations
must attain a certain level of process maturity—and architects must establish credibility—before they can incorporate effective SOA architectural governance. Don't expect to
establish governance authority before the organization as a whole sees the value of the SOA program and is ready to change its behavior to attain that value.

Information and Analytics – An often-ignored part of SOA is information architecture and use of analytics to help drive business improvement. Information and analytics are
key to delivering on the vision of the agile enterprise that can innovate and respond to market dynamics. Having good information on tap and widely accessible predictive
analytics is key to achieving this vision and should be part of any SOA architecture and strategy.

Finance – Budget allocation in a pre-SOA world happened in silos at the project, group, or department level. SOA, on the other hand, is about sharing capabilities as services
and leveraging assets across the enterprise. SOA may require new policies and procedures (including chargeback models) for funding services and architecture. Ideally, these
policies should facilitate 1) the sharing of hardware and software infrastructure that is the backbone of an enterprise wide SOA; 2) the funding of business and technical services
that will be shared across multiple departments; 3) the funding of SOA-related capabilities that aren’t delivered as part of existing projects; and 4) the funding of an active
enterprise architecture (EA) group and SOA Center of Excellence—which usually happens when your SOA journey is already well under way. The sooner you balance the
interests of service providers, who pay an overwhelmingly large portion of the cost for producing a service, and service consumers, who pay an underwhelmingly small cost for
using the service, the more reuse you will get! The greatest benefit and return on investment with SOA occurs when companies stop trying to maximize investments locally
(silos) and start maximizing all assets across the entire enterprise.

Portfolios You need to enact policies around three types of portfolios: business and foundational services portfolios, project portfolios, and enterprise applications portfolios. You
should 1) ensure that application lifecycles (upgrade, enhancement, maintenance, and retirement) are consistent with your SOA strategy and enterprise architecture—especially

7
 SOA Maturity Cheat Sheet
Version 2.4

with the SOA standards on which interoperability is built; 2) ensure that hardware and software agendas and plans are consistent with your SOA and enterprise strategy; 3)
create projects to align applications and infrastructure with the milestones and goals of your SOA Road Map; 4) plan your business services and foundational/technical services
portfolios so that you can phase in services that are in sync with projects that will be leveraging them; and 5) ensure that your packaged enterprise applications—which are a
potential source of services—are leveraged in your business services portfolio, and that decisions on new packaged applications conform to the SOA strategy and EA direction.
At the same time, your policies should ensure that projects you are building using SOA principles contribute services to the business services portfolio, from which other projects
can then benefit.

Organization and People – SOA is not just a technology shift. Specific areas that need to be considered include 1) assigning and empowering employees who are responsible
for driving process improvement often termed Process Officers (SOA is about improving business processes, thus someone needs to be responsible for making it happen); 2)
developing the skills necessary for architecting, building, testing, and deploying services and service-oriented applications; 3) creating incentives to encourage the building of
shareable services and the reuse of existing services; 4) forming an enterprise architecture group to drive adoption of EA disciplines and SOA in particular; and 5) creating a
group that is specifically tasked with governing the SOA roadmap. Typically, the SOA governance group consists of representatives from EA, the LOBs, and finance.

Project Execution – SOA has a pronounced impact on how projects are executed. Not all projects are compatible with SOA technologies, and even projects that are designed
for SOA must have a range of additional considerations and policies applied to them. Policies need to be put into place to 1) ensure that appropriate projects are selected for the
application of SOA techniques and technologies; 2) prioritize projects and align them with the SOA strategy and SOA Road Map (for example, to ensure that projects take into
account services that gradually come online as denoted in the business services portfolio plan); 3) address service funding, ownership, and management; 4) drive consistency in
service implementation to ensure that shared services are architected and deployed to facilitate and realize sharing (some of these policies will focus on architecture as well); 5)
address the creation, storage, and retrieval of shared SOA artifacts; and 6) formalize the governance of the lifecycle of services, business processes, and business rules.

Policies that address the lifecycle of services—or service lifecycle governance—are usually the focus when people talk about SOA governance. Service lifecycle governance
covers every aspect of services, including service identification, approval for enterprise services, service design (including interface design, creation guidelines, and best
practices), service publishing, change request management, versioning, retirement/sunsetting, deployment, and operations. Proper service lifecycle governance is a critical
component of SOA success. Without it, you may have services and SOA technology, but you will not realize the benefits of an enterprise service-oriented architecture.
Technologies such as registries and repositories help to enforce service lifecycle policies, and integrated business process management suites include capabilities to manage
the lifecycle of business processes. However, each organization must define and enforce its own best practices to ensure that service lifecycle policies are followed.

Operations Services that are shared across enterprise departments have operational implications that need to be captured as policies. These policies must address 1) the
operational model for services, including who pays for additional resources when services levels are breeched; 2) capacity monitoring and planning, to ensure that critical
business processes that rely on shared services are monitored and the services that support those business processes have the capacity to handle the load; 3) the handling of
policy exceptions and violations; and 4) service execution, including the definition and enforcement of runtime policies such as security, access, logging and billing policies, and
service reliability. The runtime enforcement of operational policies is the other aspect of SOA governance that many focus on. A SOA/ Web services management solution can
help you apply runtime policies to services.

Governance – Unfortunately governance is an often-misrepresented term. Peter Weill of MIT defines IT governance as "specifying the decision rights and accountability
framework to encourage desirable behavior in the use of IT.” Decisions, processes and policies are the means by which you influence the desired behavior that contributes to
success – in this case, SOA adoption. As part of the execution of your SOA strategy, you should put together a SOA Roadmap. You should Govern the execution of your SOA
Roadmap to ensure that you deliver on your SOA (and business) objectives. That is what Governance with SOA is about! Some people talk about SOA governance in the
context of Service Governance – i.e. governing the lifecycle of services from creation through deployment. There is more to Governance with SOA than this. In order to ensure
that you deliver on your SOA Roadmap you need to make decisions, enact policies and processes, communicate them widely and then monitor their implementation and
enforcement. So the natural question arises – over what do you have to put in decisions, policies and processes? Over the capabilities mentioned above – technology
infrastructure, architecture, organization & people, finance, portfolios, information and analytics, operations and project execution. It’s only through putting policies and processes
in place that change happens. We are not suggesting that you put in extensive governance schemes when you start out – just realize that SOA requires change and change
happens through decisions and policies that get put into place!