Activity decomposition is recorded using an Activity Decomposition Diagram, described in the chapter "Analyzing Activities." In CA Gen, this diagram is drawn using the Activity Hierarchy Diagramming tool.
Activity Dependency Diagrams, drawn using the Activity Dependency Diagramming tool, may be used to confirm decomposition.
The most reliable way to decompose activities is based on the life-cycle of a proposed business object type. This involves deciding exactly what the business objects are.
At high levels of the decomposition, it is not always obvious what the business object types are going to be. For example, a high-level subject area named human resources would certainly include the data representation of a business object type (that is, a primitive subject area/primitive function combination) called employee. However, a few levels of decomposition might be required before it became clear that offer, training course, and benefits are also business object types within human resources. It might even be true that employee is eventually divided into several smaller business object types.
The result is a paradox of sorts: business object types cannot be identified with full confidence until decomposition completes, but business object types are needed to complete decomposition. The solution is to identify high-level proposed business object types that reflect reasonable assumptions about the model.
Take, for example, the sub-function of the Human Resource Management function called Hiring. It would be reasonable to assume that Hiring deals with occurrences of a business object named applicant. To decompose Hiring into its elements, consider how applicant moves through its life-cycle. This is not a formal life-cycle analysis in which all possibilities for an entity type are considered. It is simply a recognition that there are certain phases through which an applicant proceeds during the Hiring process.
A potential life-cycle for applicant is shown as the following illustration.
The Hiring function can be decomposed into the sub-functions required to lead occurrences of applicant through its life-cycle. The following illustration shows an example of a decomposition of Human Resource Management that includes a decomposition of Hiring into its elements based on the life-cycle of applicant.
Whenever possible, decomposition of activities should be accomplished using this approach.
In some cases, particularly at higher levels of the decomposition hierarchy, it may be difficult to discern a clear life-cycle for a single proposed business object type.
Some high level functions are so broad that they include several readily identifiable proposed business object types, each of which have their own life-cycle. In such cases, functions can be decomposed based on their support for specific proposed business object types.
Consider, for example, the RECEIVING function of a company that sells cars. Assume that the company must receive both finished cars and spare parts and that finished cars and spare parts both undergo a different process when they are received. In this case, the RECEIVING function cannot be associated with the life-cycle of some proposed business object type. Instead, the RECEIVING function is associated with multiple life-cycles of multiple business object types, namely SPARE PARTS and FINISHED CARS. As a result, RECEIVING is decomposed based on the classification of its proposed business object types, as shown in the following illustration.
This sort of decomposition should be used only until a function is discovered to handle a single identifiable proposed business object type. From that point, the life-cycle of the proposed business object type should govern decomposition.
The principles of cohesion and coupling can be tested at each leg of the decomposition by drawing dependency diagrams, which are described in the chapter "Analyzing Activities."
Activities that are siblings should be dependent on one another in some fashion; that is, their parent should be cohesive.
At the same time, siblings should have few dependencies with functions with which they are not siblings; that is, their parent should be loosely coupled.
Any decomposition that results in siblings that are not interdependent or are highly dependent on non-sibling functions should be questioned.
This example illustrates the decomposition of a Procurement function for a hypothetical business.
Assume that Procurement is a highest level function, as depicted in the following illustration.
PROCUREMENT is a sufficiently broad grouping of activities that business object type classification would best be used to decompose it.
After some investigation, assume that the following proposed business object types are tentatively identified:
The resulting decomposition of Procurement based on this classification of proposed business object types might look as shown in the following illustration.
Each function deals with one proposed business object type:
Now take a look at the Supplier Management function. After some investigation, it turns out that Supplier Management involves several proposed business object types, too. In addition to supplier (the obvious one), it must deal with supplier products, supplier evaluations, and supplier contracts. The following illustration shows the resulting decomposition of Supplier Management based on this classification of proposed business object types.
After further analysis, assume that it becomes obvious that these proposed business object types are actual business object types. This might happen as the result of parallel decomposition in which the proposed business object type is discovered to have the characteristics of a primitive subject area (that is, having a clearly identifiable central entity type). If this is true, the functions at this level of decomposition are primitive functions (that is, responsible for managing the lives of entities of each of the central entity types).
The next level of decomposition, then, must yield processes rather than functions. Look at Supplier Administration, which is clearly concerned with the business object type supplier, whose central entity type is also supplier.
Assume that each supplier has a very simple life-cycle:
Based on this life-cycle, the highest level processes described for Supplier Administration might be those shown in the following illustration.
Dependency diagrams drawn at each of these legs will reveal high cohesion and loose coupling, thereby confirming the correctness of the decomposition.
For example, the Dependency Diagram shown in the following illustration shows how the siblings of Supplier Management are related.
Supplier products cannot be identified before suppliers are, and a supplier contract cannot be created until the supplier products are known.
Supplier Evaluation relies on the supplier contract as well as some additional information about deliveries maintained by a different sub-function of Procurement. Note that the dependency of Supplier Evaluation on a non-sibling function is more than offset by a high level of cohesion among its siblings.
|
Copyright © 2014 CA.
All rights reserved.
|
|