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. [...]... 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 businessoriented 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...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... 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... 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... 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... 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... 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... 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... 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... 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 . 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. 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. 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