is the starting point for most SOA journeys. At this level, SOA is likely to be a relatively new concept for your organization. You may have taken few real steps toward SOA or have conducted some limited, initial web services or service-based activities that are project-centric, experimental and often technology focused.
Typically, enterprises at Level 2 have made a firm commitment to adopting SOA, although this may still be limited to certain parts of the organization. Organizations at this level have completed a pilot or initial project with SOA applied consistently across the project and will have deployed a set of services that are in production use by their business.
Enterprises that have achieved Level 3 maturity have adopted SOA as a strategic enterprise-wide architectural principle. They have also established an enterprise service catalog, and an enterprise-wide service model is defined and used. In addition they have a defined set of SOA standards and are applying it across the enterprise. Governance systems ensure that all new projects are compliant with the enterprise’s SOA principles.
At Level 4, SOA is fundamental to the way the enterprise operates both its business and its information technology, and services may extend outside the enterprise. The enterprise’s service portfolio is well-managed with quantitative, integrated, enterprise-wide visibility and control of service operations. Service operational metrics are collected and reported in both business and technology contexts, according to the audience.
When an enterprise reaches Level 5, it can accurately be described as an Adaptive Enterprise. The whole enterprise operates a dynamic SOA with business and IT synchronized to achieve an optimum balance of agility, performance, risk and cost.
SOA adoption has an impact upon and provides benefits for both business and IT. In order to successfully adopt SOA across the enterprise, it’s imperative that both business and IT commit to the program. Both sides must recognize that there will be different ways of working, and both should recognize that there will be benefits realized for each.
As the adoption of SOA proceeds across the enterprise, the Business Domain must consider:
At the heart of the People Domain is simple communication. Looking at the other domains, it is clear that all our discoveries and decisions need to be communicated across the organization.
While program management is certainly not unique to the adoption of SOA, it is a key ingredient of any SOA program. In the Program Management Domain an important element is the organizational span of the SOA rollout across teams, departments, business units, and the entire enterprise, as well as managing the depth of the service portfolio. SOA adoption requires an iterative approach, with SOA rolled out as a series of steps. Each step provides a complete business solution, and each step delivers measurable business value.
When talking to enterprises that have successfully adopted SOA, probably the single, most consistent message we hear is, ”of all the things we have done to adopt SOA, the area which most caught us by surprise was the need to significantly enhance our governance systems.” The Governance Domain concerns the models, systems and processes by which the enterprise’s operations are governed.
The Architecture Domain covers the full architecture spectrum: enterprise architecture, solution architecture and technology architecture. The ”A” in SOA provides a strong reminder that the Architecture Domain lies at the heart of successful service-oriented architecture. Architecture is about principles, standards and models. We have repeatedly experienced, during many successful customer engagements, the tremendous value of adopting a set of guiding principles at the heart of the architecture.
In the Operations and Management Domain, processes and policies defined in the governance model are applied. The domain covers all aspects of operating and managing our service-oriented architecture. In addition to stronger governance, the more flexible and dynamic SOA environment demands significantly stronger management. Management refers not only to managing technology, but to managing the technology in terms of services delivered by the technology, both IT services and business services. When a particular piece of hardware technology fails, or when a particular device is no longer available, we need to understand which services required that device to be there in the first place.
Of all the SOA domains, the Enabling Technology Domain has received the greatest attention and is probably the best described and understood. The Enabling Technology Domain encompasses the tools and technologies needed to support achievement of the goals of the other seven SOA domains and to realize the infrastructure needed to support a serviceoriented architecture within an enterprise. The focus is upon the software and hardware technologies that are specifically required for the implementation of a service-oriented architecture.
PESC is the Post Secondary Education Standards Council (http://www.pesc.org). Once the keepers of key EDI standards (like the T130), PESC now publishes a number of standards as XML schemas:
PESC also acts as a standards broker and is facilitating the convergence of Kuali Student service contracts with existing PESC standards. See Letter of Intent.
IMS IMS Global Learning Consortium