This paper combines ideas from separate research streams to identify high-level design choices related to the scope and content of enterprise models. It summarizes the work system modeling method (WSMM), an extension of a long research stream related to seeing enterprises as interacting work systems. It applies a recently developed framework for describing theoretical perspectives to articulate numerous aspects of a work system perspective on enterprise modeling (EM). This paper's main contributions include its approach for exploring conceptual or theoretical starting points for enterprise modeling and its expanded view of a work system perspective on enterprise modeling.
to illuminate many EM design choices. Some of those choices are obvious, but others point to areas that EM does not touch or purposefully avoids even though they might be quite relevant for stakeholders trying to understand processes or enterprises. 2
A work system is a system in which human participants and/or machines perform
processes and activities using information, technology, and other resources to produce
product/services for internal and/or external customers.[
The definition of work system implies that work system is a very general case that includes many special cases such as information systems, supply chains, service systems, projects, and totally automated work systems. For example, an IS is a WS most of whose activities are devoted to processing information. Supply chains are WSs that extend across multiple organizations to provide resources for other organizations. Projects are WSs that produce specific product/services and then go out of existence. Totally automated WSs perform activities autonomously without human participants. An enterprise is a configuration of interacting WSs that pursues overarching goals.
Work system method. WSM is a semi-formal systems analysis and design approach
that was developed over several decades to help business professionals visualize WSs
in their own organizations and collaborate more effectively with IT professionals [
While details differ, every version of WSM is organized as follows: 1) identify the smallest work system that has the problem or opportunity; 2) summarize the “as-is” work system using a work system snapshot (example in Table 2), a stylized one page summary; 3) evaluate the work system’s operation using measures of performance, key incidents, social relations, and other factors; 4) drill down further as necessary; 5) propose changes by producing a work system snapshot of a proposed “to be” work system that will probably perform better; 6) describe likely performance improvements.
Work system theory. WST [
Initial attempts to bring a work system perspective to EM started with a discussion
about a diagram in [
That discussion led to considering difficulties in the practical application of EM. A
BISE research note [
Those issues led to the development of the work system modeling method (WSMM),
which extends WSM into the realm of EM [
Design space for modeling methods and modeling techniques. Combining those
requirements with experience related to WSM and WST led to defining WSMM as an
extension of previous developments. As described in [
The shaded area in Fig. 2 positions most of the modeling techniques that WSM users
have applied. Most of those techniques focus on topics such as work system scope and
operation, and activity/resource dependencies. Those techniques are relatively low in
specificity compared to techniques that might be used for high precision description,
system simulation, or code generation. Fig. 2 identifies BPMN, ArchiMate, DEMO,
and MEMO as examples of modeling approaches that address P5 and P6. [
P1: System identification P2: System capabilities P3: System scope and operation P4: Activity/resource dependencies P5: High precision description P6: System simulation P7: Code generation
Most modeling r ed se techniques used with loh sop WSM teak rup S
BPMN, ArchiMate,
MEMO, DEMO
Low <<< Technique specificity >>> High WSMM as presented initially has two important limitations. The first stems from the fact that most business professionals (ranging from individual contributors to managers and executives) who want to improve work systems need more than a modeling method. They need understandable, easily used, and easily explained ways to visualize and analyze the structure, operation, and performance of work systems that are to be improved. Typically starting with problems and opportunities, that analysis considers issues such as performance gaps, risks, customer issues, and other topics that many enterprise models do not address directly. The second limitation is the assumption (implied in Fig. 2) that the purposes addressed by WSMM line up sequentially along a dimension from highly informal to highly formal. The sequence of purposes in Fig. 2 helps in introducing the idea of WSMM, but there is no reason to believe that the purposes line up sequentially or that a particular level of technique specificity is associated with only one purpose. A broader view of WSMM assumes that most levels of specificity could be appropriate for many different purposes.
A WSMM analysis and design toolkit proposed in [
Modeling modules • Identification • Capabilities • Operation and scope of the
work system • Value capture • Responsibilities • Visibility • Activity/resource
dependencies • System interactions • Diagrammatic specifications
Analysis modules • Problems and
opportunities • Performance gaps • Strengths and weaknesses • Exceptions • Workarounds or
noncompliance • Key incidents • Risks • Issues for elements of the work system framework
Design modules • Proposed changes in
the work system • Rationale for
proposed changes • Likely improvements in work system performance
A theoretical perspective is an abstract set of concepts and related associations that
can be used in organizing, describing, understanding, and analyzing a body of subject
matter. The next section will apply the following framework to a work system
perspective on EM (abbreviated EM/WSP for current purposes) even though the
framework was developed for the broader purpose of describing theoretical
perspectives in general as a path toward understanding aspects of the IS discipline. The
framework’s 20 concepts evolved through comparisons between issues in IS and topics
abstracted from [
Rationale. The reason for choosing a specific perspective.
Domain. The set of entities to which the perspective applies.
Unit of analysis. The primary entity type that usually frames understandings or analysis when using the perspective.
Focal point. A perspective’s area of maximum relevance or usefulness Omissions. Possibly relevant topics that are beyond a perspective’s scope.
Fundamental constituents. Components, parts, or phenomena frequently viewed as essential to consider within a perspective.
Attributes. Frequently relevant properties, features, or characteristics for describing or analyzing entity types or their constituents. Attributes include goals and performance metrics.
Typologies. Classification schemes that organize entity types, categories, or subcategories
Alternative models. Alternative representations of relationships between different types of constituents and/or their components
Events. Changes or actions that occur at a specific time or over a time interval. Trajectories of change. Identifiable sequences of changes or actions
Forces. Influences of an entity or group of entities that induce or impede specific types of transitions in the state of other entities.
Interactions. Unidirectional, mutual, or reciprocal actions, effects, relationships, influences, or interplay between two or more entities.
Overlaps. Sharing all or parts of constituents or their components by two or more specific entities
Roles. Behaviors, rights, responsibilities, and/or other properties that apply to an entity’s functions and/or positions with respect to other entities
Dualities. Mutually contradictory characteristics or interpretations that may apply simultaneously to the same entities or phenomena, often for different purposes.
Causes. Factors that bring about specific effects or results.
Uncertainties. Knowledge gaps related to incompleteness or inaccuracy of available information about the past, current, or future states, events (state transitions), or causes of states or transitions related to entities or phenomena
Indeterminacies. Fundamental limitations on the possibility of knowing specific aspects of the past, current, or future states, transitions, or causes of states or transitions related to entities or phenomena
Generalizations. Abstract accounts or representations that apply to entity types or phenomena. Generalizations include axioms, principles, theories, frameworks, models, metamodels, and other abstract accounts.
This section applies the framework’s 20 concepts to EM/WSP. Experts on other perspectives or starting points (e.g., BPMN, ArchiMate, MEMO, SOM, capabilitydriven development, and so on) could use the same 20 concepts to reflect on those perspectives on EM in general or to reflect on modeling choices in any specific modeling effort. This section applies aspects of a much longer paper, not yet completed, that proposes the above framework and then applies it in trying to articulate the beginnings of a theoretical foundation for IS.
Rationale. EM/WSP is a plausible basis for EM efforts that focus on WSs, processes, ISs, highly focused business ecosystems, or enterprises.
• According to WST, a WS is a system in which human participants and/or machines perform work (processes and activities) using information, technology, and other resources to produce specific product/services for internal and/or external customers. • WSs can be sociotechnical (with human participants) or totally automated. • ISs are special case of WSs in which most activities are devoted to capturing, transmitting, storing, retrieving, manipulating, and/or displaying information. • ISs can be sociotechnical (e.g., accountants performing accounting) or totally automated (e.g., search engines). • Projects are WSs designed to cease to exist after producing specific results. • Supply chains and highly focused business ecosystems can be viewed as
WSs or groups of interacting WSs that cross enterprises. • Enterprises are configurations of interacting WSs that pursue overarching goals of the enterprise.
Domain. EM/WSP covers WSs of all types and sizes, including the various special cases such as IS, projects, and highly focused business ecosystems. Covering a domain larger than automated IS or other totally automated systems is necessary for meaningful understanding and analysis of IT-reliant systems such as package delivery systems that perform activities not involved with processing information.
Unit of analysis. EM/WSP’s unit of analysis is a specific WS, or in some cases, interacting or overlapping WSs (typically IT-reliant, and sometimes ISs).
Focal point. EM/WSP’s area of maximum relevance involves the operation and/or development of IT-reliant WSs. It is less useful at small scale for describing microactivities within process steps. It is also less useful at large scale for describing the operation of entire large enterprises that include numerous WSs whose even more numerous participants perform diverse activities, often guided by diverse goals.
Omissions. EM/WSP addresses many important topics only indirectly or not at all. For example, issues related to IS/IT organizations, culture, competition, and marketing are treated as secondary to WS operation and evolution over time. Similarly, individual differences between WS participants are recognized but not explored directly.
Fundamental constituents. In EM/WSP the nine elements of the WS framework (Fig. 1) outline a basic understanding of a WS’s form, function, and environment during a period when it retains its identity even though incremental changes may occur such as personnel substitutions or technology upgrades. Processes and activities, participants, information, and technologies are completely within the WS. Customers and product/services may be partially inside and partially outside because customers often participate in internal WS activities and because product/services take shape within a WS. Environment, infrastructure, and strategies are outside of the WS even though they have impacts within a WS. Each element of the WS framework has special cases that often are important. For example, participants may be agents of the enterprise or agents of other enterprises, as when customers participate in custom software development by providing information, negotiating capabilities, and verifying that the software satisfies customer requirements.
Attributes. In EM/WSP frequently important attributes are associated with WSs as a whole and each of the elements of the WS framework. For example, attributes of a WS as a whole include scalability, flexibility, resilience, and centralization; attributes of information include precision, age, timeliness, and bias.
Typologies. In EM/WSP the highest-level distinction between types of WSs is between sociotechnical WSs with human participants and totally automated WSs that operate autonomously. Special cases of WS such as ISs, projects, and supply chains may be sociotechnical or totally automated. Each of those special cases can have their own special cases, such as ISs based on machine learning or projects that produce customized software. Each special case inherits concepts and other knowledge from more general cases, e.g., WS –> project –> software development project –> open source software development project.
Alternative models. WS structure in EM/WSP can be modeled from different
viewpoints for different purposes and with different levels of detail. WS capabilities
can be discussed without modeling WS structure [
Events. In EM/WSP important types of changes and actions include: 1) activities performed consistent with the structure, capabilities and purposes of a WS (or several WSs), as summarized by the WS framework, 2) activities performed based on adaptations or workarounds that may conflict with the structure, capabilities and purposes of a WS, and 3) unplanned or accidental activities or events that degrade, disable, or destroy WS capabilities. Events of each type may be beneficial or harmful.
Trajectories of change. In EM/WSP the WS life cycle model from WST summarizes a trajectory of planned change encompassing initiation, development (creation, acquisition, or improvement of resources, possibly including software) , and implementation phases leading to operation of a new or improved WS. Variations on the WS life cycle model apply to situations involving agile software development and/or DevOps. The WS life cycle model uses inward facing arrows to represent the possibility of unplanned changes such as workarounds and adaptations. A theory of workarounds summarizes a change trajectory through which workarounds are imagined and implemented to overcome obstacles to achieving organizational or personal goals.
Fundamental forces. Four important forces in physics are electromagnetic force, the strong force that holds atoms together, the weak force involved with radioactive decay, and gravity. In EM/WSP five types of forces apply to WSs as a whole. • Cohesive forces tend to hold WSs together, e.g., incentives, goals, controls, alignment. • Disruptive forces tend to make them less organized and may degrade them, e.g., internal misalignments, discontent, poor management, design flaws. • Innovative forces encourage changes in WS operation based on benefits for stakeholders and customers • Inertial forces resist planned or unplanned changes in WS operation. • Forces from a distance (analogous to gravity) include economics, competition, regulation, demographics, and technological change.
Other forces that operate as drivers or obstacles to WS change are directly related to specific elements of the WS framework, e.g, change driven by participant ambition and knowledge or inhibited by lack of ambition or knowledge.
Interactions. EM/WSP recognizes that WS interactions are essential for the operation of any enterprise, organization, business ecosystem, or IT-reliant system. Interactions also bring significant risks. Four sets of ideas that are presented elsewhere describe aspects of interactions involving WSs: 1) the service value chain framework, 2) WS treatment of co-production and value co-creation, 3) system interaction patterns, and 4) system interaction theory.
Overlaps. WSs often overlap with other WSs that play roles in their operation, as when ISs support or serve as integral components of other IT-reliant WSs that may or may not be ISs. Forms of overlap between WSs include separation or minimal overlap, significant overlap, and enclosure of one WS by another WS.
Roles. ISs and other WSs may play a variety of roles in WSs that they support. Typical examples include providing access to information, defining and enforcing rules for collecting or sharing information, providing methods for aggregating information, providing methods for analyzing information, controlling activity sequences in workflows, enforcing compliance with business rules, creating alarms when predefined conditions occur, controlling or facilitating coordination, suggesting decisions, triggering automated functions, and performing totally automated tasks autonomously.
Dualities. Milestones in the history of physics were discoveries that both photons and electrons have features of waves and of particles. In EM/WSP, dualities apply to WS in general and to elements of the WS framework. Important examples include: • Customers as recipients of product/services vs. beneficiaries of product/services. (Assuming that customers receive product/services is an unnecessary constraint on the treatment of customer roles.) • Processes as idealizations of how work should be done vs. descriptions of how work is executed in reality. (Treating processes as idealizations leads to ignoring important deviations that occur in many real-world situations.) • Participants as people with human needs and interests vs. participants as WS components. (Treating participants as WS components may lead to unrealistically mechanistic models. Including their needs and interests may go into territory that EM prefers to ignore.) Participants as people performing actor roles in WSs vs. as users of technology. (Treating participants only as users of technology ignores important participants who may not use the technologies of interest.) Information as digital objects vs. as meanings that inform people. (Modeling informational entities as objects ignores their meaningfulness to people, which matters greatly in some situations but not at all in others where the information takes the form of messages transmitted between automated modules.) Technologies as tools used by users vs. as automated services that operate autonomously. (Automated services can be viewed as WSs on their own right.) Causes. In EM/WSP, causes are almost always partial causes intertwined with other partial causes. For example, an operational failure of a WS may be due to its error prone nature, which may be partially due to design limitations in the WS and partially due to a management decision to replace more expensive WS participants with semi-skilled WS participants who cannot adjust to unplanned interactions with other WSs.
Uncertainties. In EM/WSP, differing degrees of uncertainty may apply to how specific processes or activities will be executed and to the exact form and quality of specific product/services that will be produced. Established process flows are not followed in many situations, especially when business processes are more like activity guidelines than activity rules. The topic of compliance versus noncompliance is a broader version of issues related to uncertainty about how work will be executed and how that might affect both internal performance and product/services for customers. A 2x2 set of related possibilities include beneficial compliance, detrimental compliance, beneficial noncompliance, and detrimental noncompliance.
Indeterminacies. In EM/WSP, there is always some level of detail where it is impossible to explain how and why events occur or have occurred in the past, especially when information about participant intentions and other important factors are not observed or recorded.
Generalizations. Six types of generalization that apply to WSs and WS components include axioms, design principles, theories, frameworks, models, and metamodels. Axioms apply to every entity of a specific type within a domain. Design principles express desired or beneficial characteristics of designed entities such as WSs within a domain and planned WS interactions. Design principles often have exceptions, may be mutually inconsistent, and may exhibit mutual conflicts in practice. Theories, frameworks, models, and metamodels associated directly with WSP include WST, a theory of workarounds, system interaction theory, the WS framework, a service value chain framework, the WS lifecycle model, and metamodels that reinterpret concepts in the WS framework. 5
This paper covered a great deal of territory. It summarized the WS perspective, used its extension into WSMM to demonstrate its relevance to EM, introduced a 20-part framework for describing theoretical perspectives, and finally applied that framework to the WS perspective on EM, which it abbreviated EM/WSP. Application of the framework to EM/WSP illustrated many design issues that are relevant to specific modeling situations and to EM in general. EM/WSP was used as an illustrative example to provide a more concrete view of those design choices than would have been possible if they had been discussed only as abstractions.
The design choices that were mentioned first, such as rationale, domain, unit of analysis, omissions, fundamental constituents, and attributes are obvious issues for almost any modeling effort. Of those, omissions is probably the most challenging due to the temptation to ignore or downplay areas that would be difficult to explain for conceptual, practical, or even political reasons. For example, assumptions about the talents, skills, and ambitions of WS participants might have direct effects on process or enterprise performance but might be difficult to explain or discuss publicly if related deficiencies seem consequential or controversial. The question of which constituents and attributes to include is also challenging due to trade-offs between precision and manageability.
Design choices concerning alternative models are at the heart of WSMM, which was first imagined as an approach to modeling situations where different stakeholders have different purposes and different levels of modeling skills. Different purposes call for inclusion or exclusion of topics that may include events, trajectories, roles, overlaps, interactions, and so on. Overloading a model with too much detail in areas such as those makes it unnecessarily difficult to understand and maintain. On the other hand, omitting those factors can make a model unrealistic. For example, even if inconvenient or complex, inclusion of intentional or accidental interactions with customers, suppliers, governments, or other parts of the surrounding environment may be important for representing the relevant reality.
WSMM applies invariant use of an overarching modeling metaphor, the work system, as a way of maintaining coherence even in the presence of alternative models for different purposes. With that approach, part of the coherence is maintained through linking metamodels to the extent possible and part is maintained through social collaboration around assuring that business stakeholders are able to contribute fully to discussions that help technical experts produce precise models for operations manuals, simulation models, and even model-driven development. Design choices related to inclusion or exclusion of dualities, forces, causes, and uncertainties add further complexity. In a duality example, if technologies can be seen either as tools or as automated services that operate autonomously, then some form of recursion may be necessary in WS modeling techniques. Whether and how appropriate recursion could be included in ADOxx or similar platforms seems like a challenging issue, possibly at a level similar to application of generalized domain specific models (e.g., concerning decision-making, communication, coordination) within models of specific situations.
Areas for future research. Ideas summarized in this paper could be applied, tested, and/or extended in many areas. A first step is to produce a deeper and more extensive version of this paper’s section on EM/WSP. Either the existing section or an extended version could be used as an illustrative example for a similar exercise starting from other approaches such as DEMO, MEMO, or SOM in the EM world or various theoretical approaches in the organizational realm, such as activity theory, viable systems model, soft systems methodology, and so on. An ambitious project might track at least several real world EM projects to examine whether and how the ideas in the framework are considered during the initial deliberations about project scope and subsequent discussions of model details. Also, it could be valuable to evaluate the content of EM/WSP from the viewpoint of method engineering to see whether either approach points to significant limitations or suggests extensions of the other. Any of those approaches and ideally any combination of those approaches likely would reveal interesting directions for sharpening both general and situation-specific discussions and decisions about what EM should include or exclude when those approaches are used.