Keywords

1 Introduction

The availability of information that is relevant and usable is important for organisations and people that collaborate. The design, production, and consumption of information become critical for them when they must consider not only their own activities but also other's points of view and practices.

Enterprise architecture (EA) focuses on working with architectural knowledge and descriptions to manage (information) complexity and address business and IT needs.

A central EA practice is analysing and documenting enterprises according to the world views and the perspectives of different stakeholders’ concerns in a holistic way that promises to facilitate the solution of problems and understanding of changes. This is supported by stakeholder analysis and management practices.

Stakeholder analysis typically involves identifying relationships, which refers to how two or more stakeholders are connected, interact or involve each other.

The capture of knowledge of relationships provides insights into what different stakeholders do with information in relation to each other. Since stakeholders in their practices have their own volition or purpose, points of view, interests, needs, goals, and access to people and data, they can also disagree, leading to potential conflicts. Examining the relationships enables deliberations about alignment, fit, asymmetry, agreement, and knowledge transfer between stakeholders’ practices over time which can explain reported problems with stakeholder engagements [27].

However, the application of stakeholder analysis in EA lacks due consideration of relationships, such as in practised EA frameworks such as TOGAF architecture development method [47], NAF [30], and in the standardisation of existing enterprise architecture practices by ISO 42010 [25], 42020 [23], 42030 [24], and OMG UAF [22].

Thus, the lack of support for relationships limits the analysis, understanding, and design of situations where stakeholders collaborate using models and diagrams.

This paper presents a problematisation of the lack of support for relationships in EA stakeholder analysis based on problems from an empirical case study and literature studies. The challenges have led to the design of the Work-Oriented Approach to Information Products (WOA) and Situation Viewpoint that can represent relationships.

The Situation Viewpoint offers to enrich and complement the EA stakeholder analysis by enabling the capture of knowledge about relationships between stakeholders’ practices where they use information products (IP) such as EA models and diagrams.

The Situation Viewpoint build upon knowledge from the fields of stakeholder analysis [29], practices [4, 31], jobs to be done [48], situational analysis [8], situational method engineering [16], and ISO 42010 [25].

The Situation Viewpoint is demonstrated by the idealisation of two projects, IT portfolio management in a larger university and a research project that created an innovative kind of algorithm for handling sea transports.

The structure of the paper is as follows. Related work and the design science research approach taken are described in Sects. 2 and 3. The problematisation of relationships in EA stakeholder analysis is described in Sect. 4, while the WOA and the Situation Viewpoint are presented in Sect. 5 and demonstrated in Sect. 6. Sections 7 and 8 conclude with a discussion and summary.

2 Related Research

Stakeholder Management. The analysis and management of stakeholders have widely understood concepts and commonly used practices and are well-researched. While there are differences in opinion about the exact definition of a stakeholder, a stakeholder is typically someone that has a stake in the game, someone that affects or is affected by a decision or action [21].

Stakeholder analysis is applied within the field of enterprise architecture, TOGAF architecture development method [47], NAF 4 [30], standardisation of existing EA practices by ISO 42010 [25], 42020 [23], 42030 [24], and OMG UAF [22], systems engineering [17], business modelling [42], and project management [29].

Stakeholder analysis typically includes elements of identification of context and focus (e.g. issue, organisation or intervention) and system boundaries, identification of stakeholders and their stake, categorisation of stakeholders, investigation of relationships between stakeholders and their practices from which interests are derived, and recommendations for future activities and stakeholder engagement [13, 36].

This suggests that EA would benefit from the consideration of relationships between stakeholders that participate in EA activities or are beneficiaries of EA services.

Enterprise Architecture (EA).

Today, there are hundreds of EA approaches, frameworks, methods and products such as TOGAF 10 [47], NATO Architecture Framework 4 (NAF) [30], Zachman enterprise ontology for EA [40, 52], and the Unified Architecture Framework (UAF), ISO/IEC 19540:2022 [22], that aims to unify EA Frameworks.

The EA has acquired a tradition and international standards that codifies existing practices; ISO 42010 for architecture descriptions [25], ISO 42020 for architecting processes [23], ISO 42030 for evaluations of architectures [24] and GERAM [18].

ISO 42010 concerns the description of architectures, which are defined as the “fundamental concepts or properties of an entity in its environment and governing principles for the realisation and evolution of this entity and its related life cycle processes.” [25].

The ISO 42010 includes definitions of the following concepts:

  • concern: a matter of relevance or importance to a stakeholder.

  • stakeholder: role, position, individual, organisation, or classes thereof, having an interest, right, share, or claim, in an entity of interest.

  • stakeholder perspective: a way of thinking about an entity of interest (3.12), especially as it relates to concerns.

  • viewpoint: a set of conventions for the creation, interpretation and use of an architecture view to frame one or more concerns.

  • information part: a separately identifiable body of information that is produced, stored, and delivered for human and machine use. Note: can be a model or diagram.

In WOA, an Information product is an information part participating in a practice.

Practices.

The idea of practice represents the customary, habitual, or expected procedure or way of doing something, including designing and using information. While not supported by a unified practice theory, the study of practices provides insight into human activities and behaviour. Practice theories are part of the field of social sciences [2, 31, 32, 43] and the Schatzki’s practice theory [6, 39].

Adler et al. [2] describes a practice as a process and repetition of actions that can be performed correctly or incorrectly and rest on accumulated knowledge.

According to Feldman and Orlikowski [12], there is an essential distinction between the value of technological artefacts and the technology-in-use. It is the ways that technological artefacts are used by agents in their practice that make them resources and meaningful for organisations.

Adjacent to practice theory, there is the jobs-to-be-done theory, as described by Christensen et al. [7] and Ulwick [48], focus on what an individual seeks to accomplish.

In this paper, the concept of practice is used to highlight the perspective that a stakeholder is using information products in their work. Thus, aspects of information products, their use, and stakeholders need to be examined in the context of a practice.

Relationships.

Relationships between people, practices, technologies and other entities are considered a key part of social, economic and technical settings and are found in diverse fields, such as stakeholder management [36], actor-network theories [5], situational analysis [8], ontology such as the Unified Foundational Ontology (UFO) [15] that incorporates the ‘relator’ construct, and institutional logic that considers governance structures, which embody rules for societal behaviour and practices [9].

In other fields, the focus for describing relationships is on exchanges of entities or value between roles, such as consumers (requester) and producers (offerer). Examples include e3Value [51] with the exchange of value between actors, value propositions [34] with gains and gains creators, service-dominant logic (SDL) with the application of skills and knowledge for the benefit of another party [49] and resource-event-agent framework (REA) [14] with the duality of the transfer of resources between agents.

Distinctions between roles can be found in ISO standards ISO 9000 [21] and ISO 15288 [20] that identify roles such as customer, provider, buyer, seller, acquirer, and operator, as well as the duality between roles in ISO 15944 [19].

The aforementioned fields provide convincing arguments that the concepts of relationship and role add aspects that are important to consider for collaborative and servicing practices and their stakeholders. They are therefore incorporated into WOA.

Boundary Object.

The concept of boundary object was introduced by Star & Griesemer [41] and examined in the paper “Crossing the line - overcoming knowledge boundaries in enterprise transformation” [1] with respect to models, which can be argued to be devices for alignment between stakeholders.

3 Research Approach

This paper presents a demonstration of results related to the concepts of relationships and roles from the second stage of a design science research (DSR) effort based on Peffers process [35], where the first stage resulted in a dissertation [45] from which the second stage continues.

DSR is carried out to change the state of affairs by designing and evaluating innovative artefacts. The steps in Peffers are 1. Problem identification and motivation, 2. Objectives of a solution, 3. Design and development, 4. Demonstration, and 5. Evaluation.

The research addresses problems relating to differences in perception and use across practices that may hamper the utility of information products over time. The design artefact (WOA) aims to answer the question, How can an information product be represented, designed, used, evolved, and evaluated so that it can participate in different practices and, at the same time, support coherence between collaborative practices within the context of the application of EA methods and frameworks.

4 Problematisation of Relationships in EA Stakeholder Analysis

While EA has matured over the years, where practices and standards have emerged, there remain challenges relating to stakeholders’ use and satisfaction with information products. In this section, we identify challenges relating to using information products (IP) in collaborative practice. The challenges are based on previous research and a case study, literature studies of related fields, and a study of EA evaluations.

4.1 Previous Research

In an empirical case study of the use and utility of an information product - the concept of capability - several problems were identified in relation to work practices [46].

1) Different variations of information products that incorporate the concept of capability were used, and the application and utility varied between work practices. 2) The information products were expected to be used by many people. However, some people use it by referring or linking to others’ use, do not use it themselves, or see little utility in using it. 3) The use of an EA framework with a single definition of an information product to integrate different kinds of work products within a project may not lead to a consistent and beneficial use of the information product. 4) The information product was overlaid with non-essential meanings and aspects, and experts added their own relevant meanings.

A review of the case study revealed two additional problems.

5) The interviewees were vague about their experienced or potential use and perceived or expected utility of the information product. The answers became significantly fewer and vaguer when asked about which specific problems and decisions the information product helped with. 6) The interviewees sometimes referred to their own benefits in terms of what others have told them.

a) Thus, there are challenges when an information product does not suit different stakeholder-specific practices in situations where the stakeholders collaborate.

4.2 Challenges from Literature Studies of Related Fields

Relationships Challenges. While relationships between stakeholders and the practices in which they use IP are considered vital in many fields, they are not explicitly supported in stakeholder analysis and management in standards such as ISO 42010 [25], GERAM [18] and EA frameworks such as TOGAF [47], NAF [30], and UAF [22].

Although there exist plentiful techniques to capture knowledge about system users’ basic actions and flows, such as use cases, process and goal models, and collaboration diagrams in EA descriptions, they are not used in EA stakeholder analysis.

Knowledge about relationships adds social and co-use aspects in addition to inherent and in-use qualities of IP, in addition to agreements on the knowledge in an IP and how the IP should be interpreted as suggested in SEQUAL [26].

Furthermore, an agreement is one step on the way toward mutually beneficial exchanges over time. Before agreement comes knowledge and training, and after comes intention to use, use, experiences, adoption and advocacy. Misalignment can negatively influence organisational efficiency in an organisation applying work specialisation.

b) Thus, the lack of relational knowledge limits the understanding of and fit, over time, between collaborating stakeholders with diverse and specialised perspectives, interests, work, responsibilities, access to people and data, practices, information needs, use of information products, goals and definitions of success.

A vital relationship to address in EA is found between a stakeholder and an architect. This relationship's imbalances can lead to an architecture-centric situation where architects look at, analyse and evaluate stakeholders instead of a stakeholder-centric situation where architecting is one of many practices in a network of stakeholders all contributing to and servicing an organisation's different parts.

c) Thus, not treating architects’ practices in the same way as stakeholders’ practices can lead to unbalanced stakeholder analysis in a larger organisational setting where the aggregated utility of architects’ and stakeholders’ diverse use of information products is not sufficiently considered.

In fields such as innovation, product development, marketing, sales, and start-up, asymmetrical challenges, such as when a business stakeholder once says an architecture model is great but later is not interested in using it any more, are well-known. Transferring knowledge from these fields can explain reported stakeholder problems [27].

d) Thus, the lack of relational knowledge limits the inclusion of knowledge from adjacent fields and analysis of ‘cause lead-to effect’ in collaborations using IP.

Stakeholder Management Challenges.

Stakeholder management in EA is not without problems. In a recent literature and case study from 2021 about “Stakeholder engagement in enterprise architecture practice”, 28 inhibitors for engagement were identified [27]. Even though it is unclear if any non-EA stakeholders were interviewed and their reason for being interested in EA was documented, the study points to a remaining mismatch and misalignment between stakeholders and EA practices.

e) Thus, there is a challenge that stakeholders do not engage in EA practices as indented by the applicable EA and stakeholder management approaches.

Practice Challenges.

The stakeholder analysis in EA typically does not include identifying and analysing the collaborative stakeholders’ practices at a desired level of detail, such as if a model fits with the need for a specific question to be answered.

While ISO 42010 discuss, in theory, the granularity of concerns and that concerns and stakeholder perspectives depend on stakeholders’ knowledge, experiences, training, responsibility, authority, needs, goals, and requirements, there are no practical provisions for capturing stakeholder practices in detail. An example is the UAF [22], where concerns are documented with a few words.

f) Thus, the lack of detailed practice knowledge limits detailed analysis, design, evolution, and evaluation of IP in collaborative stakeholder practices.

Evaluation Challenges.

The value of an IP can differ depending on who used it. An example is the difference in usability between an EA model that an architect produced and exchanged with a business manager that does not understand the model. A lack of knowledge about relationships limits the evaluation of in-use, co-use, exchange, and network factors that influence the aggregated utility of information products.

g) Thus, the lack of relational knowledge limits the evaluation of information products exchanged and used in different but related stakeholder practices.

Enterprise Modelling Challenges.

Even though enterprise modelling is established and included in EA, there are challenges. In the paper “Enterprise Modelling for the Masses – From Elitist Discipline to Common Practice” [38], the authors bring to the surface a challenge - “people refuse to spend time creating and maintaining enterprise models, find modelling and modelling methods complex and cumbersome, or do not immediately see its use for their particular perspective or set of concerns.”

h) Thus, even though an IP is intended to be used by many stakeholders, stakeholders may experience challenges relating to an IP and the way it is used depending on the stakeholders’ knowledge, skills, attitudes, and jobs to be done.

Boundary Object Challenges.

It is easy to imagine that externalised knowledge in EA models can be considered boundary objects when several stakeholders use them. However, do all stakeholders agree that a model is a boundary object?

i) Thus, there is a problem in that information products are thought of as boundary objects when they may not be designed as such and agreed upon by all stakeholders.

Mediation Challenges.

Knowledge about a practice and the use of an information product can come from different sources, such as stakeholders describing their own beliefs about themselves, stakeholders describing themself and others, or a mediator analysing and describing multiple stakeholders. When knowledge is mediated by someone other than those who participate in the practice, such as by a business analyst, modeller or architect, biases and undesirable effects can occur if voices from all stakeholders are not heard or if a mediator cannot capture all relevant knowledge.

The consultancy company McKinsey describes in the article “Business’s ‘It’s not my problem’ IT problem” what can happen with Business-IT alignment when knowledge is mediated without accountability [28].

j) Thus, the agent that is the source of knowledge about relationships, practices, stakeholders and information products influences the representation, analysis, design, use, evolution, and evaluation of information products in practices.

4.3 Challenges from Enterprise Architecture Evaluation Studies

In an ongoing systematic literature study looking at evaluations of the application of EA and what is evaluated with respect to relationships between stakeholders and their practices, an issue relating to the validity of the results has been found.

Several studies can be argued to be unbalanced since they consider only a few stakeholder groups. An example is found in the paper “An Empirical Investigation of Geographically Distributed Agile Development: The Agile Enterprise Architecture Is a Communication Enabler” [3], where 160 respondents were asked to grade the question “GDAD project meets customer’s functional requirements”. Unfortunately, only 2 respondents were identified as business stakeholders, leading to questions about the validity with respect to stakeholders. Were they represented, or were architects answering questions about other stakeholders’ work?

j) Thus, the validity of evaluations of stakeholders’ use of information products can be reduced when a stakeholder answers questions about other stakeholders.

5 Work-Oriented Approach (WOA)

This section describes the Work-oriented Approach solution artefacts, focusing on the Situation viewpoint that directly concerns relationships. The WOA consists of WOA Method chunks [44] and WOA Constructs that aim to address the aforementioned challenges by aiding a designer to construct information products to fit into collaborative practices. This is done by examining the relationships among stakeholders’ practices and use of information products. The concepts are described (Sect. 5.1) and used to form a Situation viewpoint that can be utilised to extend EA frameworks (Sect. 5.2).

5.1 Conceptual Model

The WOA is based on a conceptual model that is constructed using OMG Semantics of Business Vocabulary and Business Rules (SBVR) [33], which specifies a rich set of elements that can be used to define meanings, representations, and expressions as well as terminological dictionaries, vocabularies, and rulebooks based on a logical foundation. For the purpose of this paper, key concepts related to relationships are described in this section and illustrated in Fig. 1, but not formally specified.

An Information product refers to an information part [25] that participates in a practice as a work product.

An Agent refers to an entity or group of entities that can bring about a change in the world, such as stakeholders (a person or organisation that can affect, be affected by, or perceive itself to be affected by a decision or activity [21]) or information systems. Agents can have their own volition or purpose, points of view, responsibilities, interests, needs, goals, and access to people and data, which means they can also disagree, leading to potential conflicts between collaborating agents.

A Practice refers to the customary, habitual, or expected procedure or way of doing something [4, 8, 31, 46]. In an organisation, practices often emerge because of work specialisation.

Agents, such as stakeholders, and Entities, such as information products, participate in a practice in (thematic) roles. The concept of Participation provides the basis for representing and evaluating in-use and co-use (use in more than one practice) aspects.

A practice can be described in many ways, as demonstrated in Sect. 6. Further examples of how to describe practices in detail are Jobs to be done [48], an actor experiencing a problem or pain [34], or an actor having information needs [17].

A practice can be described at the desired level of detail by the addition of statements that each refer to a unit of knowledge relating to the practice, as illustrated in Fig. 2.

A practice can include descriptions of more than activities, such as responsibilities, features, questions that can be answered, access to data, needs, and pains that may be deemed relevant for a stakeholder’s “what is in it for me” and use of an IP.

A practice can include descriptions of alternatives [24] and relative advantages [50], which can be relevant for analysing the acceptance of using an IP.

Fig. 1.
figure 1

Illustration of key WOA concepts

Full size image

A Practice Relationship refers to the way in which two or more practices with their participating agents (e.g. stakeholders) and other entities (e.g. information products) are connected, interact or involve each other. A relationship is an objectified relation and depends on the practices that play roles in the relationship.

A Practice Role refers to how practice plays a part, assuming a function or being used in a relationship. The practice role establishes a reference point from which a stakeholder in a practice interpret themselves and entities participating in other practices within the context of the relationship.

The WOA includes the definition of three archetypical roles based on the type-instance pattern from the information systems field. In the ‘Creator’ practice, new types of IP are created, in the ‘Producer’ practice, IP instances of the type of IP are produced, and in the ‘Consumer’ practice, the instances are used.

A Practice Accommodation refers to how practices and related entities fit or are suitable or congruous, in agreement, or in harmony with each other.

In WOA, the function of accommodation is to with precision characterise a relationship and how entities in practices structurally and causally fit each other, the justification for how they fit, the assurance by argumentation and evidence for the justification, and the effectuation of how the fit is (dynamically) achieved through actions over time.

Therefore, WOA enables examination of how an information product produced in one practice fits with the information needs stated in another practice. See Fig. 2 for more examples of fit-cases that may be considered relevant to represent and analyse.

A practice relationship forms a composition of practices and uses of IP with in-use qualities such as usability and satisfaction into a co-use situation that enables the calculation of the aggregate utility of the constituent uses of IP.

Situation-in-Focus.

The situation-in-focus refers to a portion of reality that is determined to be the study, analysis, design, and/or evaluation object in which a set of practice relationships and practices should be addressed. Typically a situation-in-focus constitutes a portion of a broader situation-of-interest such as a problem-situation.

5.2 Situation Viewpoint

The Situation Viewpoint is a new ISO 42010 Viewpoint that frames relational concerns and establishes conventions for representing a situation-in-focus and with practice relationships. It is part of WOA and is used in the WOA method chunks [44], where Situation views are created, modified and used.

It is constructed from the concepts in the WOA conceptual model and incorporates specifically the concepts of ‘situation-in-focus’, ‘practice relationship’ and ‘practice role’ and references ‘practices’, represented according to the Work Viewpoint, and an “accommodation”. Represented according to the Accommodation Viewpoint.

An in-depth description of the Situation viewpoint is planned as future work.

6 Demonstration

An application of the Situation Viewpoint is demonstrated through a stylised illustration of how an archetypical situation-in-focus can be expressed using text and tables. The demonstration is briefly presented for the purpose and limitations of this paper.

The situation originates from two projects, IT portfolio management in a larger university and a research project that created an innovative kind of algorithm for handling sea transports. Table 1 illustrates the Situation view expressed in table form;

Table 1. Situation View with Relationships and Roles Played by Practices
Full size table

6.1 Work View with Identified Work Stories

The three (3) practices are expressed by work stories using natural language sentences. The following Table 2 and Fig. 2 illustrate two (2) different styles of expressing practices. A work story can also be expressed using canvases with sentences on post-it notes.

The producers’ and consumers’ work stories illustrate that although they are using the same information product (IP), the work stories are different with different agents, access to data, interests, actions and goals. Thus the aggregated utility of the two uses of the IP in an organisational setting should be calculated based on both uses (co-use).

Table 2. Shortened Creator Work story (due to space considerations of this paper
Full size table
Fig. 2.
figure 2

Demonstration of Producer and Consumer Work Stories and the Accommodation

Full size image

6.2 Accommodation View

The accommodation view exemplifies 5 kinds of commonly occurring kind of Fit. The length of this paper does not permit a demonstration of the details of How the two sides (causally) FIT each other, nor details about the Justification and Assurance of the FIT and how the FIT are dynamically achieved through actions over time.

7 Discussions

Knowledge about relationships and practices adds additional means for analysing interdependent and collaborating stakeholders in the context of an application of EA where information products (IP) are produced, stored, and exchanged for human and machine use. This includes analysis and explanations of similarities, differences, and fit between practices, stakeholders, and use of information products, as well as management of alignment, (dis)agreements, co-creation and participation in practices at micro and meso levels.

The WOA offer a neutral and balanced approach to representing, analysing, explaining and evaluating stakeholders’ (possible diverging) interests. It is neutral since all stakeholders are treated equally, with no preferential treatment given to any particular group. The neutrality promise to lower the barrier for stakeholders to participate in a balanced dialogue about which information products should be produced and used. These features may improve engagement and satisfaction by business stakeholders.

Knowledge about relationships and practices has a number of advantages over stakeholder analysis that focus on stakeholder and their synthesised concerns, including:

  • Detailed and precise analysis and evaluation can be made of the inherent features and qualities of agents, IP and practices, IP in-use, as well as co-use qualities that emerge from collaborative practices. This is aligned with ISO 250xx that separate product qualities from in-use qualities [11] and work practice theories that differentiate between the values of technology and technology-in-practice [12].

  • Situational method engineering can be used to situate and tailor IP to be more relevant and usable by stakeholders in their actual practices.

  • Evaluations can be made of the co-use and aggregated utility of IP in collaborative practices, which is a shift from local to organisational optimisation of uses of IPs.

  • Evaluations of how an IP can be or is used in practices can be made at different times, from the early formulation of use by each stakeholder in their own words to the acceptance of use by all stakeholders.

  • Detailed and precise analysis can be made of how two practices and uses of IP accommodate each other in terms of causality, means-ends, theory of change, and effectuation), which can address knowledge gaps [10] in the understanding of how EA Services leads to benefits for an organisation.

  • Knowledge and guidance can be reused from adjacent fields [34] that address the micropattern, consumer preferences fit with value provider.

The knowledge about relationships and underlying practices brings to the surface the importance of including stakeholders in evaluating the utility, usability, satisfaction, and relative advantage of information products. This supports the argument that summative participatory evaluations should complement formative expert evaluations [37].

The ISO 42010 standard does not directly support relationships between stakeholders and their practices. A design experiment was conducted indicating that ISO 42010 can be straightforwardly extended with the WOA concepts to enable the standard to benefit from the addition of increased relational and practice knowledge.

8 Summary

This paper presents a novel artefact, Situation Viewpoint resulting from a design science research (DSR) effort based on a problematisation of the lack of support for relationships between stakeholders in EA stakeholder analysis and management.

The incorporation of knowledge about relationships (and practices) promises to enrich EA stakeholder analysis and management by enabling analysis and explanations of similarities, differences, and fit between practices, stakeholders and their use of information products, as well as explicit management of (mis)alignment, (dis)agreements, co-creation and participation in practices at micro and meso levels.

We argue that an application of the Situation viewpoint has the potential to improve the relevance, design, tailoring, effectiveness, coherence, evolution, and evaluation of the co-use of information products such as models by stakeholders in their practices.

Furthermore, the Situation Viewpoint is a part of WOA that offers a neutral and balanced approach to analysing, explaining and evaluating stakeholders’ (possibly diverging) interests.

Limitations:

The presented and demonstrated results come from design theory-building activities and must therefore be complemented by theory evaluation(s) of the relevance of the Situation Viewpoint and other WOA artefacts to identified problems. This is according to Peffers iterative process [35], which is planned as future work.

Future Work:

An in-depth description of the Situation viewpoint and demonstrations of the other Viewpoints in WOA are planned as future work and paper publications. These demonstrations are planned to include designed canvases that support knowledge capture for each viewpoint. These canvases are used in the WOA Method chunks [44].

In the future work stream lies a completion of the formalisation of the WOA conceptual model, a presentation of integration of WOA with ISO 42010, and an in-depth description of the features and affordances of applying the practice accommodation.

Furthermore, the WOA provide a stepping stone for future empirical research about which relational (and practice) factors contribute to the stakeholders’ intention to use, use, co-use, and aggregate utility of information products within the context of relationships and organisation.