In the first blog in this series I highlighted an approach to capture and dissect project requirements into expanding a business function model. In this blog I want to highlight a process into identify services candidates and potential opportunities for service reuse.
Service Identification deals with the procedures and guidelines that an enterprise adopts to identify new shared Service Candidates. Discovery is the mechanism whereby existing shared Services can be easily identified as the need arises within a new project. Identification and discovery are equally important. These two topic areas share an obviously natural relationship to one another.
In the process of analyzing requirements, new Service Candidates need to be considered on two angles. Either they have already been realized in the form of a shared Service, or they are a potential candidate for a shared Service.
- Service Identification – begins with the analysis of requirements and ends with the identified set of Service Candidates. Service Candidates represent the set of business function that have been recommended for reuse. A Service Candidate does not necessarily map one-to-one to a Service because Service Candidates could be realized by the creation of one or more Services. This determination, however, is outside the scope of Service Identification but is part of Service Boundary Analysis which I will cover in the next blog.
- Service Discovery– is a natural extension of the Service Identification technique whereby a practitioner analyzes requirements against existing Services to check that there may be viable reuse to fulfill some or all of the requirements. This is a more natural approach to Service Discovery compared to a complicated search paradigm that typically tends to be inefficient and inaccurate in identifying reuse candidates.
So let’s start with identifying service candidates
Identify Service Candidates
The Identify Service Candidate process focuses on analyzing the requirements and the business function model that was populated
and expanded as part of an SOA Requirements approach (as discussed in the previous blog). This does not actually change the business function model; rather it identifies new Service Candidates, Service Candidates covering the extension of an existing Service, and Service reuse prescriptions.
Examine Business Function Model Node(s)
The business functions that have attached project requirements are examined and analyzed. By examining the requirements of each functional activity, reuse candidates, Business Process Service Candidates, and Business Activity Service Candidates are identified. When examining a business function node, there are three potential scenarios:
Complete Service overlap – If all requirements within the business function node being examined are linked to the current project and are also linked to one or more shared Services, then this is known as a “Complete Service Overlap”.
In the above figure the node “8.6.1.3.2 Transfer Funds” is being examined. In this node, all of the requirements are both linked to the current project as well as the TransferFunds Service. In this scenario, the TransferFunds Service should be validated for reuse by the current project.
Partial Service Overlap – If some, but not all, of the requirements in the examined business function node (that are linked to the project) are also linked to a shared Service, then this is known as a “Partial Service Overlap”.
In the above figure the node “8.6.1.3.2 Transfer Funds” is being examined. In this node, some of the requirements are linked to the project and some are linked to both the project and the TransferFunds Service. In this scenario, there are a number of options:
- Simply reuse the existing Service and realize the remaining requirements within the project.
- Propose a new Service Candidate from the remaining requirements.
- Propose an extension to the existing TransferFunds Service to include the new requirements.
No Service Overlap – The requirements located within the business function node are not linked to any Service. They may be linked to other projects but none of the requirements has been realized within a shared Service: this is known as “No Service Overlap”.
In the above figure the business function node “8.6.1.3 Approve Reimbursements and Advances” is being examined. Because none of the requirements in lower nodes have been put forward and approved as Service Candidates, the entire set of requirements is being put forward as a potential coarse-grained Service Candidate.
This technique, which can lead to coarse-grained Services, is critical to understand and implement. Otherwise a practitioner may be inclined to propose a Service for each individual node in the business function model. This can lead to too many fine-grained Services that may have an impact on performance once the Services are realized.
In addition, this technique allows a practitioner the ability to later refactor a coarse-grained Service into finer-grained Services. For example, the “8.6.1.3.2 Transfer Funds” business function node may later be justified as an autonomous Service, and the appropriate business functionality would be extracted from the current “Approve Reimbursements and Advances” Service. The current Service then uses a Service composition technique to replace the extracted functionality.
Business Entity Analysis
Analyzing the data needs for an identified candidate business Services and the data currently being used by identified reuse Service candidates in conjunction with the Data Consumption Model, enables an architect to identify business entities and build a Canonical Message Model. A Canonical Message Model applies a Canonical Message Model to message formats by constructing messages structures, elements, and attributes using canonical data. The Canonical Message Model describes the structure of the data that will be used to transported across the Business Function Model and, therefore, may later be used to standardize interfaces.
The architect can search the Service catalog for existing data Services that could support the needs of the identified candidate business Services.The architect may also need to search the Service catalog for existing business Services that have encapsulated data Service functionality that could support the needs of the identified candidate business Services.
The architect will then have enough information to identify:
- Candidate Data Services,
- Candidate reuse Data Services,
- Candidate Business Service modifications where encapsulated Data Service functionality could be refactored.
Create Service Candidates & Define Reuse
Service Candidates are Services that have not yet been justified for realization. Service Justification determines if a proposed Service Candidate should be realized as a shared Service or not. A Service Candidate that is not justified is pushed back to the project for realization. The project team may opt to realize the Service Candidate as a Service, but it will not be hosted and managed within the realm of shared Services infrastructure. Service Candidates must be proposed in a standardized and consistent structure. Therefore enterprises must have an agreed upon definition of a Service and its associated lifecycle states.
Proposed Service Candidates should be evaluated against a balanced criteria scoring system to indicate whether a Service Candidate should be realized. This will assist in selecting and justifying whether Service Candidates should be realized. I use a criteria that covers both the benefits and inhibitors if the Service Candidate is realized. Here is my example criteria for benefits realization.
| Criteria | Description |
| Scope | Weighs the benefit that the intended scope of the Service Candidate will have on the enterprise if realized. |
| Reuse | Weighs the potential reuse levels for the Service Candidate if realized. |
| Agility | Weighs the potential for enterprise agility resulting from the Service Candidate if realized. |
| Compliance | Weighs the potential for enterprise compliance resulting from the Service Candidate if realized. |
| Enablement | Weighs the potential to leverage existing enterprise assets to realize the functions of the proposed Service Candidate. |
Here is my example criteria for realization inhibitors.
| Criteria | Description |
| Skill-set Impact | Weighs the additional skill-set necessary to realize the functions proposed by the Service Candidate in a shared manner. |
| Project Impact | Weighs the additional impact placed on the proposed, in-flight, and operational projects that would be incurred by realizing the Service Candidate in a shared environment. |
| Technology Capability | Weighs the additional tools or technology necessary to realize the functions proposed by the Service Candidate in a shared manner. |
| QOS Feasibility | Weighs the level of difficulty and risk that will be encountered when trying to realize the nonfunctional requirements of the Service Candidate within a shared environment. |
Any criteria used by an enterprise should be open to customization as and when the needs and priorities change. This can be achieved by adding/removing as well as weighting each criterion based on the relative importance of each. A balanced scoring system simply yields a ‘Decision Basis Score’ that is the sum of ‘Realization Benefits’ less the sum of the ‘Realization Inhibitors’.
Reuse Validation
Service Reuse Validation is used to determine if a proposed Service reuse candidate should be reused by the project or not. This covers the instance where a Service Candidate has already been realized or planned to be realized and a new project would like to reuse the asset.
Before a Service can be validated for reuse by a project, a Service consumption request needs to be defined. A Service consumption request provides details regarding the expected usage requirements along with the corresponding time periods, purpose, etc. Example details include:
- Expected (and maximum) load that consumer will place upon the Service.
- Maximum amount that the Service will consume – invocations per time (e.g., invocations/hour).
- Expected usage scenarios including days of the week, hours, and average consumption during the indicated time periods; and the peak usage scenarios including days of week, hours, and average consumption during the indicated time periods.
Once the Service reuse consumption requirements have been determined, the Service Candidate is put forward for Service Reuse Validation. There are a number of validation criteria that should be used when determining if a proposed Service should be reused. In particular a Reuse Validation Process should cater for validation against security policies, service design suitability, and expected capacity.
- Security Policies – Even though the Service may be a functional fit for the consumer, it still needs to be determined whether the consumer will be authorized to reuse the proposed Service. For example, the Service security policies should be reviewed to see if they prevent the project from reusing the Service.
- Service Design – The consumer must make sure that the Service reuse candidate has been designed in a manner that is appropriate. In particular the design regarding QoS (Quality of Service) as well as the interface my invalidate the Service for reuse by the specific consumer.
- Capacity – A key criterion to review is whether the required capacity or demand that the new project will require is available within the current Service-hosting environment. If the capacity requirements are not currently available, a determination needs to be made as to whether to expand the Service-hosting environment or reject the reuse candidate. If there is capacity, then the candidate can be approved for reuse and prescribed for the project. If the necessary capacity is not currently available in the Service hosting environment, but the determination has been made to extend that environment, then the appropriate extension plans need to be arranged to have the environment scaled. The Service is then approved for reuse and must be prescribed for the project.
OK that is all for this week, next I will finish this series of blogs on Service Identification and focus on Service Boundary Analysis.
Good Luck, Now Go Architect….
An Enterprise Architect's Musings 