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. |
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? |
|
|
|
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? |
|
|
|
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? |
|
|
|
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? |
|
|
|
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? |
|
|
|
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? |
|
|
|
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)? |
|
|
|