Latest Updates | Topics | Site Map | About Me | FAQ

Levels of Service Oriented Architectgure (SOA) Maturity


Below is my rough categorization of levels of SOA. I'm still not sure if this issue fits into levels very well - but appreciate that the idea of progressive levels will be attractive to many stakeholders. Originally I had 5 levels but two problems arose. First I found myself slipping too much into the verbage of CMM-speak ("managed", "optimized", etc). Second, the distinctions between levels got a little blurry - consolidated to 3 levels so that the differences would be more apparent.
Ad Hoc SOA
  • The data consumed and provided by the service(s) focuses upon a niche of the enterprise. Use of this data requires still requires a significant understanding of technical context. Little if any of the data is expressed in terms of business domain entities or, if so, only within a specific business process context.
  • Processes performed are too small to realize a meaningfull business activity. The ability to execute business processes under load is severely constrained - little capacity exists outside the initially conceived application purpose. Services are technical in nature - e.g. login authentication.
  • The scope of service is very narrow. Very little "footprint" in the enterprise operations.
  • No meaningfull ability to measure or manage the performance/capacity of service delivery. No quality of service mechanisms in place.
  • The service environment is very narrow and may rely upon specific individuals, specific products for implementation, or locations.
  • Service development and delivery relies upon specific individuals.
  • The service directory is very limited or may not exist at all.
  • The timing concepts of the implementation reflect the niche use of services. Most services are implemented as conventional, blocked, and synchronous calls.
  • Service development is exclusively "bottom-up".
  • The limited use/re-use of the service belies calling it a "service". Use/re-use of a service requires a level of coordination that is only slightly below the re-build effort.
Application Integration
  • Services provide meaningful aggregation and transformation of data across business processes. Most of the data is expressed in terms of business domain entities.
  • Aggregates computations into meaningfull business processes - payment collections, change of address, etc.. Activities performed focus on IT-centric objectives but have impact on non-IT operations - though perhaps only indirectly.
  • Service presence spans the enterprise horizontally and vertically but is not pervasive.
  • Service delivery is measured and managed but generally in a re-active fashion. Either limited ability to plan capacity or planning focuses on technical measures. Quality of service mechanisms primarily focus on sustaining static measures of success.
  • Alternative implementations of services are available as design alternatives or product competitors but alternative implementations of services are genearlly not available on-demand in run-time operations.
  • Skill-sets necessary to design and develop services are defined and managed as roles that can be filled by a number of persons.
  • The service directory is able to support design and run-time discovery of known number of services.
  • The service participants conform to established, relatively simple, roles such as "reader" v. "writer" or "publish" v. "subscribe".
  • The service portfolio includes synchronous and asynchronous services.
  • Service development is largely "bottom up" or from a coincidence of interest between multiple projects/programs.
  • Measureable use/re-use of services occurs and has demonstrated impacts on development costs, development schedules, lifetime costs of operations, etc. Incentives compel frequent use/re-use of services but non-trivial coordination is required to use services.
Genuine Enterprise Services
  • Services provide end-to-end processing of business domain entities for the enterprise. The services are robust, resiliant, adaptive, and predictable stewards of enterprise information.
  • The operation of the enterprise services has a direct impact on activites across the enterprise - including business processes that are not directly IT-intensive. Services contribute directly to the essential, domain-specific, operations of the enterprise.
  • Service delivery is pervasive/ubiquitous in the enterprise - the presence is on par with conventional utilities such as electricity, telephones, etc.
  • Measure on service satisfaction are available with sufficient depth and breadth to support reasonably accurate capacity planning. Service delivery can be measure and managed accurately in terms of business performance. Quality of service can be predicted accurately across scale-up and scale-down mechanisms - supporting planned as well as ad hoc demands upon the services.
  • The service delivery mechanisms can provide alternative implementations of the services on an on-going basis.
  • The human resource management activities ensure not only on-going development and operations of services but contribute to significant innovation in service development.
  • The service directory provides human and machine readable support of design and run-time discovery of services - and for a volatile environment of service participants.
  • The management of service participants is complex supporting concepts such as observation, injection and veto.
  • Services can re-sequence requests, prioritize service responses, and resolve (in)completeness problems - not only at the technical level but at the business process level as well.
  • Services are identified, planned, allocated, designed, managed, etc. as part of the management of the enterprise business and technical architectures.
  • There is pervasive use/re-use of services - this is the norm rather than the exception. Individual service consumption is largely invisible to the service provider with little or no coordination required.