Introduction

"There is nothing either good or bad, but thinking makes it so" - William Shakespeare

World-renowned SOA expert Thomas Erl had stated the following on Service Reusability, "A service capability can be reused in two different ways. It can be repeatedly invoked by the same service consumer program automating the same business task or it can be invoked by different service consumers automating different business tasks." Based on this thought, services are generally classified into Shared Services and Internal Services.

1.	Shared Services (Multiple-Purpose Programs) are true enterprise resources with agnostic functional contexts. They cater to larger groups of service consumers. An example is services which are defined at Enterprise level or Inter-portfolio level.
2.	Internal Services (Single-Purpose Programs) have specific functional context. They serve with limited scope to a known service consumer. An example is services that are limited to Intra-application or Inter-applications within a portfolio.

SOA governance board should identify the category to which a service or service candidate belongs. There are many instances where a service candidate is identified by a business unit for a specific requirement. This service is termed as an internal service, but the scope could be broader.

Once a service is properly tagged, the governance board should evaluate shared services as well as internal services. If the board doesn't do so, the pitfall of the existing service will not be known until a problem occurs. This then leads to a delay while they amend the existing service (non-backward compatible changes) or totally create a new service altogether. Both of these results completely defeat the purpose of the SOA service.

An SOA governance board has to create a set of rules (Smart Assist) to evaluate a service. I have created a "Smart Assist" model to evaluate a service based on "SOA Principles of Service Design" and "SOA Design Patterns" by Thomas Erl. The yes/no responses to these rules will be translated to a percentage that will be compared against the 8 Principles of Service. This approach will help an SOA governance board to quantify the deviation a service makes from the defined standard of the enterprise. It allows everyone to know where a service stands and what needs to be improved. However, please note that the accuracy of the content and evaluation mechanism used in the "Smart Assist" approach is subjective. One can analyze and draft such guidelines and evaluation mechanism in order to better suit the enterprise and SOA project.

Figure 1 - Please note that the above graph is just indicative.

Standardized Service Contract

S.No.	Guidelines	Rationale	Phase	Importance
1.	Service contracts are standardized through naming conventions and application of design standards.	Service contracts may express similar capabilities in different ways, leading to inconsistency and risking misinterpretation	Analysis / Design	High
Yes/No	Smart Assist Query	Comments (If any)
	Is a service contract (comprised of technical interface details and one or more service description documents) provided with the service?
	Is the "Contract First" approach or refractor as per "Meet-in-the-Middle" approach applied towards creation of the service contract?
	(Compatible Change) Is a service contract extensible by design so that some changes are backwards compatible, thereby avoiding negative consumer impacts?
	(Canonical Expression) Are naming conventions applied to the service contract as part of a formal analysis and design processes?
	Are policy assertions expressed in a standardized structural manner so as to be consistent?
2.	(Canonical Schema) Service uses standardized data models within an inventory boundary for common information sets.	Services with disparate models for similar data impose transformation requirements that increase development effort, design complexity, and runtime performance overhead	Analysis / Design	High
Yes/No	Smart Assist Query	Comments (If any)
	Is a service inventory defined at an enterprise level and/or a meaningful segment of an enterprise level?
	Are business subject matter experts (SME) involved in creating the data models?
	(Entity Data Abstraction) Are Entity-centric schemas defined and standardized separately in support of service layers?
3.	(Canonical Versioning) Service contract versioning rules and the expression of version information are standardized within a service inventory boundary.	Service contracts within the same service inventory that are versioned differently will cause numerous interoperability and governance problems	Governance	Medium
Yes/No	Smart Assist Query	Comments (If any)
	Are service versioning rules defined within a service inventory boundary? i.e., a) When should a major or minor release happen? b) What should the version numbering scheme be?
	(Version Identification) Are version numbers incorporated into namespace values (or other means) and as annotations in the service contract?
	(Termination Notification) A service contract extended with ignorable policy assertions or supplemented with human-readable annotations when a service or a service contract version is scheduled for retirement?
4.	(Schema Centralization) Select schemas that exist as physically separate parts of the service contract and are shared across multiple contracts	Different service contracts often need to express capabilities that process similar business documents or data sets, resulting in redundant schema content that is difficult to govern	Analysis / Design	Medium
Yes/No	Smart Assist Query	Comments (If any)
	Are schemas designed and implemented separately from the service capabilities (operations) that utilize them to represent the structure and typing of message content?
	Are schema elements created and maintained in a centralized location for the sake of consistency and ease of maintenance?
	Is the process defined for governance of shared schemas as multiple services form dependencies on the same schema definitions?
5.	Policy Centralization: Global or domain-specific policies can be isolated and applied to multiple services.	Policies that apply to multiple services can introduce redundancy and inconsistency within service logic and contracts.	Analysis / Design	Low
Yes/No	Smart Assist Query	Comments (If any)
	(Policy Enforcement) Is inventory architecture equipped with policy processing and enforcement features?
	Are policy definition documents modularized allowing for the creation of a base policy definition containing broad, generalized assertions and creating a specialized one separately on need basis?
	(Canonical Policy Vocabulary*) Are the vocabularies used by service contract policy assertions standardized across all services within an inventory boundary?

Service Reusability

S.No.	Guidelines	Rationale	Phase	Importance
1.	Service is defined by an agnostic functional context.	Logic encapsulated by the service is associated with a context that is sufficiently agnostic to any one usage scenario so as to be considered reusable	Analysis / Design	High
Yes/No	Smart Assist Query	Comments (If any)
	(Agnostic Context) Is the service logic that is not specific to one purpose isolated into separate services with distinct agnostic contexts?
	(Agnostic Capabilities) Is agnostic service logic partitioned into a set of well-defined capabilities that address common concerns not specific to any one problem?
	Are business subject matter experts (SME) involved in creating the data models?
2.	(Service Normalization) The service inventory needs to be designed with an emphasis on service boundary alignment.	When delivering services as part of a service inventory, there is a constant risk that services will be created with overlapping functional boundaries, making it difficult to enable wide-spread reuse.	Governance	High
Yes/No	Smart Assist Query	Comments (If any)
	Is service inventory defined at an enterprise level and/or at meaningful segment of an enterprise level?
	(Service Layers) Is inventory structured into two or more logical service layers, each of which is responsible for abstracting logic based on a common functional type?
	(Service Inventory Blueprints) Is a conceptual blueprint (based on common business and data models) of all the planned services established for a given inventory?
	Did the service candidate emerge out of service inventory blueprint or at the least could it be mapped to one of the service layer?
3.	(Logic Centralization) Access to reusable functionality is limited to official agnostic services.	To avoid redundant functionality being delivered in other services, resulting in problems associated with inventory denormalization and service ownership and governance	Governance	High
Yes/No	Smart Assist Query	Comments (If any)
	Are agnostic services usage enforced via enterprise design standards? For example, if a new capability is needed which clearly falls within the boundary of an existing service, the corresponding functionality needs to be added to that service instead of creating a new service.
	(Contract Denormalization) Do service contracts include a measured extent of denormalization, allowing multiple capabilities to redundantly express core functions in different ways for different types of consumer programs?
4.	Services are designed to facilitate concurrent access by multiple consumer programs	Once a service inventory is relatively mature, reusable services will find themselves in an increasingly large number of compositions	Analysis / Design	Medium
Yes/No	Smart Assist Query	Comments (If any)
	Is a scalable runtime hosting environment capable of high-to-extreme concurrent service usage available?
	Is service designed to facilitate simultaneous access by multiple consumer programs?
5.	(Rules Centralization) The storage and management of business rules are positioned within a dedicated architectural extension from where they can be centrally accessed and maintained.	The same business rules may apply across different business services, leading to redundancy and governance challenges	Governance	Low
Yes/No	Smart Assist Query	Comments (If any)
	Are business rules separated from core service logic and centrally located?
	Is the business rules management system or engine employed?
	Are business rules accessed via system agents or a dedicated service?

Service Autonomy

S.No.	Guidelines	Rationale	Phase	Importance
1.	Services are deployed in an environment over which they exercise a great deal (and preferably an exclusive level) of control	Gives the freedom and control to make its own decisions without the need for external approval or involvement. The more independent a system is from unpredictable outside influences, the more reliable it will be	Runtime / Implementation	High
Yes/No	Smart Assist Query	Comments (If any)
	Is the service hosted in a middleware product(s) or at least on an application server specifically dedicated for services?
	Is a distributable deployment environment available, so as to allow the service to be moved, isolated, or composed as required?
2.	Service instances are hosted by an environment that accommodates high concurrency for scalability purposes.	To guarantee acceptable runtime execution performance and to ensure a greater level of behavioral predictability	Runtime / Implementation	High
Yes/No	Smart Assist Query	Comments (If any)
	Is scalable runtime hosting environment capable of high-to-extreme concurrent service usage available?
3.	(Design-time Autonomy) Control over how a service is designed and developed	The greater the amount of design-time autonomy, the greater the amount of attainable runtime autonomy	Governance	Medium
Yes/No	Smart Assist Query	Comments (If any)
	Are underlying services components dedicated to the service and can be isolated?
	Are physical data models (database artifacts) dedicated to the service?
	Does the service encapsulate legacy logic?

Service Statelessness

S.No.	Guidelines	Rationale	Phase	Importance
1.	State management delegation and deferral extensions to be designed into the component logic	Helps maximize scalability	Analysis / Design	High
Yes/No	Smart Assist Query	Comments (If any)
	Is shared architectural extension designed/ available for reliable and flexible state deferral?
	(State Repository) Is state data temporarily written to and then later retrieved from a dedicated state repository?
2.	Services have no shared state with other services through common data is stored (separation of the data stores is conceptual).	To support the design of agnostic service logic and improve the potential for service reuse.	Analysis / Design	High
Yes/No	Smart Assist Query	Comments (If any)
	Is the service designed to not retain state information for any specific parent business process?
	Is the service contract less constrained so as to allow for the receipt and transmission of a wider range of state data (if any) at runtime?

Service Discoverability

S.No.	Guidelines	Rationale	Phase	Importance
1.	Service contracts are enriched with metadata information to describe the purpose and capabilities.	To ensure services are correctly referenced when discovery queries are issued.	Analysis / Design	High
Yes/No	Smart Assist Query	Comments (If any)
	Has functional meta information been expressed as part of the service contract for discoverability purposes?
	Has the quality of service meta information been clearly expressed as part of the service contract or a formal SLA?
	Have business subject matter experts contributed to the definition of business centric discoverability meta information?
	Has all discoverability meta documentation been subjected to standards and conventions to ensure consistency?
2.	Service contracts should be enriched further with additional metadata information to describe the purpose and capabilities in human readable format	To enable a wide range of project team members to effectively carry out the discovery process and not to limit it to those with technical expertise. And for a service consumer to make an informed decision.	Analysis / Design	High
Yes/No	Smart Assist Query	Comments (If any)
	Has functional meta information been documented in plain English?
	Has quality of service information been documented in non-technical English?
	Have business subject matter experts contributed to the definition of business centric discoverability meta information?
3.	Service profile document or service record is made available in Service Repository/Registry.	To facilitate central discovery mechanism	Governance	Medium
Yes/No	Smart Assist Query	Comments (If any)
	Are Service Registry/Repository available at enterprise level and/or at meaningful segment of an enterprise level?
	Has a service profile document or the corresponding service registry record been created?
	Does the service profile/registry record contain all relevant functional meta information?
	Does the service profile/registry record contain all relevant quality of service meta information?

Service Loose Coupling

S.No.	Guidelines	Rationale	Phase	Importance
1.	(Logic-to-Contract Coupling) Approach building a service by designing its physical contract prior to its underlying solution logic.	Maximizes the freedom with which the service can be evolved over time	Analysis / Design	High
Yes/No	Smart Assist Query	Comments (If any)
	Has functional meta information been expressed as part of the service contract for discoverability purposes?
	Is the "Contract First" approach or refractor as per "Meet-in-the-Middle" approach applied for creation of the service contract?
	Is the "Contract First" approach or refractor as per "Meet-in-the-Middle" approach applied for creation of the service contract?
	Is the usage of physical data model details into the service contract avoided? i.e. Placing auto-generated schema from database tables, views or similar objects into service contract
	Is a canonical data model that is independent from the type systems (used in the called applications) part of the service contract?
2.	(Consumer-to-Contract Coupling) Service contract is accessed as the sole or primary endpoint into service logic and resources	To achieve the greatest amount of independence between the consumer and the service. Gives Service owner the ability to swap service implementation technologies without affecting the service's existing consumer base	Governance	High
Yes/No	Smart Assist Query	Comments (If any)
	Is a service contract decoupled from proprietary technology and use XML and Web services standards?
	(Contract Centralization) Is access to service logic limited to the service contract, forcing consumers to avoid implementation coupling?

Service Abstraction

S.No.	Guidelines	Rationale	Phase	Importance
1.	Services consistently abstract specific information about technology and logic away from the outside world (the world outside of the service boundary).	This gives the service owners the maximum amount of freedom in evolving the service over time	Governance	High
Yes/No	Smart Assist Query	Comments (If any)
	Is technology information such as programming language, system resources used by the service hidden?
	Are low-level design details such as algorithms, exception handling and logging routines and other logic associated with the service protected by access control measures?
	Is source code of the service protected by access control measures?
	Have efforts been made to moderate usage of policy assertions so as to not reveal too many details about service's underlying logic, behavior and preferences?
2.	Service contracts are carefully designed to express just the right amount of functionality and select quality of service (QoS) details	To prevent unnecessary access to additional service details	Governance	High
Yes/No	Smart Assist Query	Comments (If any)
	Has a formal audit undergone on a service contract to trim unnecessary metadata and constraints?
	For all of the meta information the service capability abstracts, does it provide a clear expression of important quality of service characteristics?
	Is quality of service characteristics documented and maintained as part of SLAs (and access control measures taken as required)?

Conclusion

The guidelines for "Service Composability" are described in detail for a similar pattern in the book "SOA Principles of Service Design" book by Thomas Erl. Please refer the book for more information.

Note that shared service evaluation effort is not about finding the absolute truth; it is about measuring and publishing the relative truth. It is to help understand the efficiency of your service, so that no problematic surprises would arise. The success of your SOA system should not be determined by luck.

The Prentice Hall Service-Oriented Computing Series from Thomas Erl

Home Past Issues Contributors What is SOA? SOA Glossary SOA School SOA Books About/RSS Legal