Business Process Implementation for IT Professionals phần 5 pps

Weidenhaupt, K., et al., “Scenarios in System Development: Current Practice,” IEEE
Software, Vol. 15, No. 2, 1998, pp. 34–45.
Chapter 10: Role modeling
Overview
The concept of roles is utilized, either explicitly or implicitly, in various areas related to
the specification of enterprise automation needs. Unfortunately, there is no general
agreement as to the definition or characteristics of a role. That ambiguity results in
considerable confusion as to how to specify and use roles effectively, especially in the
development of process maps. The purpose of this chapter is to present a
comprehensive discussion of roles and their use in the enterprise.
Because of the close identification of the term role with stage plays and movies, the
tendency is to transfer that association to the understanding of roles in the enterprise.
While the analogy is close, there are some subtle differences that, if not recognized and
accounted for, can greatly confuse the concept and hinder the acceptance of roles as a
useful entity. For that reason, all the terms used here are carefully motivated and
defined. That allows deviation, as needed, from the popular notion of the term. In
addition, questions that arise from the current confusion in using roles (e.g., is
“customer” a role?) are addressed and answered.
Roles are automation assets, and as such all the concepts developed in Part I apply.
This chapter explicitly addresses many of those considerations. However, even if a
specific aspect is not explicitly addressed in this discussion, it still is important in a
design and development situation to explicitly consider all the management system
functions.


10.1 Basic definitions
Because a role must exist in an environment that utilizes other ambiguous terms, it is
necessary to define a number of those terms for an understanding of the overall
environment involved. Because there is a close analogy to the stage and movies,
examples are used that exploit that association as long as the analogy does not become
unduly strained. To successfully make that connection, it is necessary to define some

stage and movie terms in addition to those needed for enterprise auto- mation. The
relationships between the terms are described after the definitions.
10.1.1 Role
Appropriately, the first definition is that of role: A role is an unordered set of cohesive
activities. By that definition, a role is passive. It is defined by the collection activities
assigned to it. How those activities are defined and assigned becomes the crucial
element in role definition. Most of the confusion in the specification and use of roles
occurs because the set of activities involved is not well understood. That problem, as
well as a partial solution, will become clearer as the discussion proceeds.
The word cohesive is intended to indicate that the activities defining a role must have
some discernible relationship. The relationship can take many forms, but it must be able
to be explicitly identified. If there are activities assigned to a role for which the cohesive
property does not apply, those activities should be considered to be part of another role.
The activities that form a role are not in any predefined order. Order implies process, and
roles are independent of process. The same activity can be incorporated into multiple
roles. That, unfortunately, permits a greater degree of freedom in the specification of
roles than would be desirable. However, making the roles completely and mutually
exclusive in terms of their defined activities would result in an artificial model for a real
enterprise. Careful specification of the set of enterprise roles can minimize the inherent
confusion of overlapping activities. The specification of a set of roles for the enterprise is
investigated in more detail later in the discussion.
As entities, roles can have attributes, and the values of those attributes determine the
type of the role and its characteristics. Several types of roles are considered and
discussed in detail.
10.1.2 Activity
For the purposes of this discussion, the term activity generally is considered in its
commonly accepted usage. However, the formal definition also must consider the
purpose of the activity in relation to the enterprise: An activity is any work the primary
purpose of which is to change the state of the enterprise. Note that there is no indication
as to the characteristics of the work or how it is performed. That allows the definition of

many types of roles.
Work that is not primarily intended to change the state of the enterprise in some manner
is considered to be outside the scope of the enterprise, and the associated activity
cannot be used as part of a defined role. As one interesting result of that definition, we
can answer the question of whether customer is an enterprise role. Unfortunately, as
might be expected, the answer is maybe!
If the customer’s work efforts are not primarily intended to change the state of the
enterprise, even though eventually the result will be used in some fashion by the
enterprise, the customer is not performing an activity from the perspective of the
enterprise. Because the customer is not performing an activity, there is no customer role.
If, however, the customer is interacting with enterprise resources in a way that is
intended to directly change the state of the enterprise, then the customer is performing
an enterprise activity and, hence, an enterprise role. The role may be that of customer,
or it may be another defined enterprise role with a performer of “customer,” as discussed
in Section 10.1.3.
The discussion concerning the role of customer extends to any other prospective role
that is to be filled by individuals who are not employees of the enterprise. That would
include suppliers, consultants, government regulators, and service providers of various
types. The determination depends on the degree of planned interaction with enterprise
personnel in the fulfillment of an enterprise process.
10.1.3 Performer
Because role is defined to be passive, there must be some mechanism for the animation
of a role. In this case, animation means causing the activities defining a role to occur.
The mechanism for animation is through the use of a role performer. A role performer (or
performer for short) is some entity that animates a role by causing one or more of the
activities that define the role to be accomplished.
When a role is animated by a performer, an instance of the role is said to have been
created. A role is passive, but a role instance is dynamic. Depending on the number of
performers capable of performing the role, there may be many instances of the role in
existence at any given time.

Although a performer animates a role by performing some role activities, common usage
is to say that the performer performs (or “acts out,” in stage terminology) the role. Since it
engenders no confusion, that terminology is used because continued reference to
“animating a role” would be somewhat awkward.
A performer can be human or it can be a machine. The main concept is that the
performer is separate from the role. A performer may perform multiple roles, although
usually not at the same time. However, a role may be performed by many performers
simultaneously
Multiple types of roles can be defined. The type of role determines the needed
characteristics of the role performer. The reverse is not true. The performer does not
change the role (i.e., the activities to be performed). However, specific performers may, if
allowed by the control mechanism, perform the role in different ways (e.g., the sequence
of activities).
10.1.4 Control
Control of which role activities a performer is to perform is achieved through one of two
entities. In a play or a movie, the mechanism is a script. The script defines which roles
are needed and tells the performer of each role what lines to say when, in what manner
to say them, and how to behave as they are being said. In the enterprise environment,
the control mechanism is a process specification. The process defines which roles are
needed and guides the performer of each role as to how, when, and in what manner to
perform the defined activities of the role. In that sense, a process can be considered to
be an activity script.
There is a difference between a script and a process that needs to be understood so
there is no confusion in the utilization of the analogy. A script contains the instructions
that enable performers to elucidate a story by animating the roles. Only one context (set
of story attributes) is utilized. A process contains the instructions that enable performers
to elucidate a story using many different contexts. The specific context utilized for any
given instance of the story is provided by the scenario.
In a play, there usually are multiple roles. The focus (control) of the play is passed from
one role to another as orchestrated by the script. Likewise, in the enterprise there are

multiple roles. Control is passed from one role to another as directed by the process. The
role that is in control gives the performer of the role the ability to accomplish the specified
activities of the role. Some processes allow control to be shared by multiple roles. That
enables the roles to simultaneously have their activities accomplished by the assigned
performers. The concept of passing control from one role to another is important in
differentiating a role from a resource.
It is possible for a given performer to perform more than one role. That in no way
compromises the independence of the roles or diminishes their individuality. The choice
of performers for each role is a completely separate occurrence from the definition of the
individual roles.
10.1.5 Resource
Except for the most elementary set of activities, for a performer to perform a role, some
set of resources is needed. The resources can be in many forms. In a play, they are the
props, the set, or the costumes the performers wear. Those resources are not usually
considered to play a role. For example, if a performer, as part of the role being
performed, uses a knife in some fashion, one does not normally say that the knife is
performing a knife role. The knife is referred to as a prop. In general, in a play, humans
perform roles and inanimate objects are resources of some sort.
Likewise, if a role in an enterprise process requires that a performer utilize a resource as
part of the performance of the role, the resource is not performing a role. Unfortunately,
in this situation, the differentiation can be somewhat less clear than it is in the case of a
play. That results in considerable confusion as to what is a resource and what is a
performer performing a role.
As a quick aside, it must be admitted that at some level all entities involved in elucidating
a story can be considered resources, resulting in three potential types of resources:
entities not performing a role, entities performing a role, and data. As an aid to
understanding, it is useful to distinguish between those different types of entities from a
resource perspective. Toward that end, role performers are not referred to as resources.
Non-role-performer entities are considered role resources, and data also are considered
a separate type of resource. With this interpretation, the discussion can continue.

If a performer of a role uses a calculator to total some numbers in performing an activity,
it probably is evident that the calculator is a resource and that it is not performing a
(calculator) role. Now assume that, instead of adding the numbers as part of the role
activity, the performer of the role gives the list of numbers to another individual who
totals the numbers and gives the result back to the performer of the original role. The
performer then uses the total as needed in a subsequent activity. Is the individual who
totals the numbers a resource in the same way as the calculator, or is that person a
performer of the “number adder” role?
Now again change the example slightly. Assume that a performer is performing the same
role activity, but instead of either using a calculator or having another person perform the
number addition, an automated function or application is employed. The computer
application also can be viewed as a resource used to help the performer perform the
activity and a role activity being performed by an automated performer.
Some means of determining a uniform response to those situations from a “role”
perspective is necessary to provide a firm foundation for the specification of enterprise
roles. The following three principles allow a deterministic answer to the role-versus-
resource questions.
§ Principle 1: All inanimate objects (no intelligence) provide only a resource
and do not perform a role. In that sense, data are always a resource
because they have no inherent intelligence of their own.
§ Principle 2: All humans perform a role rather than merely provide a
resource. It is dehumanizing for a person to have only the status of a
resource.
§ Principle 3: Entities that contain machine intelligence (computers) and
provide an automated function perform an automated role when they
function independently of the role that initiates their operation. The
concept of independence is defined next.
If an automated function has at least one of the following characteristics, it is considered
independent of the initiating role and is defined to be an automated role. If it has none of
these characteristics, it is not independent of the initiating role and is considered a

resource of the initiating role.
§ The automated function provides some information to a role other than
the one that initiated it. Storing data in a shared database is not
considered to be providing information to another role unless database
interaction is the primary purpose of the function.
§ The automated function is able to complete its operation after the
initiating role terminates its normal activity. The initiating role does not
expect a direct response from the automated function.
§ The automated function is capable of independently deciding which of
multiple activities it should perform in response to a request.
Given those principles, the answers to the role-versus-resource questions would be
determined as follows:
§ The calculator is a resource. It has no inherent intelligence.
§ The number adder person is a role performer. He or she is human.
§ The number adder computer application can be either a resource or a
role. It depends on which of the characteristics in the preceding list are
involved. With the specific circumstances of the question as originally
stated, the automated application is a resource because it has none of
the defining characteristics of an automated role.
Although not explicitly defined, an automated role can utilize other automated functions
that may themselves be resources or other automated roles. The application of these
principles provides that determination in the same way as for human role performers.
It should be admitted at this point that the principles utilized to differentiate between a
role and a resource are somewhat pragmatic. They seem to follow the practice of many
organizations, but exceptions almost always seem to exist. However, the author has not
found any situations that cannot be resolved by applying the defined principles in a
reasonable fashion. For the remainder of this chapter and the rest of this book, the
determination of the existence of an automated role or the explicit definition of one is
consistent with the defined principles.

10.2 Role relationships
Figure 10.1 utilizes a modified E-R diagram to structure the relationships of the various
terms needed to place roles in their proper context. Such a representation inherently
presents a passive view of the structure. A dynamic aspect, associated with the
development and usage of the relationship structure, also needs to be presented.
Providing such a dynamic representation in a diagram format is difficult. However, by
stepping through the structure in the sequence that a process implementation and
operation would require, the use of the structure can be illustrated, although somewhat
imperfectly at this point. Later chapters provide a great deal more insight into the
dynamics of the structure.

Figure 10.1: Structure of role relationships.
Assume that a set of enterprise roles has been defined by specifying the activities each
contain. The dynamic properties of the relationship structure are then illustrated by the
following:
§ A script/process elucidates a story/scenario by specifying the particular roles
involved and then controlling the performers as to how they perform their
respective roles.
§ The control mechanism guides the performers as to when and in what manner
they perform the specific role activities required by the given story/scenario.
§ The performance of an activity can, as necessary, employ resources or the
direct CRUD of data. A resource can also directly access data and utilize
the CRUD functions, if appropriate to the resource.


10.3 Enterprise role specification
The determination of an effective set of enterprise roles is a difficult undertaking and one
for which few guidelines exist. Usually many different sets of roles could serve the
enterprise reasonably well, but the identification of even one of those sets is nebulous

enough that it almost never is attempted in practice.
Roles generally are determined on a process-specific basis. The problem with that
approach is the usual one that occurs when independent efforts define different elements
of the same set:
§ The same role has different names.
§ Different roles have the same name.
§ Roles that should be mutually exclusive are not.
§ Roles that are needed for required functions do not exist and that lack is not
detected.
§ Many more roles than really needed are defined because possible reuse is not
obtained.
It is possible to develop guidelines for the process-independent specification of
enterprise roles so that the majority of those problems can be avoided. In addition,
guidelines address the need to ensure that the set of roles conforms to enterprise
management and operational philosophy. This section motivates and articulates those
guidelines.
Although developing roles from an enterprise perspective is useful, it is not possible to
determine all the roles that the enterprise will need in that manner. There will always be
a need to define new roles from a process perspective. Because of the large number of
roles usually found in an enterprise and the inability for humans to deal effectively with
that complexity, the need for additional roles will arise as processes are defined in
enough detail to be implemented. Such exception-based specification is preferable to
trying to determine all the enterprise roles from only a process-by-process examination.
10.3.1 Role orientation
The first step in the determination of a set of roles for the enterprise is to determine
possible role orientations. Although orientation is only one of the role attributes that need
to be discussed, it is introduced at this time because of its importance in determining an
effective role structure. The other role attributes are considered in Section 10.4.
Actual roles can consist of a single orientation, or they can combine multiple orientations.
Possible role orientations along with some examples of each are defined in the following

list:
§ Organization unit: Warehouse worker, marketing department member,
finance department member, manufacturing depart- ment member;
§ Position title/description: Member of staff, strategic planner, janitor,
secretary, bookkeeper;
§ Management level: Foreman, supervisor, manager, department head,
director, officer;
§ Salary level: Nonexempt, exempt band 1, exempt band 2;
§ Degree/professional designation: Engineer, accountant, physician,
attorney;
§ Enumerated activities: “Makes copies, clears machine when it jams, calls
service when service light comes on”; “Bolts on steering wheel, mounts
dashboard, attaches radio antenna”;
§ Service provider: Travel agent, workstation repairer, help desk
representative;
§ Process step(s) performer: Bill producer, accounts payable check writer,
order taker, customer complaint handler.
Examples of roles that combine orientations are as follows:
§ Engineer; manager; exempt band 2;
§ Member of staff, finance department member, strategic planner;
§ Assembly line worker, nonexempt, “bolts on steering wheel, mounts
dashboard, attaches radio antenna.”
The exact titles of the roles are not really important, nor are the orientations used to
define them. Roles with various orientations can be mixed and matched as desired, as
later examples illustrate. The most important criterion is that every enterprise activity
needed for its operation is defined as part of at least one role. Although not quite as
important, the number of activities placed in multiple roles should be kept to a minimum,
to maintain consistency in role utilization.
There is one important exception to that criterion. It may be necessary for some activities
to be part of many roles (e.g., filling out a time card). That activity could be required by

human resources for all employees and would implicitly be a part of all roles. An efficient
way of handling such a case from the human resources perspective is through a general
role class.
The activities that belong to a specific role usually are not explicitly defined except for
roles that have a job description that enumerates them. (Hence this often related story:
When asked to do something a little different, the employee says, “I didn’t know that was
part of my job description.”)
Admittedly, having roles with implied activities can and does lead to some confusion.
However, it provides the necessary flexibility to handle new activities and situations
without the need to continuously create new roles or update the definitions of current
ones. For example, the role of “design engineer” may not have an explicit set of activities
associated with it. However, there generally is enough innate understanding of this role
so it can be reasonably determined if a given activity is contained in the role. That
common association of activities may not be true of an “administrative assistant” role.
Common sense must prevail in determining the degree of definition necessary for a role.
Although it has been stated that the names and orientations of roles are not really
important, it is also recognized that, from a practical perspective, the naming and
definition of roles is of considerable interest to the individuals who are expected to
perform them. Also, the enterprise usually is very interested in the defined set of roles to
maintain some agreement with the desired operational characteristics of the business.
To meet those needs, some general principles can be used in the definition of a set of
enterprise roles. These guidelines are to be viewed as general because in any given
enterprise the principles will, at times, conflict with each other. The importance and
priority of each must be evaluated as role definition proceeds.
§ Roles should reflect the management style of the enterprise. If the
enterprise is managed by organization entity, the role definitions should
maintain an organization orientation. If the enterprise is managed by
process, the roles should have a process orientation.
§ Roles should reflect any enterprise philosophy on the scope of individual
job assignments. If it is expected that an individual must be able to

perform a number of different activities, that should be reflected in role
definitions that contain several activities. If the enterprise believes
individuals should be limited to only a few activities, the role definitions
should reflect that philosophy.
§ Roles that are more clerical in nature should have the activities defined in
more detail than the activities of knowledge workers. Likewise, the
activities of knowledge worker roles should be defined in more detail than
those of executive roles.
§ Roles should reflect the characteristics of the enterprise. An enterprise in
a stable, slow-moving industry (e.g., paper towel manufacturing) needs
roles with activities defined in greater detail than the roles in an unstable,
fast-moving industry (e.g., Internet software development).
§ Roles should reflect those areas that the enterprise wants to emphasize
or deemphasize. If an enterprise needs to emphasize a certain area of its
operation, roles should be defined that specifically address that area. If
product A is the most important area of the enterprise, roles should be
defined to specifically address product A (e.g., product A program
manager, product A marketing manager). Conversely, if product A is to
be deemphasized, roles directly involving products would be defined
generically and not refer to product A specifically.
It is not necessary to keep roles static once they are defined. There are many reasons
that any current set of roles will have to be changed in some fashion. Because of the use
of role definitions in process specifications and other enterprise uses, referential integrity
is important. When the role set changes, any uses of the roles that change must be
identified and examined for any possible consequence. That requires that good
configuration management must be maintained, which requires the use of repository
techniques as part of the management process.
Any enterprise of significant size will have a large number of roles. A structured
approach to the specification of those roles that meets the needs articulated earlier is
required to manage the inherent complexity involved. Such an approach is outlined in

this discussion. It is presented only as a representation of the type of analysis needed to
obtain a comprehensive enterprise role set. For convenience, object-oriented notation
and concepts are used as a basis for representation of the ideas involved.
10.3.2 Role class structure
For the purpose of facilitating the introduction of the role structure, only the roles with an
association value of employee are initially addressed. In addition, consideration of
general role classes is deferred to Section 10.4.8.
Assume that an enterprise has a traditional philosophy of management and the high-
level organization chart depicted in Figure 10.2. In this case, most of the roles are going
to be organizationally oriented, and a portion of an associated role class structure might
take the form presented in Figure 10.3. Because of the complexity that would result if
complete structures were shown, for the purposes of this and the following sections, only
that portion of each structure necessary to illustrate the salient points being discussed is
provided. It is relatively easy to extend the diagrams to any degree of detail; if readers
are so inclined, it may be useful to model their own enterprise structures using the
described principles.

Figure 10.2: An enterprise organization chart.

Figure 10.3: An organization-oriented role class structure.
Note that the first level of the class hierarchy contains broadly defined roles similar to the
major organizations of the enterprise. Subsequent partitions of the roles can represent
smaller organizational units; finally, position descriptions generally are required (e.g.,
engineer, technician). It also is necessary to add other role orientations such as
management level (e.g., foreman, manager) and enumerated activities that further define
a role (e.g., television assembly worker, radio assembly worker).
Now assume that an enterprise has a philosophy of management by process and utilizes
the set of leaf processes depicted in Figure 10.4. In this case, most of the roles are going
to be process oriented and a portion of a role class hierarchy might take the form
presented in Figure 10.5.

Figure 10.4: Enterprise process definitions.

Figure 10.5: A process-oriented role class structure.
There is a considerable difference in the orientation of these role specifications from
those defined from an organizational perspective. As might be expected, each type of
orientation has advantages and disadvantages. The organization orientation makes it
relatively easy to specify a wide range of activities (usually implicitly) in a given role and
keep the number of roles somewhat low. The disadvantage is that the activities included
in the role are not easily specified, and a noncohesive activity set can easily result.
The process orientation results in an intuitive understanding of the activities included in a
role. The disadvantage is that the roles easily can become fragmented, and a large
number of roles with few activities can result.
Although not explicitly shown in the figures, the two role orientations can easily be mixed,
depending on the needs of the enterprise. For example, instead of the manager role (that
probably is somewhat nebulous from a process perspective) included in the process
orientation role structure in Figure 10.5, it might be more appropriate to substitute the
executive staff or the administration staff role from the organization orientation role
structure in Figure 10.4. As long as all the enterprise activities are included in at least
one role, the roles can be defined in any way that makes sense for the business.


10.4 Role attributes
In addition to role orientation, a number of other role attributes are needed to adequately
define the characteristics of individual roles. A useful set of role attributes and associated
values are provided in Table 10.1.
Table 10.1: Role Attributes and Values
Attribute Value Set
Orientation Organization
unit, position

title/description,
management
level, salary
level,
degree/professi
onal
designation,
enumerated
activities,
process step(s)
performer
Association Internal,
external
Performer type Human,
automated,
Table 10.1: Role Attributes and Values
Attribute Value Set
institution
Performer standing Internal,
external
Cardinality Singular,
multiple
Totality Whole, part
Persistence Permanent,
temporary
Node Branch, leaf
Dependence Primary,
shadow, tandem
10.4.1 Orientation
The orientation characteristics were discussed in Section 10.3.1; the reader is referred to

that discussion for examination of each of the possible values.
10.4.2 Association
Enterprise roles usually are considered to be internal to the enterprise. However, as has
been discussed, roles can be defined that are external to the enterprise (e.g., customer).
External roles must be used with extreme caution because the degree of control over the
performers is considerably less than that usually assumed for internal roles.
10.4.3 Performer type
Human and automated performers were discussed in Section 10.1.3. There can also be
institution performers that always have a standing (see Section 10.4.4) external to the
enterprise. Those performers usually are known as service providers. For example,
assume that a needed activity in an order-handling process is to determine a prospective
customer’s credit rating. That activity could be assigned to a role identified as some type
of institution such as a credit bureau. All that would be known about the activity is that it
will be performed by the assigned institution, hence the designation.
10.4.4 Performer standing
A performer can be located internal or external to the enterprise. An external role always
implies an external performer. Internal roles, however, may be performed by external
performers. There are two aspects to the use of external performers for internal roles.
The first is the use of consultants and contractors who are utilized to perform internal
roles frequently. However, from an economic point of view, they are the same as
employees since their services must be compensated.
Another desirable aspect occurs when it is possible to get cus- tomers and suppliers to
perform internal roles. In the discussion in Section 10.1.2 of the definition of the term
activity, it was noted that an internal role can be performed by a customer under the
appropriate circumstances. From the enterprise view, these types of external performers
essentially are providing “free” work.
As part of the ongoing analysis that should be performed as part of role life cycle
management, there should be an examination of the possibility of customers and
suppliers performing internal roles.
10.4.5 Cardinality

The cardinality of a role indicates the number of human performers that must closely
cooperate to perform the role activities effectively. That number usually is one, meaning
that a single individual performs the activities of a given role instance. There is a growing
tendency, however, to use a team approach in the performance of certain activities. For
example, assume that an activity is to “plan next year’s capital budget.” That probably
would be performed by multiple individuals acting together, and the role containing the
activity could be known as the “capital budget team.” That would be a role with a
cardinality greater than one.
10.4.6 Totality
When the cardinality of a role is greater than one, another aspect of the role must be
considered. For example, in the capital budget team role, each team member (role
performer) also has an individual role associated with the team role. That role could be
as simple as “capital budget team member” or the somewhat more complex “capital
budget team trend analysis member.” In any event, the collective (cardinality greater
than one) role would have a totality value of “whole” because it consists of all of the
activities assigned to the role. The individual roles would have a totality of “part” because
they would reflect only part of the activities of the entire role.
The totality attribute should not be confused with the node attribute (discussed in Section
10.4.8). Totality is defined only in conjunction with a role of cardinality greater than one.
The node attribute is defined for all roles.
10.4.7 Persistence
The persistence of a role indicates whether the role is temporary or permanent. A
permanent role is created with no identified time for elimination. It is to exist as long as it
is useful for the business. A temporary role is created for a specific purpose and time
period. It will then disappear. Most roles are permanent but in certain circumstances,
temporary roles are quite useful. The activities in a temporary role may themselves be
transient, or they may be permanent and only temporarily assigned to the role.
For example, assume an enterprise purchases another company and it is necessary to
merge the operations of the two organizations. Temporary roles could be created to
accommodate the temporary activities needed. Both are temporary because after the

organizations merge, neither the roles nor their activities will be needed.
In another example, assume that a permanent activity to “analyze competitor products” is
assigned to a role with a cardinality of one. Now assume that a significant change occurs
in the industry and that to “rebase” future analyses, a team of experts in different areas is
needed to perform the activity for a given period of time. After the rebasing takes place,
the team is no longer needed, and the activity can revert to its original role. In this case,
the activity did not change. However, the role necessary for performing the activity did
change on a temporary basis.
10.4.8 Node
In the role hierarchies illustrated in Figures 10.3 and 10.5, the roles are either branch
nodes or leaf nodes. The branch nodes have child nodes, while the leaf nodes do not. In
general, leaf nodes are the only ones used as operational roles by the enterprise. That
includes the use of roles as part of the process definition. The main purpose of the
branch nodes is to serve as a vehicle for the eventual definition of the leaf nodes.
However, they are also useful, in some situations, as a means to indicate a general role
class.
An example of the use of a general role class is the definition of a role called “employee.”
This role can stand for all employees when necessary. A process that puts new
employees on the payroll could use a general role such as this to avoid having to
enumerate all the different employee roles involved. Roles of this type could be included
in the role hierarchy shown in Figure 10.6. The employee role would then become the
root branch role for the hierarchies shown in Figures 10.3 and 10.5.

Figure 10.6: Addition of general roles to the class hierarchy.
It can be argued, with some justification, that the branch nodes do not need to be
characterized, and that, therefore, this attribute is not needed. However, there is some
use for branch nodes in the general characterization of certain role classes and for
containing activities common to large numbers of roles. Also, characterization of the leaf
nodes can be made easier through standard class inheritance techniques.
This attribute will be retained and the branch nodes characterized as needed.

10.4.9 Dependence
Roles can depend on other roles in addition to the dependency defined implicitly through
their use in a process. Roles that have no dependencies except as obtained through use
in the same process are called primary roles. Shadow roles are roles that depend on one
or more primary roles and are used to perform activities that closely interact with those of
the primary roles. The usual example is that of a management role.
For example, assume a role of “customer bill checker.” Assume further that a
management oversight role of “customer billing manager” also has been defined. If an
error is found by the bill checker role performer, the relevant information is sent to the
manager role. Other primary roles in the billing process also could utilize the same
customer billing manager role for errors, approvals, and other management functions.
The customer billing manager role is a shadow role, because it does not exist
independently of the primary roles that elucidate the customer billing process. Almost all
management roles are shadow roles because they cannot exist independently of the
roles they manage. The role being managed can, however, exist without the
management role.
Another type of shadow role would be a support role that provides additional information
to the primary role being supported. A popular example would be a sales support role
that contains research activities designed to help the sales role provide needed
information to prospective customers. The sales support role cannot exist independently
of the sales role, but the reverse is not true. Definition as a shadow role does not reduce
the importance of the role to the enterprise in any way. It is simply a way of
characterizing role dependencies.
Tandem roles are roles that require each other and must be defined together. Although
the term tandem implies two, any number of roles could be defined as part of a group
being utilized simultaneously. An example of tandem roles would be a trainee (student)
role and a trainer (teacher) role. It would be difficult to separate the two roles. Although
each could be used in some situations without the other, neither makes sense unless the
other role is associated with it.

10.5 Role utilization
The main reason to define roles in the enterprise is to provide a useful mechanism for
ensuring that the enterprise is operating efficiently and effectively. That is accomplished
using both construction and analysis techniques. Without the use of role definition, there
is no easy means to determine how well employees and their automated tools
(automated functionality) are being used in performing the activities of the enterprise.
Although automated roles have been defined for convenience, the main focus of roles is
toward the humans in the enterprise. That focus is evident in the following discussion.
In current organizations, especially those involved in high-technology industries, human
capital can be significantly more important than financial capital in ensuring future
success, although both certainly are necessary for survival. Human capital is really a
shorthand way of referring to the collective experience and abilities of the employees of
an enterprise. Roles represent an important tool for determining if (1) the human capital
is utilized wisely and (2) individuals are comfortable and reasonably happy with their
assigned activities. The discipline of explicit role definitions also provides a mechanism
for determining how the enterprise should respond to changing business and technology
pressures from the human capital perspective.
The explicit use of role specifications allows an enterprise to determine, for a specific
point in time, the characteristics and numbers of employees that are needed to
effectively and efficiently operate the enterprise or, conversely, how to best apply the
talents and experience of individuals that are already available.
Job descriptions, which are a form of role definition, historically have been used in the
enterprise to help define individual positions and the desired characteristics of the
employees who fill the positions. That, however, is a narrow utilization of the role concept
and does not easily permit any analysis as to the overall effectiveness of the positions as
defined. In addition, not all (or even a majority) of positions in an organization may have
job descriptions. In that case, because the definition of roles is not pervasive in the
enterprise, their usefulness as an analysis tool is further diminished.
Selected bibliography

Lupu, E., and M. Sloman, “A Policy-Based Role Object Model,” Proc. 1st Internatl. Enterprise
Distributed Object Computing Workshop, Gold Coast, Australia, Oct. 24–26, 1997, pp. 36–47.
Plaisant, C., and B. Shneiderman, “Organization Overviews and Role Manage- ment:
Inspiration for Future Desktop Environments,” Proc. 4th Workshop Enabling Technologies:
Infrastructure for Collaborative Enterprises, Morgantown, WV, Apr. 20–22, 1995, pp. 14–22.
Chapter 11: Information modeling
Effective management and utilization of information are required for an enterprise to
obtain and maintain a competitive advantage. Executive decisions, marketing strategies,
process improvement, and personnel motivation, along with many other crucial activities,
all depend on having the right information at the right time in the right format. With the
glut of information currently available, there is a growing need to identify and make
effective use of the specific sets of information that will enhance the operation of the
enterprise. An emerging technology known as knowledge management is attempting to
deal with the general problem of information overload. Although a general discussion of
that technology is well beyond the scope of this presentation, there are some similarities
with the discussion in this chapter, including a need to utilize a higher level of abstraction
than data, extensive modeling techniques, and the use of repository technology.
Modeling allows a consistent approach to the identification, control, and utilization of
information. Although information modeling (or data modeling, as it historically has been
called) has been in use since the beginning of computer applications, there is a growing
need for more extensive models than the relatively restrictive ones used in the past. The
purpose of this chapter is to motivate and develop a comprehensive information model
suitable for the fast-changing automation environment of the enterprise. To keep with
historical precedent, the term data modeling is used throughout this discussion, except
when it is necessary to differentiate between the concepts of data and information.
11.1 Background
Historically, the modeling of data has used several different formats. From the earliest
beginnings of general computer usage and data processing, data have been modeled
using the constructs of programming languages and still are for local data that will not be
shared between software programs. Fortran and Cobol, along with most other

languages, let programmers determine the layout, names, and characteristics of the data
(data model) needed by a program. Initially, the data were unique to the program in
which the data were defined. Shared data were later in coming and required that the
model (e.g., Fortran Common) be copied in all programs that needed it.
The purpose of those primitive data models was simply to allow the programmer to easily
couple the program logic with the data it required. Those models could be considered
logical models, because the programmer usually was not concerned with how the data
were actually stored in memory (the physical model). Some programmers, however, did
understand how the compiler directed the data to be stored and were able to circumvent
the model by directly accessing physical storage. (It should be noted that the problem of
circumventing models of various types continues to this day, usually with unanticipated
and unfortunate results.)
The need to define data models as an independent (from software development) activity
resulted from the development of mass storage devices. That need did motivate some
additional modeling concepts. File structures had to be defined with some thought
toward the most efficient way to access and utilize the sequential data format. From that
need comes the concept of the master file and transaction files. That operational data
model is still in use today, although some of the forms have changed to keep pace with
storage technology.
In addition to the modeling needed for efficient file design and utilization, another
modeling concept became popular. It resulted from the need for a procedure to
determine:
§ What specific data were needed for the individual automated functions;
§ The detailed characteristics of the data so they could be specified to the
software applications.
The result is the E-R model, which is usually depicted in diagrammatic form. That model,
or E-R diagram, the name by which it was usually known, was quickly adopted because
the number of functions being automated was increasing rapidly, as was the amount of
data that needed to be accommodated. An example of an E-R diagram is shown in
Figure 11.1.

Figure 11.1: An example of an E-R diagram.
In concept, an E-R diagram is relatively simple. The entities are represented by the
nodes (circles) of the diagram, and the relationships are represented by the lines. Both
entities and relationships can have attributes, illustrated by annotations in the figure, the
values of which determine their characteristics. Some additional, more complex
constructs are needed for practical modeling situations. For the purposes of this
discussion, however, it is not necessary to go further into the details of E-R model
notation.
Because of the power of the E-R model to identify problems with a data specification, it
was applied to the modeling of the entire enterprise. It is possible although somewhat
difficult, as these efforts indicated, to develop an E-R diagram for an entire enterprise.
Whether or not that was a useful activity depended heavily on the intended use of the
model. If the purpose was to identify and understand enterprise data, then it could have
been a useful exercise. If the purpose was to use the model as the basis for software
development, then the inherent structural complexity could—and usually did—greatly
hinder the use of the model. In many cases, that resulted in the development ignoring
the data model and using no model at all. E-R modeling fell on hard times.
The development and use of DBMSs have given rise to the new specialty of database
administrator (DBA), who was responsible for:
§ Mapping the enterprise data into the structure of the DBMS being used
(logical model);
§ Ensuring that the DBMS was efficiently used (physical model).
Software that used DBMS resident data had to understand the logical model of the data
to navigate through the DBMS structures to locate the desired data. Providing for
efficient response times usually was met by tuning the parameters that determined how
the DBMS stored the data on the bulk storage media being used.
With the advent of relational DBMS structures, data modeling took a somewhat different
path. Considerable emphasis, from a modeling perspective, was placed on data
normalization. The original purpose of normalization was to minimize the need to store a

given data item multiple times and thereby improve storage efficiency and integrity. That
is accomplished by defining data units that contain a cohesive set of data elements and,
with the exception of links between units, allow a data element to reside in only one unit.
In a relational model, those units are structured as tables.
While normalization is an excellent concept for a physical data model, there was an
unforeseen effect. The logical data models used for coupling with the software were also
being subject to normalization. That type of design made it difficult to find the data
contained in an intermediate data structure (e.g., purchase order). Link after link would
have to be followed, sometimes through three and four levels, before individual data
elements of interest could be found. Normalized data models, much like the E-R models,
were not well suited to the needs of software development.
The latest evolution of DBMS formats is based on objects, a format that has
considerable appeal for use with software based on object-oriented designs and
implementations. It also is considered useful for storing data that contain information
such as video, audio, text, and graphics. Data models for object DBMSs result from the
specification of the attributes for the object classes of interest. This area is of great
general interest, but the state of the art has not advanced to the point where it would
affect the discussions in this chapter.
Although several aspects of data models (physical, logical, operational) appeared at
various times in the evolution of data modeling, the focus of the models almost always
was on the following three concerns:
§ The specification and relationships of individual data elements;
§ The physical storage format of the data at the data element level;
§ An efficient means of handling the traffic load on the data storage mechanism.
The use of data models to facilitate the specification and utilization of
automation functionality generally were not considered. One of the few
exceptions was the development of the master and transaction file data
model, which was designed to ease the software design and operation
problem inherent in the use of the sequential files.
While the data-centric concerns are still quite valid, maintaining the data modeling focus

on them exclusively is no longer sufficient. Data models must also support the efficient
specification and utilization of automation functionality in the enterprise. Inclusion of that
view requires consideration of the information aspects of the enterprise as well as a
more effective way of incorporating that level of abstraction into the specification and
implementation of automation functionality.
To some extent, incorporation of both views requires shifting the overall focus of data
modeling to the information level abstraction rather than the data level, although both
must be included in the resultant model. Section 11.2 contains models designed to
provide the broader modeling scope and the shift of emphasis needed to address both
the information and data levels of abstraction.
For the purposes of the discussions in this book, information is considered to be data
with a usage context. For example, “customer name” is data because there is no
indication as to how it will be used. “Customer name” in a pending-order structure is
information, because “pending order” indicates how the customer name is to be used. In
general, information utilizes a higher abstraction level than the data it contains. That
differentiation will become clearer as the discussion proceeds.


11.2 Data modeling system
The purpose of the data modeling system as defined in this section is to provide a
comprehensive, unified structure that facilitates the efficient specification and utilization
of information and data in the automated operations of the enterprise. The system is
designed to meet the following needs (both old and new):
§ The determination of the data elements needed in the enterprise;
§ The use of the data elements to provide an effective physical implementation
of the data;
§ The ability to specify the data needs of the automation functionality at the
information level;
§ The ability to specify, access, and use the physical data elements at the
information level;

§ The ability to ensure that changes in any one area are reflected in all other
affected areas of the modeling system.
Those needs all must be met without incurring significant overhead costs to use the data
or requiring an excessive amount of administration and management effort. That
necessitates an approach that incorporates a method for self-definition of the data and
that uses a repository as an integral part of the model structure.
11.2.1 Modeling system dynamics
Figure 11.2 illustrates a data modeling system. Four component models must interact to
provide the overall system model. Each model has a specific purpose in the
management of the data specification. In addition, the DBMS may have its own internal
model. However, discussion of DBMS internal construction is well beyond the scope of
this presentation. The global aspects of the data modeling system are considered first to
determine the purpose and usage of each of the individual models. Once those
requirements have been established, the structure of each of the individual models can
be defined and discussed in additional detail.

Figure 11.2: Structure of a data modeling system.
In addition to the model components, a repository component is also included in the
system diagram. The repository indicates the requirement for saving all of the model
information as well as the ability to examine the modeling system for specification
problems or improvement opportunities. Maintenance of the referential integrity of the
model also requires repository services. As the discussion continues, it should be kept in
mind that many of the requirements placed on the models and their relationships are
dependent on use of a repository.
The modeling system is dynamic, although the diagram is not able to depict that aspect
very well. To convey an understanding of the model dynamics, a description of a typical
sequence of events is utilized, along with a description of the major characteristics of
each component model as it is invoked in response to the data system operation.
The first activity is the development of an enterprise logical data model. The purpose of
that model is to determine the data needs of the enterprise as a whole. As discussed

previously, any attempt to develop an enterprisewide definition of any type is fraught with
difficulty. That certainly does not mean it is not a useful effort, however. It can serve as
an excellent starting point to which additional items can be added as normal operations
necessitate.
Once the logical model has been defined, it is used for two entirely different purposes.
The first—and probably the most important—purpose is to provide the structural basis for
defining the physical model. The physical model is used to partition the data such that
they can be efficiently accessed by the operational software. The characteristics of the
DBMS product being utilized as well as the platform on which it resides are also major
inputs to the physical data model. The physical data model must meet the intent of the
logical model, but it is not required to mirror the logical model in every aspect. In fact, in
most cases it will not be able to do so and maintain adequate access characteristics.
Because the logical model defines the set of enterprise data elements and their
associated characteristics, it also forms a natural repository of data elements for other
models that need that information. Although the structure of the data elements used in
the logical model usually is not appropriate for incorporation into the other models, the
ability to provide a common set of data element names and associated characteristics is
important in maintaining consistency throughout the entire modeling system.
The information model provides the mechanism for defining and utilizing data as part of
the process specification. It is defined independently of the logical data model, and its
constructs are specifically designed to complement and integrate effectively with those
used to define the automation functionality. Because the components of the information
model eventually must be defined down to the data element level, the use of the
available element definitions from the logical model simplifies that aspect of model
development. In addition, given that the information model is designed to elicit all the
data element needs for a specific process implementation, it readily can be determined if
there is a gap in the definitions of the logical model for the process of interest.
The purpose of the operational model is to efficiently couple the data accessed through
the DBMS with the automation software. As such, it is not unlike the purpose of the
original data models specified through the use of programming language constructs or

the master/transaction file model.
This completes the dynamic description of the data modeling system. It should be noted
that each component model is defined from needs imposed from outside the data system
as well as needs that result from adjacent system components. The operation of the
system is continuous because it must respond rapidly to any changes in the needs of the
enterprise. The decoupling of the component models and their close integration with the
development phase with which they are associated make that kind of response possible.
As the components targeted to the specification and execution of automation software,
the information model and the operational data model specifically are used as integral
parts of the process implementation methodology and are covered in detail in the
following sections.
11.2.2 Information model
The information model structure and specification procedure are illustrated in Figure
11.3. This discussion proceeds in the context of a business process specification, which
is the preferable approach to the development of automation functionality.

Figure 11.3: Information model.
11.2.2.1 Information flows
The first activity is the definition of information flows for each step of the business
process. The initial definition of an information flow consists of a name and a business-
oriented description of its purpose and contents. The flows depict the logical types of
information needed for the successful execution of the process step.
Information as it is used in this discussion is merely a context specification at a relatively
high level of abstraction presented in terms understandable by business-oriented
personnel. The specification format would also be of interest to any technical personnel
who are not familiar with the specifics of traditional data modeling. Examples of
information flows would be: “customer profile repair ticket,” “items purchased,” and
“credit rating.”
The information flows should be defined independently of any current source of data
(e.g., database, legacy system). The goal is to identify the inherent information needs of

the process and not to determine how to get at the physical data the information
represents. The link between the physical data and the automation functionality are
specified by other components of the data modeling system. It should be noted that it
may be difficult for the participants in this information identification effort to divorce
themselves from their knowledge of the current locations of the information. However,
that must be accomplished if the information flow specifications are to accomplish their
purpose.
The intention of this type of specification is to separate the identification of information
need from the details of how the data elements are specified in the logical data model.
As has been stated, the logical data model is not in a form that can be easily adapted to
procedures for information determination.
Although the term flow is included because of its historical use, a dataflow diagram in the
classical sense is not required. A listing of the information flows for each process step
and their major characteristics (e.g., input, output, description, timeliness) is sufficient.
The specification of the information flows at this time serves two basic purposes:
§ It provides an indication as to the complexity of the process step.
§ It allows the business SMEs to provide advice and counsel on the
information requirements of the process in addition to the functionality
aspects.
The specification of the logical sources and sinks of the flows is not immediately
necessary and probably premature. However, that identification must be accomplished
before the information flow specification is completed.
11.2.2.2 Information structures
After the information flows are specified, the information structures derived from the
information flows must be identified. As indicated in Figure 11.3, an information flow can
consist of an entire information structure, or there can be several information flows
defined within a structure. The information structure serves as the authoritative source
for the information in the flow. Because a basic philosophy of the modeling approach
presented here is that the same information can be replicated in many places, it is
necessary to identify a means of obtaining the “official” copy of the information contents.

By convention, the specific information structure defined for an information flow contains
the official copy of the information in that flow.
As an example, assume that a needed information flow is “customer contact
information.” The official source of the information could be a set of data called
“customer profile” that would contain the information for customer contact as well as a
significant amount of other potential information about the customer (e.g., credit history).
“Customer profile” would then be identified as the information structure that contains the
customer contact information. Note that all of “customer profile” will be a single
information flow under some circumstances such as initial creation of a profile or a
general update of the information contained in the structure. Generally, every information
structure will also be defined as an information flow.
Because an information structure is also an information flow, it does not have to have a
different degree of definition than its component flows to be identified as an information
structure. In addition, the following discussion of selecting data elements for each flow
also applies to information structures. If possible, the data elements for the information
structure should be selected first. That makes it easier to select those for the other
information flows it contains. In many cases, however, the data element population
proceeds in an opposite sequence. The data elements for the component flows are
selected first, and the union of those are used to populate the information structure.
Either way works, as does a combination approach. In any case, the data elements of
each information flow must be consistent with the data elements contained in its defining
structure.
11.2.2.3 Data element specification
After the information structures are identified, it is necessary to determine which specific
data elements will constitute each information flow. The basic approach is to use the
description of the flow to examine data elements:
§ As defined in any of the structures of the logical data model;
§ As contained in the defining information structure of the flow.
A determination then can be made as to which elements would be appropriate for
inclusion in the definition of the flow. The elements selected are examined to determine

what gaps, overlaps, conflicts, or inconsistencies may exist. Those problems are
resolved by going back to the logical data model for new or replacement elements and
eliminating currently specified ones.
This is an iterative procedure and must be repeated several times before an acceptable
information flow specification at the element level can be achieved. The need for data
elements that have not been specified in the logical data model is also quite likely. In that
case, they must be added to the logical model as well as the information flow.
When a set of data elements has been identified for an information flow, the elements
must also be examined in light of the functionality for the process steps in which they are
used. That analysis may show the need for additional data elements or the inclusion of
inappropriate ones. The process always remains the base specification against which all
modeling constructs must be validated.
The same data element may appear in multiple flows. Elements are not normalized
across flows. Remember that the purpose of the information flow is to facilitate the
specification of the data needed for a process step. Molding it into an artificial construct
that will obscure the purpose of the information must be avoided. A convenient method
of managing such replication through naming conventions is discussed in Section
11.2.2.5.
Continuing with the “customer profile” example, assume that in addition to a “customer
contact” information flow, a “customer type” flow is defined for use in selling new
products. The latter flow indicates the level of services needed by the customer. Some of
the elements included in the “customer contact” flow might be:
§ Name;
§ Street address;
§ City;
§ County;
§ State;
§ Zip code;
§ Main telephone number;
§ E-mail address;

§ Fax number.
Some of the elements included in the “customer type” flow might be:
§ Name;
§ Main telephone number;
§ Customer size;
§ Mobile phone number;
§ Other phone numbers;
§ Pager number;
§ E-mail address;
§ Fax number.
As stated, the purpose of those elements is to indicate the level of services utilized by
the customer. Note that some of the same elements are used in each flow since the
desire is to have each flow as a complete entity. Even though an element appears in
multiple flows, it would appear only once in the information structure itself. For the above
assumptions, the elements in the “customer profile” structure would be (in no particular
order):
§ Name;
§ Street address;
§ City;
§ County;
§ State;
§ Zip code;
§ Main telephone number;
§ E-mail address;
§ Fax number;
§ Customer size;
§ Mobile phone number;
§ Other phone numbers;
§ Pager number.
Additional information flows defined for this structure could add more elements, or they

could use those elements already defined for the structure.
11.2.2.4 Datastores
Once the data elements of an information flow have been determined, a source or a sink
of the flow must be identified. The source or a sink of an information flow is called a
datastore. The base location of an information structure is also in a datastore. An
individual datastore may be a source of information, a sink for information, or both.
Datastores may have a considerable amount of implied intelligence, although they can
always be reformulated (at a cost) as containing no intelligence. That aspect is illustrated
in Figure 11.4. Requesting information from a datastore is accomplished through a key
mechanism. The request key can be complex or simple; an example that uses a complex
key is given later. The datastore structure is compatible with the models developed in the
following chapters.

Figure 11.4: Datastore configurations.
As an example, assume that a datastore is defined that serves as a source of equipment
costs. The input (or key) to obtain cost information from the datastore is a specific
equipment configuration. The output is the cost of the configuration. The datastore could
be organized as a table that contains entries for each possible type of configuration and
the cost associated with each configuration. With a large number of possible
combinations that may be undergoing considerable change, this approach easily could
be impractical. Another approach is to create a program that calculates the cost based
on the configuration presented and a set of business rules that contain the costing policy.
From a user perspective, there is no difference between these two implementations
(except possibly the response time). The datastore is specified only on the basis of the
information desired (configuration cost) and not on how it is obtained (e.g., table or
program logic). If a datastore consists of more than static data, it sometimes is referred
to as an intelligent datastore. The same discussion can be utilized for the other CRUD
operations. The user view remains the same, but the implementation may vary
considerably.
More information on the use of datastores is given in Chapter 13, which discusses the

structure and use of functionality elements called actions. Actions interact with
datastores to access the data needed to perform the indicated function. Actions assume
that all functionality is provided by intelligent datastores regardless of actual
implementation.
If existing datastore definitions are available from the previous implementation of other
processes, it would be useful to examine their definition and data elements to determine
if they would be suitable for the current process. That is the data equivalent of reusing
process activities and associated functionality. The determination as to the suitability of a
previously defined datastore can be accomplished only through a detailed knowledge of
the process being implemented and the definition of the existing datastore. Because an
existing datastore contains a relatively rich set of data as needed by the previous
process implementation, its use would be advantageous later in the design. However,
the use of an existing datastore should not be forced, because it may compromise the
design if a good fit does not exist. Seasoned engineering judgment is needed in the
effort as well as excellent documentation.
It is not necessary to assume that an information flow will use one and only one
datastore and is probably counterproductive. Continuing with the example, again
consider a “customer contact” information flow as defined earlier. A source for this
information could be a datastore called “customer information,” which contains basic
information on all customers.
There could be multiple sinks for the customer contact information, including a “customer
contact” datastore, which contains a record of all customer contacts; a “pending order”
datastore, which contains a record on all pending service orders; and others depending
on the process being implemented. Those datastores could, in turn, serve as a source
for the information as needed in subsequent process steps.
Because each datastore has a different logical purpose, it is conceptually easier to keep
all the information needed for each logical purpose together even if some of the
information is duplicated (e.g., customer contact). Initially thinking in terms of the
purpose of the information rather than its content results in more efficient automation
design and development.

11.2.2.5 Naming convention
A naming convention is an effective means to keep the replication of data elements
under control. In addition, it provides for the self-definition of the data when used under
operational conditions. Although many formats could be utilized, the naming convention
that will be utilized for the data elements is as follows:
datastore name.information structure name.information flow name.data element name
(value)
or DS.IS.IF.DE (value) for short. Minus the value, this format is referred to as the fully
qualified name for a data element; alternatively, it is called a data item. The data element
name portion of a data item can also have components of its own, depending on how the
data elements are specified in the logical data model. Each unique fully qualified name
can have a different value for the data element in the same invocation instance. Although
that will be relatively infrequent, there are conditions under which it is a useful feature.
One of the most compelling conditions is utilization of legacy or COTS systems that have
their own inherent element or value structures that must be accommodated. The
operational aspects of this naming convention are considered in detail in Section 11.2.3.
11.2.3 Operational model
The purpose of the operational model is twofold. The first is to provide a structure
through which the physical data elements can be accessed by the automation software
at the information level. That allows the software developer to work with data at a level
higher than data elements when appropriate but still have access to the individual
elements as needed for the functionality to be implemented. While the specification of
data at the information level probably is not that unusual an idea, the access and control
of data at the information level certainly are. However, this aspect is needed to facilitate
the specification and development of automation functionality.
The second aspect of the operational data model is to allow for effective use of the self-
defining aspects of the data. The metadata inherent in the fully qualified name provides
the self-defining feature. Self-defining data provide a significant number of advantages
during the operational phase of automation software. Some of the major advantages are
the following:

§ The operational model need not be statically defined. Data needed
during any given invocation of the software may vary depending on the
path taken through the process being followed.
§ The presence or absence of a given data item, regardless of value, can
easily be detected.
§ The same data item can be given multiple values by changing its fully
qualified name (e.g., utilizing a different datastore name).
§ The elements in an information structure or information flow can be
changed to accommodate new applications without the need to change
existing software.
§ New datastores, information flows, and information structures can be
defined without the need to change existing software.
§ The needs of transient software components, such as Java Beans, can
be easily accommodated.
As an example of direct utilization of the information level, consider a customer
verification activity from an order entry process. Assume that there are two information
flows of interest: “customer profile” and “customer-provided information.” To provide
verification as to the identity of the individual placing the order, the information provided
by the customer must match the information in the customer profile. That certainly can
be accomplished at an element level, but it is far more efficient and meaningful to do it at
the information level. In high-level pseudo-code:
Get customer profile
Get customer provided information
If customer provided information [elements given] =
customer profile [associated elements] continue
else go to terminate order activity
What that indicates is that all the elements obtained from the customer must match the
same elements in the customer profile for the order to be processed. It should not be
necessary to determine in advance which elements are to be compared or even what
elements are in the customer profile information flow. Although there will have to be a

fragment of infrastructure code that actually compares the data items, their self-defining
feature makes the development of that type of generic functionality very efficient. The
operational model provides the concepts, structures, and overall framework to
accommodate that type of information use.
An illustration of one design for an operational model is shown in Figure 11.5. The DBMS
structure, although not a direct part of the model, is included in the diagram for
completeness of the illustration. The concept of a cluster store, discussed in Section
11.2.3.1, is central to the model structure. The reason for this particular terminology will
be evident in the presentation of the process implementation methodology.

Figure 11.5: Operational model.
Note that both logical and physical data paths are shown. The logical path indicates the
relationship or mapping between the datastore and the physical storage for a specific
information flow. The physical path is more representative of how the data transfer would
be controlled and transported in an actual implementation. For that reason, the scenario
examples, which are utilized to indicate the dynamics of the model, will use the physical
path as an explicit part of the specification.
11.2.3.1 Cluster store
The cluster store contains all the data items needed by the software functions for a
specific task. At that point, the cluster store can be thought of as local data, although, as
is explained in Chapter 13, the concept is much more powerful than that. The concept
and definition of a task are contained in the discussion presented in the workflow
discussion in Chapter 15. Required data from persistent storage must be explicitly
obtained. For the immediate purpose of this discussion, a task may be considered as all
activities of a single role that are performed by a given role performer in a continuous
time interval. Thus, all the data considered during that time interval are available to any
activity during the same interval. The great power of this construct will become evident
during the implementation methodology discussion.
All the data in the cluster store are formatted according to the DS.IS.IF.DE (value) format
presented in Section 11.2.2.5. Data can be accessed and utilized at any level in the

name (e.g., by information structure name). The types of operations that can be
performed on the cluster store data are defined and discussed in detail in Chapter 13.
Although this postponement probably is not very satisfying to the reader, because of the
uniqueness of the approach, it is necessary to develop a large number of basic concepts
and models before they can be brought together into an integrated structure that
achieves the desired results.
11.2.3.2 Dynamics
The overall dynamics of the operational data model are considered through the use of
high-level scenario stories. Only a few are considered, but that should be enough to
provide the necessary understanding for later discussions that incorporate this concept.
Scenario 1: Retrieval of information from a datastore
1. Function 1 requests the “customer contact” information flow from
the “customer information” datastore.
2. The request is given to the cluster store control by way of the
function execution environment. (This environment provides a
standard means of communication between the individual
functions and the cluster store and cluster store control.)
3. The cluster store control queries the location map to determine
which DBMS contains the “customer contact” information flow
from the “customer profile” datastore. (Logically, this map would
be in the repository.)
4. The request is then sent to the physical data control that locates
and accesses the desired data from the identified database.
5. The physical data control sends the data through the network
connection to the cluster store under control of the cluster store
control.
6. When the “customer contact” information flow is available in the
cluster store, the cluster store control notifies the function
execution environment, which then notifies function 1.
7. A subset of the data in the cluster store is now as follows:

§ customer information.customer profile.customer
contact.name
§ customer information.customer profile.customer
contact.street address
§ customer information.customer profile.customer
contact.city
§ customer information.customer profile.customer
contact.county
§ customer information.customer profile.customer
contact.state
§ customer information.customer profile.customer
contact.zip code
§ customer information.customer profile.customer
contact.main telephone number
§ customer information.customer profile.customer
contact.e-mail address
§ customer information.customer profile.customer
contact.fax number
Scenario 2: Copy of an information flow
Function 2 requests the “customer contact” information flow from the “customer
information” datastore be copied as the “customer contact” information flow for the
“repair ticket” datastore.
1. The request is given to the cluster store control by way of the
function execution environment.
2. The cluster store control locates all data items of the form (xx
means “don’t care”): customer information.customer
profile.customer contact.xx.
3. For each item located, it forms a new data item of the form: repair
ticket.customer profile.customer contact.xx.
4. The “don’t care” levels are copied without change.

5. A subset of the data in the cluster store is now as follows:
§ customer information.customer profile.customer
contact.name
§ customer information.customer profile.customer
contact.street address
§ customer information.customer profile.customer
contact.city
§ customer information.customer profile.customer
contact.county
§ customer information.customer profile.customer
contact.state
§ customer information.customer profile.customer
contact.zip code
§ customer information.customer profile.customer
contact.main telephone number
§ customer information.customer profile.customer
contact.e-mail address