Business Process Implementation for IT Professionals phần 5 pps

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.. How

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.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

§ 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 level organization chart depicted in Figure 10.2 In this case, most of the roles are going

high-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

unit, position title/description, management level, salary level, degree/professional

designation, enumerated activities, process step(s) performer

external

automated,

Table 10.1: Role Attributes and Values

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 activi ty 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 us e 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

§ 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