Identifying appropriate Services and Service reuse opportunities is a fundamental tenet of SOA. Therefore, a repeatable and pragmatic approach is required for the successful adoption and execution of an SOA.
One of the most important aspects of having an approach to identify services is to make sure it is repeatable, consistent, and effective.
I want to cover how I identify services. I want to address this topic over a series of blogs so that I can do justice to the topic. In this first blog I want to cover the topic of looking at project requirements with a SOA bias.
SOA Based Requirements
In order to achieve effective SOA, applications simply cannot be developed independently of one another. SOA applications utilize shared services that are not owned by any single application, have their own lifecycle separate from any application, and are managed independently. In order to be effective in managing requirements within an SOA, projects have to be aware of the requirements of existing applications, in-flight projects, and proposed projects.
Scoping requirements at the enterprise level, rather than at the application or project level, enables project architecture and planning exercises to remain connected to the overall enterprise SOA. This connection also provides a natural enabler for Service discovery, identification, and Service release planning.
Functional Requirement Decomposition
A functional requirement decomposition approach takes raw requirements such as text document, use cases, storyboards, etc. (depending on methodology used by the enterprise) and refines them to elaborate and extend an existing business function model. It is common for this approach to be called the “Top-Down” approach.
Here are the high-level steps that assist with this approach. (Over time, experienced practitioners collapse these steps into one streamlined activity.)
- Requirements should be reviewed noting the key verbs and associated nouns
- Specifics should be removed as a business function model is concerned with the “What” and is not concerned with the “Who”, “How”, or “When”.
- Appropriate business terminology should replace any project specific or unnecessary minor words.
- The identified function name should be based around a present tense “verb singular noun” (best effort).
| Harvest | Refined |
| All expense requests are reviewed by the office coordinator before approval by the consultant’s manager | Review Expense Report, Approve Expense Request |
| The finance department has the responsibility to verify the expense request against the expense policies | Verify Expense Request |
| Funds are sent weekly to consultants by the finance department | Harvest |
Application Decomposition
An application decomposition approach takes existing applications and identifies sources of functionality to service enable. It is common for this approach to be called the “Bottom-Up” approach and is commonly used to modernize an enterprise’s integration architecture. While this approach does have some value, this approach can lead to a number of challenges.
- Not all functionality that should be service enabled is identified.
- It is easier to define the wrong service granularity.
- SOA is not solely about integration so higher valued IT and business benefits will be neglected.
To overcome these challenges it is best to use a functional requirement decomposition approach coupled with the application decomposition approach. This allows a practitioner to analyze applications and identify the appropriate functional boundaries. This can then be used to elaborate and extend the existing business function model. It is common for this approach to be called the “Hybrid” or “Meet in the Middle” approach.
Business Process Decomposition
An approach that uses business process decomposition takes requirements defined in various sources, such as text documents, business process models, and business context models and refines them to elaborate and extend the existing business function model.
During the elaboration process of documenting a business process, individual process activities at all business function levels should be considered when expanding the existing business function model. A common error is to include technology specific activities within a business process model. It is important that these are not considered as part of the business function model.
Expand Business Function Model
I then use the identified functions from the above decomposition techniques to expand the existing business function model. It may be necessary to add additional levels to group related activities. The graphic below shows an expanded business function model where the identified functions (highlighted by the ticks) have been added to the partial business function model that is based on the APQC framework.
Classify Enterprise Requirements Against Function Model
The classification of functional models and requirements is achieved iteratively between the business and IT divisions. The business provides input regarding the overall business process, while the delivery team and SOA leadership team develop the models and classifications that are then crosschecked with the business. The requirement is attached to the appropriate node within the business function model based on granularity and scope
As the requirements are classified against the nodes within a business function model, it is important that the origination of the requirement be documented. Once this is done it is possible to check whether there are overlapping or duplicate requirements.
If an existing requirement fully covers the proposed requirement, then simply earmark the existing requirement as being relevant to the project. If an existing requirement partially covers a proposed requirement, propose a new version of the existing requirement and earmark both as being relevant to the project. Another potential scenario that would cause a new version to be split is when an existing requirement fully covers the proposed requirement but is partially implemented, with the unimplemented portion being required for this project. If there are no matches for the proposed requirement, register the new requirement with the repository and earmark it for the project.
The above graphic shows a scenario where the requirements from three projects are classified and attached to a business function model.
| Step | Description |
| 1 | Project ABC attaches a requirement against 8.6.1.2.1 Review Expense Request. There are no other requirements at this function node; so this requirement will be classified as a New Requirement. |
| 2 | Project ABC attaches a requirement against 8.6.1.2.1 Review Expense Request. There are no other requirements at this function node; so this requirement will be classified as a New Requirement. There are no other requirements at the 8.6.1.3.2 Transfer Funds function node; so this requirement will be classified as a New Requirement. The requirement encountered at 8.6.1.2.1 Review Expense Request is a sub-set of the requirements classified by Project XYZ; therefore a new version of the existing requirement is proposed that is versioned and extended. |
| 3 | Project DEF attaches a requirement against 8.6.1.3.2 Transfer funds. An identical existing requirement at 8.6.1.3.2 Transfer Funds is encountered. This requirement is then earmarked as a Duplicate Requirement, which gives a practitioner an indication that there is a potential reuse when identifying Services. |
Define a Data Consumption Model
The objective of a Data Consumption Model is to understand the key business entities within the scope of the project(s), determine where they fit with respect to semantic communities, and organize this information into a form that can be communicated and classified.
Here are the high-level steps that assist with this approach. (Over time, experienced practitioners collapse these steps into one streamlined activity.)
- Requirements attached to each node within the Business Function Model are reviewed noting nouns that infer business entities
- Understand synonyms and relationships between business entities.
- Convert pronouns (e.g. they, he, it) into inferred business entities.
- Identify possible actions on entities by noting verbs.
- Construct a Data Consumption model by detailing the business entity, its semantic community, and the identified CRUD operations applied against each business entity.
OK that’s all for now for SOA based requirements. In my next blog I will continue with the steps to identify services from these now classified requirements.
Good Luck, Now Go Architect….
An Enterprise Architect's Musings 