=Paper=
{{Paper
|id=Vol-2499/paper5
|storemode=property
|title=Using a Framework for Describing Theoretical Perspectives to Identify High-Level Design Choices about the Scope and Content of Enterprise Models
|pdfUrl=https://ceur-ws.org/Vol-2499/paper5.pdf
|volume=Vol-2499
|authors=Steven Alter
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/Alter19
}}
==Using a Framework for Describing Theoretical Perspectives to Identify High-Level Design Choices about the Scope and Content of Enterprise Models==
https://ceur-ws.org/Vol-2499/paper5.pdf
Using a Framework for Describing Theoretical
Perspectives to Identify High-Level Design Choices about
the Scope and Content of Enterprise Models
Steven Alter[1]
1 University of San Francisco, San Francisco CA 94117, USA
alter@usfca.edu
Abstract. 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.
Keywords: Modeling Method, Work System Method, Work System Theory
1 A Work System Perspective on Enterprise Modeling
Initial steps toward a new stream of EM research [1] pursued the possibility that ideas
and approaches from an older stream of research about work systems might be relevant
and beneficial in EM. That new research represents both an extension of long-term
research on work systems [2, 3] and a possible direction for addressing important EM
challenges noted by leaders of the EM community [4]. The initial results imply that a
work system perspective on EM is a plausible, is theoretically solid, and forms a
potential basis of a toolkit that could be available through ADOxx. This paper builds
on those ideas, but pursues a purpose that touches EM in a more general way.
What to include or exclude? Scope and content are key design choices in producing
any model. This paper presents a framework that could help enterprise modelers
identify issues related to the scope and content of enterprise models. It applies that
framework to a work system perspective on EM to illuminate many related questions.
Goal and organization. This paper includes three major sections. First is highly
summarized background about the work system perspective in general and initial EM-
related research based on that perspective. Next is an overview of a framework
consisting of 20 ideas related to the scope and content of theoretical perspectives. That
framework was developed in a totally separate, highly iterative effort to articulate a
theoretical foundation for the IS discipline. The subsequent section applies the
framework to the work system perspective on EM (abbreviated as EM/WSP) as a way
Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons
License Attribution 4.0 International (CC BY 4.0).
50
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 Background
2.1 Work system basics
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.[2, 3] The and/or in the
definition implies that work systems can be sociotechnical (with human participants)
or totally automated. A work system operates within an environment that matters (e.g.,
national and organizational culture, policies, history, competitive situation,
demographics, technological change, other stakeholders, and so on). Work systems rely
on human, informational, and technical infrastructure that is shared with other work
systems. Work systems should support enterprise and departmental strategies.
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 [2,
3]. To date, almost all use of WSM has applied WS analysis outlines that proceed from
aspects of WS structure and performance toward a preliminary recommendation of
improvements. The outlines include some questions that require textual answers, others
that require filling out formatted tables, and others that invite users to include swimlane
diagrams, Pareto charts, or other diagrams if they have appropriate software.
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 [3], the theoretical basis of WSM, consists of three
parts: 1) the definition of work system (above), 2) the work system framework (Fig. 1),
and 3) the work system life cycle model (mentioned later but not shown in a figure).
51
Fig. 1. Work system framework [2, 3]
2.1 Challenges in Enterprise Modeling
Initial attempts to bring a work system perspective to EM started with a discussion
about a diagram in [5] saying that a modeling method can have only one modeling
technique that combines a single modeling language and a modeling procedure. Use of
WSM analysis outlines by MBA and executive MBA students during 2003-2017 (e.g.
[6]) suggested that restrictive assumptions about the nature of modeling might seem
more of an obstacle than an aid to business professionals trying to understand IT-
enabled work systems.
That discussion led to considering difficulties in the practical application of EM. A
BISE research note [4] argued that the impact of EM to date had been disappointing
and that it needed to be more democratic, more like “modeling for the masses.” Many
other sources cited in [1] noted issues related to modeling techniques becoming
straitjackets, being vague about vagueness, assuming that nonexperts in modeling
would be able to use or at least understand unfamiliar notations, and so on.
2.2 Work System Modeling Method and Related Toolkit
Those issues led to the development of the work system modeling method (WSMM),
which extends WSM into the realm of EM [1]. WSMM pursued four requirements for
making modeling methods more flexible: 1) The modeling method should respect
stakeholder diversity related to knowledge, beliefs, and roles. 2) It might include
different modeling techniques for different stakeholder purposes related to the same
situation, 3) It might use different modeling languages based on different metamodels.
In relation to domain-specific conceptual modeling [7], this approach assumes that
intersubjective understanding between stakeholders might not require a single
metamodel for processes, services, enterprises, goals, and so on. 4) The representation
of a model might or might not use diagrams with rigorously defined notation and syntax
(e. g., BPMN, ArchiMate) or might use diagrams for some purposes but not for others.
[8] and [9] shed light on ideas related to how these requirements might be pursued using
ADOxx by means of its modeltype functionality, which is a like a select operator or
hyperlink that can be applied to a repository of modeling language concepts by an
ADOxx developer.
52
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 [1], WSMM is a flexible modeling
method that accommodates different purposes and different levels of specificity while
maintaining coherence through invariant use of a core modeling metaphor [10] (such
as the work system perspective). The scope of WSMM was described in terms of a
design space for modeling methods and modeling techniques related to a core modeling
metaphor. The design space (Fig. 2) accommodates a range of stakeholder purposes,
shown as P1 through P7. Technique specificity is the extent to which a technique
defines exactly what to include, what to ignore, and how to proceed. Techniques with
low specificity tend to be flexible but provide little conceptual or procedural guidance.
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. [1] used a
simplified example to illustrate application of WSMM across P1 through P6. WSMM’s
main point about code generation (P7) was that programmers would have to collaborate
with stakeholders around at least P1 through P4 in order to reduce the likelihood that
software would be built based on incomplete or incorrect assumptions. Thus, WSMM
applies the very broad view of modeling expressed in Fig. 2 and assumes that the
general sequence of WSM steps mentioned above can be pursued to varying degrees
depending on the purpose at hand and the interests and knowledge of stakeholders.
P1: System identification Most modeling
P2: System capabilities
Stakeholder
techniques used with
purposes
P3: System scope and operation
P4: Activity/resource dependencies WSM
P5: High precision description BPMN, ArchiMate,
P6: System simulation MEMO, DEMO
P7: Code generation
Low <<< Technique specificity >>> High
Fig. 2. Design Space for Modeling Methods and Modeling Techniques [1]
2.3 Possibility of a WSMM Toolkit
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
53
(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 [11] addresses both issues. The
toolkit consists of modules, each of which is directed at a different stakeholder purpose
related to understanding or analyzing an aspect of a work system such as value capture,
shared responsibility, and visibility for providers and customers. Informal versions of
some of those analysis modules appeared in most of the previously mentioned outlines
used by MBA and Executive MBA students. Some are based on subsequent extensions
of WST. The overall vision is that these modules will be implemented as an interactive
toolkit on a platform such as ADOxx that will make it easy for users to identify, select,
and use individual modules or pre-packaged groups of modules that are especially
relevant to the types of situations that they want to analyze. Table 1 identifies
representative modules for modeling, analysis, and design.
Modeling modules Analysis modules Design modules
• Identification • Problems and • Proposed changes in
• Capabilities opportunities the work system
• Operation and scope of the • Performance gaps • Rationale for
work system • Strengths and weaknesses proposed changes
• Value capture • Exceptions • Likely
• Responsibilities • Workarounds or improvements in
• Visibility noncompliance work system
• Activity/resource • Key incidents performance
dependencies • Risks
• System interactions • Issues for elements of the
• Diagrammatic specifications work system framework
Table 1. Examples of modeling, analysis, and design modules [11]
3 Framework for Describing Theoretical Perspectives
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 [12], a physicist’s account of the quest for a “theory of everything” in
physics, i.e., a theory that explains the structure and behavior of matter from the
subatomic to the cosmic level. The framework evolved through numerous iterations of
identifying and clarifying issues that can be separated from specifics of physics and
54
adapted for thinking about IS. For example, both call for identifying and describing the
domain, omissions, constituents, forces, uncertainties and interactions. Some of the
following concepts such as rationale, domain, unit of analysis, and omissions are
obvious to anyone who produces models. Many of the others are not obvious and raise
many questions about why an enterprise model could or should ignore a topic that might
be quite important in the reality the model describes.
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.
55
4 A Work System Perspective on EM Based on the Framework
for Describing Theoretical Perspectives
This section applies the framework’s 20 concepts to EM/WSP. Experts on other
perspectives or starting points (e.g., BPMN, ArchiMate, MEMO, SOM, capability-
driven 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 micro-
activities 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
56
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 [1]. The WS framework points to
summarizing WS operation in the more integrated form of a WS snapshot, a formatted
one-page summary of its six central elements. A more detailed view of a WS identifies
specific resources that are used or produced by each activity. Even more detailed views
of a WS apply established techniques such as BPMN or ERD for documenting
processes and information in databases.
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
57
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
58
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 Discussion and Conclusions
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
59
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
60
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.
References
1. Alter, S., Bork, D.: Work System Modeling Method with Different Levels of Specificity and
Rigor for Different Stakeholder Purpose, 14th International Conference on
Wirtschaftsinformatik, Siegen, Germany. 124-138 (2019).
2. Alter, S.: The work system method: connecting people, processes, and IT for business
results. Work System Press, Lankspur, CA, USA (2006).
3. Alter, S.: Work System Theory: Overview of Core Concepts, Extensions, and Challenges
for the Future. J. Assoc. Inf. Syst. 14, 72–121 (2013).
4. Sandkuhl, K., Fill, H.-G., Hoppenbrouwers, S., Krogstie, J., Matthes, F., Opdahl, A.,
Schwabe, G., Uludag, Ö., Winter, R.: From Expert Discipline to Common Practice: A Vision
and Research Agenda for Extending the Reach of Enterprise Modeling. Bus. Inf. Syst. Eng.
60, 69–80 (2018).
5. Karagiannis, D., Kühn, H.: Metamodelling Platforms. In: Third International Conference
EC-Web 2002. p. 182 (2002).
6. Truex, D., Alter, S., Long, C.: Systems analysis for everyone else: Empowering business
professionals through a systems analysis method that fits their needs. In: ECIS 2010
Proceedings. 4 (2010).
7. Karagiannis, D., Mayr, H.C., Mylopoulos, J.: Domain- Specific Conceptual
ModelingSpringer Berlin Heidelberg (2016)
8. Fill, H.G., Karagiannis, D.:. On the conceptualisation of modelling methods using the
ADOxx meta modelling platform. Enterprise Modelling and Information Systems
Architectures (EMISAJ). 8(1):4-25 (2013)
9. Fill, H.G., Redmond, T., Karagiannis, D.: Formalizing meta models with FDMM: the
ADOxx case. In International Conference on Enterprise Information Systems (pp. 429-451).
Springer, Berlin, Heidelberg (2013)
10. Ferstl, O.K., Sinz, E.J.: Grundlagen der Wirtschaftsinformatik. Oldenbourg, München
(2013)
11. Alter, S., Bork,D.: Systems Analysis and Design Toolkit Based on Work System Theory
and Its Extensions, paper currently under review.
12. Lincoln, D.: The Theory of Everything: The quest to explain all reality. Course guidebook.
The Teaching Company: Chantilly, Virginia, USA (2017)