This is third part of a four-part article series. The first two parts are published at Service Portfolio Management - Part I, and Part II
Building Static Models of the Business Entities
Another aspect that governance should monitor is the creation of static business models that define the information (data) that each organization uses to conduct its affairs. The techniques of data modeling are well established, and data models can be readily implemented as they translate directly to physical relational database structures.
There are three essential concepts to static data modeling – attributes, entities and relationships.
- Attributes - are simple variables that can be assigned a single unambiguous value.
For example cost = $23.99, color = blue, height = 6'2", etc.
- Entities - represent collections of attributes that describe a single physical instance of a specific type of object. For example, an entity describing a person might have attributes of date of birth, sex, title, family name, first name, middle initials etc. Individual people (such as instances of a Person entity) will, of course, have distinct sets of attribute values.
- Relationships - represent linkages between two or more entities. For example, lives at might represent a relationship between an entity representing a Person and another entity representing a Building. Relationships are more complex than attributes or entities:
- Relationships are directional. In the lives at relationship example above, the primary entity is Person and the secondary entity is Building. If we looked at the inverse of this relationship, (such as from the perspective of the Building entity), we would have a different relationship that reads Building houses Person
- Relationships have cardinality that describes how many instances of the secondary entity can be involved in a relationship for a given primary entity. Possible cardinality values are 0 to 1, 1 and only 1, 0 to many or 1 to many. For the example above, each Person lives at 0 to many Buildings, and each Building houses 0 to many People.
Sometimes, there is a need to store attributes that belong to the relationship itself rather than to either the primary or secondary entities themselves. In this case, the data modeler creates an attributive entity that contains those attributes. For example, a better way of defining who lives where might be to create the attributive entity residency with the attributes start date and end date. The relationship that describes who lives where now becomes:
- a Person has 1 to many residencies ('has' being the generic term for having a relationship)
- a residency has 1 and only 1 Building
Relationships are generally bi-directional. The inverse relationships between a person, residency and building are:
- a Building has 0 to many residencies
- each residency has 1 and only 1 Person
This approach now allows us to describe how the lives at relationship varies over time.
Static information models are commonly referred to as Entity-Relationship (ER) models. Since data modeling activities generally start by examining the physical data the organization already maintains, the process of creating a physical data model is often termed bottom-up modeling.
An important attribute of an ER model is the principle of normalization, which requires that each data attribute is attached to one and only one entity. For example, the attribute or attributes representing the name of a single Person should appear nowhere else in the ER model other than as part of that Person entity. In other words, the only way to determine an individual's name is to locate the corresponding Person entity and access its name attributes. The value of this becomes clear when you realize that you would only ever have to change the name of a Person in just one place, when it will become effective immediately, whoever else refers to that individual.
The relationship between ER models and physical relational databases is very close. Each type of entity corresponds to a separate database table. Columns in that table contain values for individual attributes, and each row in the table thus describes the values of each attribute for a specific instance of that entity. Each row in a data table is given a separate key that serves as its unique identifier, and relationships are stored in separate tables that reference the associated entity instances through their primary keys.
In the interests of standardization and reducing complexity, no organization should attempt to create an ER model from scratch but should start with an existing model and make a minimum set of necessary changes to it. Many software application packages (for example, enterprise resource planning or ERP) are based on a standardized ER model. Common standard models exist for many industries, for example:
A Case Study Example
McPherson Corp. had already made a commitment to using the industry standard ER model that was implemented in Tri-Fold's Enterprise Resource Planning (ERP) package, so from Tri-Fold's perspective, creating a federated inventory management system seemed quite feasible.
However, when the Tri-Fold and Alleywood data analysts conferred, they came up with some major issues that included:
Alleywood operates in both the US and Canada. The US uses the Imperial measurement system (pounds, feet, and inches), while Canada and most of the rest of the world uses the metrics system (kilograms, meters, and centimeters). Standard lumber sizes used by the two countries differ, though there are some overlaps.
Like everyone else, Alleywood and Tri-Fold both use a label called a stock keeping unit (SKU) to uniquely identify each product. However, there is no coordination whatsoever between the values used for these SKUs. Different subsidiaries, and even different locations in a single subsidiary, can use different SKUs for the same product or the same SKU for different products. Migrating all subsidiaries to a common set of SKUs would cause unacceptable disruption.
With the exception of some basic attributes such as name, short description, unit of measurement (such as unit, carton, pallet) and pricing information, different products have totally different sets of attributes.
The Solution Architect understood these problems but didn't believe that they were show-stoppers for the concept of a federated inventory. He suggested that theses issues could be resolved by mandating the following functional requirements for any federated inventory system:
- The creation of a set of standardized SKUs to be used only when transmitting product or inventory information between subsidiaries. Subsidiaries could continue to use their own SKUs internally and would not have to modify their IT systems to support those standardized SKUs.
- Creation of a canonical (standardized) Product Profile entity that contains a set of product summary information common to all products, whether they are raw materials, components, finished products, or waste material. This canonical form would implement the new SKU standards.
- Development of a standardized facility to mediate (translate) between this canonical form and whatever format the data is used by each subsidiary data repository. This mediation must be bi-directional.
- Creation of a system that maintains a set of equivalent, alternative or replacement products. Given a SKU representing a specific product, this system would generate a list of SKUs that represent a viable substitute.
The SGPO met and decided that, even though the effort of implementing a federated inventory management system was likely to be high, the probable benefit to the McPherson Corporation would be enormous. They unanimously recommended that an effort to create a service model to examine the potential for a service oriented solution to this business need should begin immediately.
Constructing a Business Service Model
The next step is for governance to ensure that the business process model and business data models that cover each specific area of interest are combined effectively into a single business service model.
Individual business processes often translate almost directly into business services. Every process must have some sort of input or event that initiates it and must produce some sort of output; otherwise it would have no business value. The inputs and outputs of business processes (messages between business processes) can generally be expressed in terms of business entities, though the complex business processes towards the top of the process chain may produce abstract entities such as plans, reports, or decisions.
The main difference between process models and service models is that process models focus on the business activities and tasks, while service models are also interested in the inputs and outputs of those tasks. Generally, those can be expressed as logical or physical entities.
The most reusable processes or services are those that are agnostic in nature, meaning that they can be executed independently of any parent processor task, and in any order. Non-agnostic services could be built, but would have little reusability, and these types of processes are best handled by dedicated applications. Examples of non-agnostic processes are text, spreadsheet or graphical editing, or traffic management.
Establishing the Business Domains
Business processes and services can generally be grouped into a set of logical domains that cover specific areas of interest. This can help in establishing ownership of the services and determining potential consumers.
Since ER models tend to concentrate on physical objects, it is not unusual to find that the ER model does not contain some of the logical entities that the business domain implies. In this case, the best approach is to create a new logical or abstract entity to match that domain. Ideally, each logical or physical asset or entity will belong to a specific business domain, although it may well be produced or used by a different domain.
It is important to create clear distinctions between related but independent entities. A sales plan is distinct from a set of physical sales, for example, and a corporate budget is a different artifact from a departmental budget, even though clear relationships exist between them. A good way to model these would be to create a generic sales domain that included planned sales and actual sales sub-domains and a budget domain or abstract entity that contains the sub-domains corporate budget and departmental budget.
The next step is to re-cast all the processes in the business process model and assign each of them to a specific business domain or sub-domain. This is an iterative process, and it is likely that some changes will need to be made to the domain structure. After a few iterations, the business domains should have distinct, meaningful boundaries.
If the business analysis has reached a significant level of depth, it is likely that some services may have been identified that can't be classified as belonging to any specific service domain or related to any single business entity but that appear to be common to multiple leaf level business processes. These represent utility services that can be assigned to a common services domain. Examples include print, send, or raise alert.
Figure 1 - Individual business domains, sub-domains and a common utility domain.
Classification of Services into Service Layers
Services may also be classified into layers. Chapters 6 and 7 of SOA Design Patterns described three service layers, task services, entity services, and utility services:
- Task services - contain complex business logic and may require hours to days to complete. Domains representing abstract entities tend to contain a high proportion of such services. Extreme examples of task services might include prepare annual report or create sales forecast.
- Entity services - contain relatively little business logic and typically deal with a specific business entity. Examples might include obtaining, manipulating or storing data about a specific entity and creating or deleting a relationship between groups of entities (for example, change of address). Some of these services may include a significant amount of logic to manipulate data.
- Utility services - perform common housekeeping functions that are not associated with or restricted to a specific business entity.
Figure 2 - Service model layers (note - this is a copy of Fig. 6.21 in the SOA Design Patterns book)
A Case Study Example
The Business Analyst and solution architect looked at the product inventory management processes and decided that the principal service domain of interest was the Product Inventory domain. Within this domain, they decided to create two sub domains:
- A local product inventory domain that is responsible for managing physical inventory at a single specific location. Each manufacturing or warehousing location of each subsidiary would have an instance of this domain.
- A federated product inventory domain that manages inventory at a global level by interacting with all local inventory instances. There would be only one instance of this domain.
The team also identified the existence of additional service domains, the product forecast and production plan domains that would have significant interactions with the inventory domain but decided not to develop service models for these domains at the present time. Their service domain model is pictured below:
Figure 3 - The initial McPherson business domain model.
The following services within each domain were identified:
Federated Product Inventory Domain
|plan total stock levels
||create or adjust plans for total stock levels by product and date
|assign local stock levels
||allocate individual inventory levels by location, product and date
|monitor total stock level
||track whether total inventory plan is being followed
|total physical stock
||calculate actual quantities by product and date (current, future or historic)
|total available stock
||calculate available quantities by product and date (current, future or historic)
|physical stock locations
||calculate actual quantity by product, location and date
|available stock locations
||calculate available quantity by product, location and date
Local Product Inventory Domain
|plan local stock levels
||negotiate future inventory plan with production planning
|monitor local stock level
||compare physical and available inventory levels with plan
|local physical stock
||calculate actual quantity by product and date
|local stock availability
||calculate available quantity by product and date
||reserve inventory by product, customer and date
||adjust inventory levels (e.g. for sales, new manufacturing, shipment)
||translate between global SKU and local product numbers
||for given global SKU, provide list of substitute or alternative SKUs
The rationale for describing these as utility services is that since SKUs are attributes rather than complete entities, services that manipulate SKUs can be considered as common utility functions.
The next article will conclude this series by stepping through the creating of an initial service portfolio.