Continuing from my last blog I will finish off by looking at Service Boundary Analysis. Service Boundary Analysis is a key activity in Service Identification which helps with determining if one or more Service boundaries are necessary in order to make the best use of hardware resources and satisfy the intended Service consumers who require the functions of the Service Candidate.
Typically, a Service Candidate will result in a single contract being defined leading to a single Service being realized after Service Delivery is completed. However, a Service Candidate may result in the definition of multiple Service Contracts since there are additional factors to consider when determining the Service boundaries based on a Service Candidate’s attached requirements.
Influencing Factors
An architect identifies the Service boundaries by analyzing various influencing factors against the Service Candidate requirements. Example influencing factors that affect Service boundaries include:
- Clarification of Service Candidates –Â If requirements fall into separate Service classifications, then there is a good chance that a Service boundary should be established, and that separate Services should be created for each scope that has different requirements.
- Scope of Requirements –Â If requirements are different for differently scoped consumers, then there is a good chance that a Service boundary should be established, and that separate Services should be created for each scope that has different requirements.
- Security Policies –Â If a Service candidate has a variety of different security policies spread across differing requirements across the Service Candidate, then it is likely that separate Services should be created along these different security requirements. This pattern usually provides a key indicator that significantly different types of consumers will be using the functions identified by the requirements.
- Message Exchange Patterns –Â Variances in Message Exchange Patterns (MEP) are another indicator of a potential Service boundary. If certain requirements require a publish/subscribe pattern while others require request response, there is a good chance that separate Services should be defined along these lines. Reasons for identifying Service boundaries by Message Exchange Patterns Include:
- EPs typically represent significantly different functional requirements.
- QoS is usually significantly different across differing MEPs.
- Different MEPs typically require separate interfaces.
- Quality of Service Requirements –Â The QoS requirements of the Service candidate need to be examined since they may represent significant differences in infrastructure requirements. When these conditions exist, defining separate Services along QoS boundaries leads to greater flexibility especially when managing scalability within the shared environments.
Service Boundary Analysis is not an exact science, and its primary goal is to draw the architect’s attention to potential areas where a Service boundary may be required.
There will certainly be situations where there are differences in the factors identified above, but there is not enough benefit to justify the creation of a separate Service. Once the Service boundaries have been identified, a Service Contract for each identified Service should be defined.
Architects should expect and anticipate the need to change a Service. Services will evolve and go through a documented Service versioning process. In some circumstances, this will require the need to change the Service boundary and potentially promote a Service operation into a Service.
I think that is more than enough on service identification.Â
Good Luck, Now Go Architect
An Enterprise Architect's Musings 