In analysis circles, it is common for practitioners to describe themselves as being either "data oriented" or "process oriented."
Data-oriented analysts typically begin an analysis project by building an entity-relationship diagram. After most of the data modeling work is done, they begin to identify the set of processes needed to manipulate the data based on the way they have modeled it. Some proponents of such data-oriented approaches even go so far as to say that the process model "drops out" of the data model.
Process-oriented analysts might begin an analysis project by creating a detailed functional decomposition accompanied by a thick sheaf of dependency diagrams. Once the details of the process interactions are well understood, they might model the data required to enable those processes.
Both schools of thought have their adherents, but in practice it turns out that each is lacking. Experience has shown that those who concentrate solely on defining data will miss some important processes and thereby, some important data. Likewise, those who focus on processes alone are likely to forget some critical element of data and, by implication, the processes that use them.
One obvious way to overcome the limitations of these one-dimensional approaches is to interleave the analysis of data and activities so that they can be used to confirm one another. By carefully adding detail to both sides of the model simultaneously, you can produce a more accurate and stable view of the part of the business being modeled. In practice, models built in this way tend to require less rework, be more complete in the initial pass, and generally exhibit higher quality than models built using either a data or a process emphasis.
This approach to defining and refining data and activities at the same time is called parallel decomposition. Parallel decomposition results in the definition of a set of business object types that include entity types and the processes that affect them.
Decomposition was introduced in the chapter "Analyzing Activities." The topic was activity decomposition: the breaking of a function or process into sub-functions or processes to refine one's understanding of the activities undertaken by the business.
There is a corresponding concept in the realm of data. Although not treated explicitly in the chapter "Analyzing Data" for data analysis, subject areas can decompose into subordinate subject areas or entity types just as functions can decompose into subordinate functions or processes.
In each successive layer of decomposition, whether of activities or data, more detail is added to the model, and its representation of business reality becomes more precise.
Copyright © 2014 CA.
All rights reserved.
|
|