Developing and Evolving a Digital Twin of the Organization

Digital Twin of the Organization (DTO) is a relatively new concept that emerged to help managers have a full understanding of their organization and realize their objectives. Indeed, DTO enables connecting all the elements of an organization virtually by providing monitoring, optimization, prediction, and other capabilities through continuous simulations. Creating a flexible and evolvable DTO that covers and supports the organization’s business strategies is a complex and time-consuming task that requires engineering best practices. In this context, this paper presents and evaluates the EA Blueprint Pattern, which serves as an architectural reference for the development of a DTO by allowing for mapping well-known Enterprise Architecture concepts into software components defining the DTO software architecture. The evaluation is carried on by showing how to use the pattern for creating the DTO for a given organization. Then, a thorough discussion is conducted to analyze how the developed DTO should evolve to deal with vertical and horizontal integration. The lessons learned highlight the strengths and weaknesses along with practical implications for organizations that are eager to develop their DTO according to the EA Blueprint Pattern.


I. INTRODUCTION
The organization is a stable association of persons engaged in coordinated processes to achieve specific business goals [1].To ensure that the business processes lead a given organization to achieve its goals and deliver maximum value, continuously monitoring and assessing the process performances is essential [2].Currently, most organizations are utilizing various software to support each business process distinctly [3] and make strategic decisions based on assumptions due to a lack of thorough knowledge about all available information [4].Holistically analyzing an organization and covering a wide range of operational domains requires complex software solutions that integrate various tools, methods, and processes [5].
This requirement is exacerbated by the dynamic nature of the contemporary business environments and the The associate editor coordinating the review of this manuscript and approving it for publication was Fabrizio Messina .everchanging competitive markets, which in some cases require organizational growth and expansion [6].Depending on the reason for the organizations' growth/expansion, e.g., less dependency on other products, cost reduction, higher flexibility, better quality of service, etc., they may consider an integration strategy that works appropriately in terms of their goals, the current state of their industry, and the availability of suitable targets for acquisition or partnership [7], [8].Deciding on which strategy to pursue entails careful consideration of all the trade-offs since this decision is time-consuming and can lead the organization to significant and detrimental issues if the wrong strategy is chosen.Then, it is crucial to thoroughly assess the options and make an informed decision to ensure the organization's longterm success and avoid potentially unwanted outcomes [9].
To this end, Enterprise Architecture (EA) is widely recognized as an effective tool to holistically assess how changes should be implemented to achieve the desired organization's vision and goals [10].Indeed, EA is defined as a set of concepts, methodologies, and models used for describing the current or future organization's structure, business processes, information systems, and infrastructure, as well as its development and maintenance process [11].However, EA does not allow for capturing the dynamic aspects of the organizations, such as behavior, performance, adaptive response to market changes, prediction, user interactions, etc. [12], [13].
On the other hand, the Digital Twin of the Organization (DTO) is emerging as a powerful technology to provide an accurate digital representation of the organization that includes, beyond the representation of devices, machines, and physical assets, also structures, processes, services, functions, people, and all other elements relevant for the organization's operation [14].Indeed, DTO complements EA to move organizations a step forward in the digitalization journey.Specifically, DTOs allow managers to have a complete understanding of the business and to realize the organization's goal [15] through perpetual simulation and analysis, which enable the continuous assessment and optimization of the organization [14].To this extent, DTO exploits engineering best practices for validating, optimizing, estimating, and predicting the future performance of organizations because all operations are virtualized [16].Nevertheless, engineering DTO is challenging as it entails creating realistic models mimicking the organization, providing a smooth, flexible, and cost-effective implementation that integrates all the organization's assets, and facing many other complex engineering obstacles [17].
As EA concepts are widely recognized and understood in the organizational context by most organizations' managers and stakeholders, employing them as a starting point for developing DTO would be beneficial.To straightforwardly map the organizational aspects, expressed by the EA, into software components defining the DTO Software Architecture (SA) [18], this paper addresses concerns on ''How to map EA concepts to SA for facilitating DTO development''.
Further, when an organization needs to implement a physical change, its DTO emerges as a crucial and sustainable asset for thorough analysis, experimentation, and informed decision-making across diverse scenarios before the actual change of the physical environment [19].The DTO should not only serve as a tool for assessing the impact of changes but also have the flexibility to accommodate organizational changes and evolve accordingly to prevent any misalignment between the physical and digital counterparts [20].
Towards these objectives, the main contributions of this work are: • Presenting EA Blueprint Pattern that leverages established EA models to develop DTO utilizing Agile Design Principles, • Evaluating EA Blueprint Pattern through a lightweight illustrative case study, • Offering simulation, flexibility, and evolvability as the core characteristics of DTO, The paper is organized as follows.Section II provides DTO-related literature review and concludes with existing gaps/challenges in this field.Section III sets the context by illustrating the industrial use case.Section IV, by introducing EA blueprint pattern, highlights its characteristics to address DTO developing and evolving challenges, whereas Section V details how we perform the development of the DTO by using the EA Blueprint Pattern.Section VI analyzes the efforts required to evolve the developed DTO in accordance with the EA blueprint pattern where physical changes happen.Section VII discusses the learned lessons in the process of developing an evolvable DTO via the proposed pattern.Threats to validity of the proposed approach are presented in SectionVIII.Finally, Section IX draws the conclusions and provides hints for future work.

II. RELATED WORK
Notwithstanding the widespread use of digital twins in recent years [21] for different applications in aerospace [22], manufacturing [23], product design, production, prognostics, and health management (PHM) [24], Metaverse [25], humans [26], and representing the living and non-living entities [27], there are few studies on both conceptual and practical aspects of developing DTO [28] to improve business processes [3] and result in a simulable digital twin at an organizational/enterprise level.In this regard, this section reviews the current state-of-the-art in DTOs, covering aspects ranging from the concepts to the significance and the prevalent challenges associated with them.

A. CONCEPT
For describing DTO, by expanding the digital twin idea from digital representations of physical items to include digital representations of the entire organization, Parmar et al. [15] propose the term Organizational Digital Twin.Organizational Digital Twin acts as a living digital simulation model of the organization that updates and develops as the company grows.It also allows scenarios to be fully evaluated to anticipate the performance of prospective tactics and plans once it is ready.The authors presented a dynamic evolutionary process with five principles as the theoretical road map for successfully constructing an organization's Digital Twin from its current (as-is) state.
Riss et al.'s [12] method for defining DTOs involves mapping the 5-layer architecture of Digital Twins in Manufacturing (DTMs) [29].Their approach places a particular emphasis on adapting the User Interface Layer of the DTO to effectively address discrepancies between DTM and DTO.However, this research does not adequately address how to accommodate operational and evolutionary changes, such as adding new workstations or other equipment, that are common in modern organizations.
Yildiz et al. [3] propose the extension of DT-based Virtual Factory (VF) to Virtual Enterprise.In this context, they attempt to generalize their findings, solutions, and framework of DT-based VF to DT-based enterprises.However, their results highlight that further empirical research is required before the VF concept can be expanded to include the integration of digital technologies to represent organizational activities, resources, and architectures.No measurable use case has, however, been provided in this study to illustrate how a virtual enterprise should be established in practice.This is also where the majority of studies on Digital Twins at the Organizational level, like [30] and [31], fall short.
Lyytinen et al. [32] classify the types of digital twins into three groups: digital twins of physical objects or things (DTT), digital twins of business processes (DTBP), and digital twins of organizations (DTO).Accordingly, they discuss the evolution of digital twins, particularly the shift from DTBPs to DTO, by emphasizing that a comprehensive DTO must proceed beyond mirroring operational processes and consider fundamental organizational properties.These properties include agency, conflict, learning and forgetting, hidden interdependencies, multiple realities, and emergence.
Park and van der Aalst [33] define DTO as ''a digital representation of an organization that aims to uncover business process flaws and enhance operational decision-making by simulating various situations.''For realizing the DTO, the same authors in [34] employed the action-oriented process mining framework [35] for monitoring violations of constraints in the operational process.As a result of these observations, the required actions for upgrading the information system are triggered automatically.To do this, they created the Digital Twin-Interface Model (DT-IM), which is created of object-centric Petri nets that represent business processes and their information systems.The action-oriented process mining framework facilitates automatic model enhancement, but the whole software architecture for the DTO has not been proposed with flexibility and extensibility as the primary concerns.

B. SIGNIFICANCE
Within the organizational context, DTO plays a significant role in improving situational awareness and facilitating effective decision-making by acquiring, integrating, and transmitting appropriate models, knowledge, and data from relevant sources in the proper context.This process is particularly applicable to various stages such as design, manufacturing, optimal operation, monitoring, and predictive/proactive maintenance [36].Yildiz et al. [3] emphasize the importance of managing coordinated evolution (co-evolution) through DTO, which is defined as the unpredictable scenarios for dynamic manufacturing operations caused by modifications/changes [37] in the product, process, and system domains of the enterprise, for survival in highly competitive settings.This aligns with the view presented by Diez and de Lara [5], who assert that organizations are inherently dynamic and unpredictable, with an unbounded degree of freedom, which makes them different from other kinds of systems.The significance of DTO, therefore, lies behind its capability to represent various views of reality with fast evolution and casual relations with real objects, individuals, and other technologies.To this end, they place DTO as the bridge between Fundamental Systems-including the physical setup and social systems-and Governance System-responsible for structuring fundamental systems operation-of the conventional enterprise model to control the behavior of the entire organizational system by making the virtual representation of organizational elements and interaction with conventional tools.
To overcome the actual distance between real-world occurrences and information systems within organizations, Kubelskiy [28] advocates for the development of DTOs based on ontologies, knowledge graphs, and enterprise architecture.This approach is similar to the concept introduced by Dragon1, which presents the Enterprise Architecture Blueprint as a comprehensive representation of an enterprise's architecture at various levels [38].These frameworks provide a structured and formalized way to represent and manage organizational elements, addressing the challenges associated with the lack of formalization.Kumbhar et al. [39] identify a similar gap in implementing DTs in real-world shop-floor operations, leading them to propose a four-layered framework for optimal decision-making in manufacturing systems.This framework not only addresses bottlenecks in shop-floor operations but also aligns with the broader theme of enhancing decision-making processes within organizations.
Groher and Riss [40] present a forward-looking approach with DTO, focusing on supporting weakly structured and knowledge-intensive business processes.In response to the increasing demands for organizational agility, customer focus, and information utilization, DTOs emerge as highly information-based, real-time enabled, and visualizationoriented solutions.They bridge the gaps identified in existing business information systems, offering a more suitable fit for the evolving requirements of modern organizations.
The main contributions of DTO in modern organizations, based on literature, are providing a holistic and structured approach to managing dynamic environments, facilitating optimal decision-making, and addressing the challenges introduced by the lack of formalization and distance between real-world events and information systems.

C. CHALLENGES
Reviewing the existing literature reveals that, apart from process mining techniques, practical ideas of DTO are still largely in the theoretical and conceptual stages without concrete implementation.The ISO 23247 standard [41] for digital twins also provides a general and high-level abstract framework and functional views.However, notable questions in DTO, such as what are the core elements of organizations, and how to model and continuously simulate them [42] remain without a reliable solution.On the other hand, process mining techniques use the recorded activities performed by individuals, machinery, and software, so-called event logs, for the discovery, analysis, and enhancement of business processes [43].However, given that process mining adopts a bottom-up approach for constructing DTO from event logs, a critical challenge is identifying appropriate event logs for making an accurate DTO [44].Additionally, it is always more advantageous to simulate and examine potential future paths and what-if scenarios before implementing the best strategy in the real world [45].In this context, process mining-based techniques could suffer integration with other process improvement methods [46], which simulation is one of them [47].Indeed, our work focuses on the development of DTO through a top-down methodology-taking the organization's existing enterprise architecture into accountwith simulation as its core.Then, it could be accompanied by process mining techniques for ultimately enhancing the organization's competitive capabilities.

III. RUNNING EXAMPLE
The running example is described by means of its Enterprise Architecture (EA), which can provide a detailed understanding of the organization through a comprehensive picture of the entire organization.This example will be used to evaluate the EA Blueprint Pattern applicability in developing and evolving DTO.

A. ORGANIZATION DESCRIPTION
The medium-sized organization under study is a supplier of different articles in the automotive industry.Figure 1 represents an overview of the organization's Enterprise Architecture which is modeled using ArchiMate [48], a standard modeling language for expressing Enterprise Architecture.The figure captures a holistic perspective of the organization's architecture, offering a layered representation of its business, application (or information), and technology.
The top layer of the architecture in Figure 1 represents the organization Business Architecture.It consists of three departments/actors (top row), assigned to business roles (second row) and business processes (third row) for driving the company from the first step, receiving client orders, to the last step, delivering items on time.To be more explicit, a business process represents a sequence of business behaviors that results in a certain end, such as a defined set of products or services.Business actors are expected to conduct business behaviors.A business role, on the other hand, is the responsibility for executing a certain behavior that an actor might be assigned to, or the part that an actor performs in a given activity.As an example, in Figure 1, the Designing a product is a business role whose actor is Design, Production, and Quality Department, and two processes, which have concrete outcomes, include in this role: Concept Design and Final Design.
Several concurrent processes are accomplished by different departments in the organization.For example, while Finance and Accounting Department works on price calculation of received orders and purchasing the previous orders material, Design, Production, and Quality Department plans time and task scheduling for different orders to prevent any conflicts in the production line and delay in the outcome.
Obtaining support from the Information system or Application Architecture layer (middle layer in Figure 1) is required for efficiently executing business processes.To this end, a number of applications collaborate or work independently to provide IT services that are then consumed by business processes via application services.
The bottom layer in Figure 1 is called the Technology Architecture.This layer depicts technology services such as physical processes, storage, and communication services needed to run the applications, and the computer and communication hardware and system software that realize those services.Physical components could be also added to this layer to model physical equipment, materials, and distribution networks.

B. EXPECTATION OF DTO
The organization, to survive and prosper in today's competitive business environment, needs tools that, in addition to managing daily operations, help the organization become smarter, for example, by predicting probable future events.DTO provides a suitable basis for continuous assessment, optimization, and prediction by representing all the organizational system elements and connections in virtual models and through perpetual simulation and analysis.Therefore, in order to mimic and simulate the structure and behavior of an organization, a DTO must be able to: collect data from the environment; develop models of organizational elements; interact with existing software in an organization; realize business processes, and analyze them to generate outputs in the form of physical system control actions, enhanced data for other applications, and services for business processes.
In particular, the designed DTO for the specific use case should encompass a range of essential functionalities: • Accurately mirroring the existing physical organization in its current state.
• Identifying and comprehending vulnerabilities within processes that give rise to inefficiencies, bottlenecks, deviations from anticipated outcomes, or unknown status.
• Monitoring the operational status, health, and throughput of physical devices within the technology layer.
• Conducting analyses of potential ''what-if'' scenarios to identify optimal strategies or courses of action.
• Predicting the expected outcomes and performance metrics of different parts of the organization, such as production performance when new orders are received.
• Facilitating seamless integration with other DTOs, enabling interoperability and collaboration between different components of the organizational system.
• Adapting and evolving to accommodate growth and expansion within the physical counterpart of the organization.By incorporating these functionalities into the DTO, the organization can enhance its operational capabilities, and improve decision-making processes and the efficiency and resilience within its organizational systems.

IV. EA BLUEPRINT PATTERN FOR DTO
In this section, we elaborate on the EA Blueprint pattern [20], to explore its core components and how it could facilitate the mapping of an organization's EA model to simulable software for allowing the dynamic and continuous simulation and analysis of organizational behavior and performance.
This pattern leverages the organization's established EA model for developing DTO while embracing the principles of flexibility and evolvability through Agile Design principles.In designing the pattern, architectural concerns for DTO [14], including modularity, granularity, composition/decomposition, and evolution, have been considered to support the DTO incremental development.Accordingly, timely alignment of the mismatches that occur between the real-world organization and DTO, due to the continuous changes in the organization is handled by the proposed pattern (i.e., the pattern relies on other patterns facilitating software evolution).The pattern, illustrated in Figure 2, adopts a nomenclature similar to the organization architecture modeled by ArchiMate (see Figure 1).By employing this naming convention and dividing the macro components with inspiration from EA, stakeholders from various domains can readily comprehend the elements involved.
The proposed EA blueprint pattern consists of three macro components for DTO layers, as its core elements so that new DTO elements can be easily added as cohesive and loosely coupled services.However, the pattern does not specify how to implement the macro components.Rather, it gives freedom to properly select the analysis technique and modeling language engine needed to provide the stakeholders' expectations.

A. BUSINESS ARCHITECTURE
(BA) in the proposed pattern represents business processes and interactions at the organizational level.BA plays a key role in realizing DTO, as it embeds processes and models for mimicking the real organization through the DTO.Given that organizations are dynamic entities constantly subjected to changes in response to external factors [49], it is imperative that the DTO can easily adapt and evolve.To this end, EA Blueprint Pattern promotes the exploitation of Service-Oriented composition/decomposition style and Agile Design principles [50] to implement the BA.The flexibility and evolvability of Service Oriented Architecture (SOA) are derived from its emphasis on loose coupling, interoperability, reusability, scalability, decentralization, and technology neutrality [51].These aspects, in combination with the agile design principles, enhance DTO modularity, enable different levels of granularity, and facilitate smooth evolution, enabling organizations to respond quickly to changing business requirements where new services can be developed, modified, or replaced without requiring extensive changes to the existing system.The main architectural elements for constructing the BA are: Unit-Level Service Container, Registry, and Evaluation Engine (see the left-end side in Figure 2).
The Unit-Level Service Container is responsible for the effective management of service deployment and provision.These services act as digital representations of physical elements within the organization, such as machines, spaces, activities, and people.In other words, the elements of Technology Architecture layer of EA (Figure 1) are modeled as unit-level services and mapped to the Unit-Level Service Container.Following the principles of SOA, the unit-level services are registered in the service Registry.This ensures that when changes occur, such as the addition or removal of physical elements, the corresponding modifications are made in the Unit-Level Service Container.Further, unit-level services can be composed to create complex functionality and increase the level of abstraction.Direct access to the Persistent Storage in Information Architecture is considered for Unit-Level Service Container to retrieve the data of interest, as some services might need to perform complex analysis on Historical Data (e.g., calculating average values, or computing trends).
Within the Evaluation Engine, multiple Business Process Models can be employed to simulate various behaviors, allowing for versatility and flexibility.Evaluation Engine serves as a dynamic orchestrator, capable of executing specific BPMs based on user requests or events (e.g., data updates, system events).Each BPM has a defined structure and logic that outlines the sequence of activities, decision points, and data dependencies.The Evaluation Engine enforces this logic during the execution of the BPM to achieve the desired behavior.The binding with unit-level services, to get up-to-date information on each service, in execution makes it a powerful mechanism for managing and simulating the behavior of the DTO in response to various inputs and conditions and facilitates informed decision-making and effective planning.The Evaluation Engine not only maps the Business Architecture layer of EA (Figure 1) but also serves as a main component for exploring diverse scenarios, providing valuable insights into their potential outcomes.
Since organizations are continuously evolving, both the unit-level services and business processes may need frequent updates.Propagating the changes at the unit-level to allow the Evaluation Engine, to always invoke the latest service version, may overwhelm DTO maintainers.Moreover, some parts of the Business Process Model can temporarily work acceptably well by using old versions of the unit-level services.For those reasons, the unit-level services are registered in the Registry including their version, so that Evaluation Engine can find and dynamically bind to the most appropriate version.

B. INFORMATION ARCHITECTURE
(IA) in the EA blueprint pattern is in charge of: (i) handling the data streams from organization elements, collecting the raw data, and creating the information needed at the business level, (ii) handling the persistence of historical data, (iii) and visualizing the information of interest.Given the EA of the organization (Figure 1), this macro-component models and maps the elements of the Application Architecture layer.
For providing the aforementioned functionalities, EA Blueprint Pattern leverages Model-View-Controller (MVC) (see right-end side of Figure 2).Indeed, this pattern effectively separates the concerns by dividing the information architecture into three interconnected components.The Controller entity orchestrates the data flow and feeds it into the Model, manages user interactions, and establishes 45480 VOLUME 12, 2024 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
the communication between the Model and View.The Model represents the (real-time) information needed at the organization level and creates business-level information.The information retained by the Model depends on the semantics of the data streams but is agnostic to the specific format.The View offers GUI for visualizing the organization status and other information of interest.MVC's modular structure allows for flexibility and adaptability to changing business requirements.As the organization's needs evolve, each component can be modified or extended independently.For example, the Model can be adjusted to handle new types of data or adapt to changes in data formats, View can be updated to visualize new types of information or accommodate changes in the presentation layer, and Controller can be modified to handle new user interactions or incorporate additional business logic.Implementation details of IA are provided in Section V.While MVC is a suitable choice for covering the desired functionalities of IA, other patterns may also be considered as alternatives for implementing this macro component.

C. SYNCHRONIZATION
manages the real-time information exchange between BA and IA.Constant change can quickly make the DTO outdated and the manual task of re-configuring an evolution to incorporate recent changes makes it cumbersome.Therefore, EA Blueprint Pattern includes a first-class element specifically designed to handle the synchronization of real-time information at the business level to ensure alignment between BA and IA.Although the concept of this element may seem straightforward, it is important to note that existing methods for connecting real-time data with their digital representations often lack standardization [52].In the development of EA Blueprint Pattern, inspiration is drawn from the work of Kirchhof et al. [53].The Business Process Model within the BA incorporates ports that serve as injection points for receiving external information.These ports are designed to integrate specific real-time data retrieved from the Model into the Business Process Model.
As a conclusion for this section, following the EA blueprint pattern, we expect to obtain a flexible DTO architecture that allows us both to extend it during the digitalization journey and to evolve its parts to be kept aligned with organizational changes.The following sections describe the DTO implementation details for our industrial case study using the EA blueprint pattern.

V. DTO DEVELOPMENT FOLLOWING THE EA BLUEPRINT PATTERN
An organization cannot become digitally transformed overnight.It should go step-by-step, starting with one business process, integrating it with the enterprise, and then repeating these procedures [30].Among all the business processes in the running example (section III), we start DTO journey by describing a specific process, i.e, Production Business Process (called Production in the third row of Business Architecture in Figure 1) of the organization.In this context, Production Business Process will be described in more detail and then the required steps, from design to implementation, for systematic creation of the simulable DTO, following the EA blueprint pattern, will be presented.

A. PRODUCTION BUSINESS PROCESS-DESCRIPTION
The Physical Production Line (called Production Line in the Technology Architecture in Figure 1) is the basis of the Production Business Process, and its details will be discussed first.The Physical Production Line is represented in Figure 3. Referring to this figure, the arrival of raw materials (the leftmost element in the figure) triggers the production line process.It consists of three workstations: • Manufacturing Workstation (MWS) produces the articles.It consists of two identical machines that work in parallel.This workstation requires an operator to reconfigure the machines depending on the specific variant to be produced.
• Reworking Workstation (RWS) fixes the defective articles.Machines in MWS do not always manufacture the units correctly but sometimes they have defects that need a manual rework before being packaged.If there are no articles to rework, this workstation is idle.If there are articles to rework, any of the operators can rework the articles.
• Packaging Workstation (PWS) creates a package of several articles of the same type.It consists of two identical machines that can work in parallel.This workstation is not automatized, and each machine requires an operator.Before entering each workstation, the articles are temporarily stored in ''waiting areas''.Waiting Area M, Waiting Area R, and Waiting Area P are managed according to a First-In-First-Out (FIFO) policy.After the packaging in PWS, the orders are stored in a location called products Storage.Finally, the production line includes a conveyor that transports the necessary raw materials for manufacturing the articles to Waiting Area M, and a conveyor for moving articles from MWS to Waiting Area P. Articles that need to be reworked are manually transported from MWS to Waiting Area R, and from RWS to Waiting Area P.

B. PRODUCTION BUSINESS PROCESS-DTO DESIGN
This section presents a DTO solution for the Production Business Process, detailing the development of each of the EA Blueprint Pattern components at the design level.This is the initial step that an organization should embark upon in its journey toward developing a DTO, setting the foundation for subsequent implementation details.

1) BUSINESS ARCHITECTURE
This macro-component replicates the structure and behavior of the organization and it is implemented following SOA (see left-end side of Figure 2).The Unit-Level Service Container, which represents the Technology Architecture and Physical Elements of the real organization and handles the relevant data, comprises six types of Unit-Level Services (ULS).
1) ULS Manufacturing includes two machines in MWS.
Each machine has its ID, which is always a necessary parameter when requesting the service.The service can provide both real-time information -synchronized from the model in the Information Architecture-and complex information such as the average service time to produce an article, the average time to change its configuration, the proportion of time that the machine is idle (either because there is no work to do or because there is not any operator on it), or the expected time until maintenance is needed.2) ULS Packaging includes the two machines in PWS.
This service gives information about the observed service times to package a batch and the proportion of time that the machine is free to show the availability of operators to work on another task.3) ULS Waiting offers information about the buffers in the Production process.It includes the three waiting areas and the storage area.In particular, Waiting Area M, Waiting Area R, and Waiting Area P are implemented by means of a FIFO queue.Requests to this service also need to specify the area ID as a parameter.For the three waiting areas, the service provides information about the average residence time of articles and the average number of articles.The service also provides information for all four areas about the maximum capacity of the area and the current number of articles.4) ULS Transferring involves the services of the two conveyors, before MWS and PWS.Requests also need to include the conveyor ID as a parameter.The service provides information on both current and average values for their speed and throughput.It also provides information about their length and the expected time until maintenance is needed.5) ULS Routing includes the services for the element that inspects whether an article has been correctly produced in MW and, thus, it decides whether it proceeds to PWS conveyor for packaging or to Waiting area R for rework.
It provides information about the proportion of articles correctly produced in synchronization with the related sensor in Information Architecture.6) ULS Operating involves the services for the human operators.Services are invoked using an operator ID.
It provides information about their current activity, the proportion of time in each workstation, the proportion of idle time, and the frequency of change between workstations.The core architectural element of BA macro-component is the Evaluation Engine.It is in charge of evaluating the organization Business Process Model using organizational knowledge and orchestrating all the ULS based on the business processes.Furthermore, evolutionary changes of Business Process Model are realized in this architectural element manually or automatically through Synchronization macro-component and leveraging process mining [34], or other approaches.
Figure 4 shows the Business Process Model of the organization Production business process, realized by the Evaluation Engine.The Production process consists of three subsystems.The first subsystem includes the two machines in MWS, the operator, the Waiting Area M, and the switch that inspects whether an article was correctly produced and takes the routing decision of the article towards the conveyor or the reworking area.The second subsystem comprises the elements involved in the reworking of an article: RWS, Waiting Area R, and the possible operator.The third subsystem includes the two machines in PWS, its two possible operators, and the Waiting Area P.

2) INFORMATION ARCHITECTURE
The Information Architecture (see right-end side of Figure 2) receives the streams of raw data, transforms them to the appropriate format of information (model), shows the real-time relevant information, and manages the persistent storage of information in the historic.Figure 5 illustrates this component in the EA Blueprint Pattern, following the MVC pattern.
The Controller receives the raw data from physical elements like sensors, switches, machines, operators, and other IT subsystems (incl.web portal, ERP, Canvas, etc.).The non-comprehensive list of input data includes: the placement of new orders, the moment when an article starts and ends its production in each machine in MWS, moments when the configuration of a machine in MWS is changed in order to produce a different variant, whether each article has been correctly or defectively produced in MWS, the moments when a rework activity for an article begins and ends, the moments when a packaging activity for a set of articles begins and ends, and the moment when an order placed in the product storage.The bottom-most part in Figure 5 illustrates these inputs.The Controller processes these streams of data, transforms them to the engineered representation of plant information (i.e., the Model), and changes the Model with the new information.For example, the inspection of an article after its correct production in MWS produces the data <orderID, numberOfArticle, timestamp, "Correct"> The View shows relevant real-time and predicted information about the status of the plant elements that can be immediately derived from the Model, such as the current occupation of the queue of orders waiting for production in  MWS, the status of a workstation, the amount of work-inprogress (as the sum of articles in all queues, conveyors, and workstations), or the lead time of the last order delivered.Information that requires a more complex analysis of information, including historical and a broader perspective with several physical elements, is not shown in this View but delegated to the analysis performed by the Evaluation Engine at the Business Architecture level.Moreover, dealing with diverse user roles is crucial for DTO Information Architecture since each role in the organization demands access to a different set of relevant information.Handling the multiple roles for information architecture is addressed by using multiple dynamic layouts.This functionality results in a multi-page application that facilitates the evolvability of future updates in the roles.For each role, the IA is designed to have the functionality to dynamically add graphs at run-time, which could be leveraged to add new visualizations to the dashboard.This way of relating different types of dashboard abstractions was described by Ivanov et al. [54].
The Model is the computerized representation of the physical domain.It represents the plant information following the Controller commands.When the Controller sends new information to the Model, the Model autonomously stores the modification in a database of Historic information.Figure 5 shows only an excerpt of a generic model, not the full model, and the ''Order'' Class of the case study.The attributes shown on the ''Order'' Class represents the type of article ordered (articleType), the number of articles requested in the order (numArticlesOrdered), the order identifier (id), the moment when the order was received (creationTime), and the order current status (status).
The Historic database is written by the Model entity and read by the Business Architecture EA Blueprint Pattern component when elaborate analyses are executed.

3) SYNCHRONIZATION
This EA Blueprint Pattern component provides the Business Process Model with timely information from the Model.It is an event-based Synchronization; i.e., it actuates when the Model is updated.In particular, the Business Process Model at the BA takes external information, which is meant to feed particular real-time information obtained from the Model into the Business Process Model.To this end, two key actions are implemented: (1) identifying the two particular spots in the BA and IA that must be aligned and (2) supplying the BA with real-time information.Nevertheless, the event-based paradigm is not the only possible option for developing the synchronization.If the traffic generated by the Synchronization became excessive (e.g., the stream of a sensor with a high refresh rate) for the Business Process Model execution, a time-based synchronization with a periodic update or other solutions would be recommended.

C. PRODUCTION BUSINESS PROCESS-DTO IMPLEMENTATION
This section describes the implementation strategy of the DTO portion that is related to the real-world illustrative scenario in Figure 3.
The BA is deployed as SOA, as shown in Figure 6; each ULS is implemented and deployed in the form of a service, which feeds the Evaluation Engine with the latest data before beginning a simulation.Each ULS computes many process parameters related to the workstation, which they are assigned to, by relying on a Database Cache service that periodically fetches a time window of data from IA's Persistent Storage.In this way, the Evaluation Engine is provided with values that approximate the real process in its current status.The Evaluation Engine contains a Simulation block for simulating the business process model.It is implemented by the Discrete-Event System (DES) library in MATLAB Simulink environment. 1 It is also continuously updated thanks to the same service that is responsible for fetching data from the ULS by checking, through the Synchronization module, the presence of updated versions on a given repository before starting each simulation.
1 https://www.mathworks.com/solutions/discrete-event-simulation.htmlThe Simulation service is invoked by a timed routine and provides the Synchronization module with its results that are propagated through the IA and can be visualized in the View component.
Every workstation of the Production technology architecture layer is equipped with sensors able to continuously monitor relevant metrics e.g. the ongoing orders.This data is firstly transferred to the Model and then saved into the Persistent Storage.The View allows visualizing the concrete set of information that is relevant for each type of stakeholder (called roles in the following).It is implemented using the Python framework Dash. 2 The visualizations for the view are created with the framework Plotly. 3Plotly provides functions for different chart types, each accepting a wide range of arguments for customization of the chart.
Three distinct roles within the scope of this use case are considered, namely the operator, who handles the articles; the production planner, who oversees and optimizes the production process; and, lastly, the executive manager, who is only interested in a high-level overview of how the production line is performing.Specifically, operators need a live view of how many articles are currently in the production line, and how many articles are in each of the workstations waiting areas.It contains a data table for showing the current number of elements in the production line or Work In Progress (WIP) and in the Waiting Areas.
The production planner needs monitored and predicted information on when orders arrive to be produced and data about when articles enter and leave each workstation.Also, the production planner needs to be able to see historical data of the number of articles in each of the queues and in the production line overall for the past 5 days.The view page for the production planner is shown in Figure 7.It comprises two sections: a section for the monitored information and a section for the predictions about the near future.The monitored section contains charts visualizing the inputs and outputs of articles to the production line components.Additionally, the production planner view page contains three line charts showing how the amount of WIP and articles in Waiting Areas has evolved over the last 5 days.In turn, the prediction section shows how the status of articles and elements in the production chain are expected to evolve in a predefined time horizon for the same parameters that were shown in the monitored section.
Lastly, the executive manager only needs to visualize the articles lead times monitored and predicted into the near future.Figure 8    reasons), depicting the predicted lead times of future articles.Scatter charts were chosen for these visualizations, as they highlight possible relationships between the articles sequence and their lead time.

VI. DTO ENGINEERING TO ACCOMMODATE CHANGES OF PHYSICAL ORGANIZATION
Generally, two well-known strategies for organization growth/expansion are Horizontal and Vertical Integration.The former considers the joining of businesses through the acquisition or takeover of similar organizations that are at the same developmental stage, in the same sector, and producing the same products, whereas the latter happens when one business takes control of one or more stages of business processes [55].
This section provides insights into the efforts required to evolve the developed DTO in accordance with the EA blueprint pattern.It focuses on outlining the necessary steps and considerations involved in the ongoing evolution process of the DTO when Vertical and Horizontal integration happen in the physical organization.

A. VERTICAL INTEGRATION
Due to delivery issues, such as delayed product delivery to clients, which leads to lower customer satisfaction, the organization under study is willing to integrate the Transportation 45486 VOLUME 12, 2024 Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.
Process into its supply chain (Vertical Integration).Thanks to this integration, the organization gains more flexibility and independence.This section details this integration following the incremental development approach suggested in [14] adhering to the EA Blueprint pattern.
Managers describe their expectation of Transportation process as following: ''The Transportation process occurs concurrently with the Production process and comprises the Delivery entity and the Waiting area D. The Waiting area D physically corresponds to the location where the previous Production process stored the packaged products, i.e., the Product Storage.The Delivery entity actuates periodically, it checks the packages in the Waiting area D and transports to the destination as many the packaged orders as can be possible to deliver subject to respecting the correct sequence order.Therefore, the Delivery is the entity in charge of enforcing the orders departure policy.'' To develop the DTO that reflects the organization correctly, IA and BA in EA blueprint need to be extended.Regarding the IA, the Controller needs to handle a new type of events that indicates the timestamp of the periodic arrival of the Delivery entity and the IDs of the orders that are delivered during such arrival.The periodic delivery event can deliver zero or more orders, depending on how many orders were produced and their sequence order.The Model needs to represent the arrivals of the Delivery entity, the ''status'' attribute in the Order Class needs to include the ''delivered'' status, and it should represent the status of the Waiting area D, from where the delivered articles must be removed.The View needs to show the information about the Waiting area D and the expected arrival moment of the next Delivery entity.
Regarding the BA, a new ULS Transport is needed to provide information about the period of the Delivery arrivals and statistics about the number of articles that are transported in each arrival.The ULS Routing is extended to become a service for all elements that make decisions on the routing and progress of the articles.Concretely, it is extended to provide information about the gate that delivers the packaged elements in their correct order.In turn, the Business Process Model is extended to incorporate the Transportation process as depicted in Figure 9.a.It shows that Waiting area D is modeled with a queue element (DWS Queue) that offers its elements to a gate element (DWS Gate), which selects them according to the sequence order (Input Sequence ID).It also shows that this action can only happen when a resource called Delivery is available, which happens periodically with an inter-arrival controlled by the Periodic Delivery element.
The most relevant activities for integrating the Transportation DTO and the previously developed DTO explained in Section V, are the following: • The Business Process Model has to represent both processes.Figure 9.b shows the integration result.
• Since having two storages is not logical, it is necessary to merge the Product Storage element in the Production DTO and the Waiting area D in the Transportation DTO into a single element.It was decided by the organizational board that Waiting area D took the responsibility of the entity and, therefore, the DTO of the Production process was modified to send its packaged orders to the Waiting area D. Regarding the modification in the Business Process Model, Figure 9.b shows that the packaging subsystem connects with the queue in the Transportation.Regarding the modifications in the IA, the Model and View needed to override its references to the Product Storage (nothing was necessary to merge in the Controller since there were not events received from that location).
• A ULS will handle all the information about the routing of articles, the Routing ULS needed an integration effort to also execute the delivery gate services.

B. DTO ADDED VALUES IN THE VERTICAL INTEGRATION SCENARIO
Managers within the organization are tasked with making decisions regarding the optimal policies and resource allocations for the newly integrated  1, the most favorable outcomes, reflected in the lowest values for both AW and AL, are associated with the scenario in which there are four resources (trucks) and the departure policy, which governs the frequency of resource triggers, is set at 10 times per day.However, the average utilization of resources (AU) for this case is 0.99.This implies that the trucks are consistently in operation, which could lead to increased vehicle breaking, maintenance expenses, fuel costs, and related concerns.Therefore, an alternative approach could be deploying four trucks with four departures per day, resulting in an AU of 0.85.By the way, if the organization can tolerate slightly longer waiting times, and if the cost of maintaining trucks is a significant concern, the best-suited choice could be owning three trucks with a departure policy of two times per day.In this case, the AU value drops to 0.59.Identifying the most advantageous scenario depends on the preferences of the management and the strategy of the organization.

C. HORIZONTAL INTEGRATION
The management board of the organization is exploring a new business activity to take advantage of opportunities and to survive competitors' improvements.Concretely, the managers are planning to introduce its production to a new market, the highly-customized luxury sector.Therefore, they would like to integrate a luxury Production line (Horizontal Integration) into their organization.It is worth noting that, in this subsection, we proceed with the assumption that the vertical integration discussed earlier is already established in the organization's DTO.
The new highly-customized articles will bring new characteristics to the organization, such that: • orders of articles will be very specific, the expected batch size of new articles is usually one or two; • new articles will require special shapes and materials, which need a special design (see the Concept Design process in Figure 1); • special luxury materials will need to be ordered to suppliers for specific orders after their design, which can cause an accumulation of work-in-progress orders while waiting for the arrival of luxury material (see Ordering process in Figure 1); • machines in workstation MWS cannot automatically manufacture them, plant operators with specific skills for each order will be needed for manual production of these articles; • they do not need to respect the sequence order of the regular articles but can be transported to the customer as soon as they are packaged.To fulfill the requirements of the luxury sector, there will be a new Customization Workstation (CWS), the operators will be a limited resource, and their specific skills will matter.Any operator can work on MWS, RWS, and PWS, but when a highly-customized order will reach CWS, an operator with appropriate skills will have to move there.The organization, then, needs to create a list of necessary skills.Each operator will have a value for each possible skill, e.g., in the set {expert, medium, low}.When an order for a highly-customized article arrives, it will be immediately labeled with the skills required for its production.
For BA, the ULS Operating has to be modified to offer the new services related to the operators' skills and their assignment of tasks for highly-customized articles.The DTO also needs new ULS that offer services related to CWS and the necessary skills to manufacture the article.In turn, Transport service requires only a change in its logic since the orders of highly-customized articles are not affected by the ordered sequence of delivery.The Business Process Model has to include the new part that represents the manufacturing of the new types of orders and to modify the logic of the delivery of the of orders.
For IA, Figure 10 shows the modifications to apply in this element to perform horizontal integration in the EA Blueprint pattern.The Model needs to represent several modified information as well as some new information.Among the new information to represent, we list the operators' skills and all the information regarding the new workstation CWS.The information in the model that now must evolve includes: the types of articles that can be ordered, the types of status of orders (e.g., now an order can also be undergoing manual production in CWS), the fact that an order may require certain specific skills, and the type of delivery in Delivery, which is no longer strictly in the same sequence as articles were ordered.In turn, the Controller needs to accept new data related to the new activities in the production line, such as the manufacturing in CWS, the assignment of a concrete operator to a production task in CWS, and the updates in the operators' skills.These messages about the new skills may be sent upon successful training of operators or after noticing the operator's performance on the tasks.Regarding the data streams that were already considered in the base case and that must be modified, we find the stream of ''newOrders''.Now, the Controller needs to manage in that stream the data about the user's customization choice that affects the operator's skills needed to manufacture it.All these new and modified information have to be stored in the persistent Historic, which requires some modifications to the database schema.
The View shows the new relevant information.It includes the information on the CWS status in terms of highlycustomized articles under production, the number of articles waiting for production, and information about the tasks assignments to operators.
In a nutshell, the most essential part to address in the DTO after the organization's horizontal integration is the new format of the stream of orders.This has to be addressed in the Controller and Model entities.Without that modification, the DTO loses much of its previous functionality, which needs to be recovered.The next part to address is the new logic for the articles Delivery.The rules and behavior in the Business Process Model and the Delivery ULS have to be updated to avoid raising frequent notifications about outof-order deliveries.By updating only these two aspects, the DTO already recovers minimal functionality, but it offers a degraded service with limited accuracy because it still lacks the representation of important parts in the new organization: the new CWS, the operators skills, and their assigned tasks.
The rest of the developments to evolve the DTO gradually increase their functionality and accuracy until it becomes aligned with the organization.Figure 11 shows a diagram with the single developments and their dependencies separated into two groups.The upper part lists the developments necessary to recover the functionalities that the DTO provided before the organization horizontal integration, while the lower part lists the extensions needed to achieve the new expected functionality.The number of necessary modifications and extensions presented in Figure 11 is large.Actually, 15 modules need to be developed or modified.Despite a large amount of single developments, there is a moderate number of dependencies between developments.Actually, the maximum length of a development dependency path is four: the Business Process Model part that represents the CWS depends on the CWS ULS, which depends on the CWS Model, which depends on the Model of the Order element.This motivates that the used EA Blueprint Pattern can offer a structured and loosely coupled possibility to incrementally evolve the DTO.
The modularity of the proposed EA Blueprint Pattern and its adopted SOA principles benefit its resilience since it avoids creating tight dependencies that may hamper the initial fast recovery of minimal services and the subsequent full evolution towards the optimal version.The monolithic structure of MVC, on the other hand, presents problems when a new type of data is entered into DTO.In this case, its structure must be entirely rectified, which increases the necessary time to recover and, in consequence, reduces its resilience.

D. DTO ADDED VALUES IN THE HORIZONTAL INTEGRATION SCENARIO
A DTO that simulates the organization's expected outcomes along with its horizontal integration would greatly assist the decision-making on whether and how to evolve the organization towards new business activities.The following scenario examines the feasibility of horizontal integration, focusing on a time-based Key Performance Indicator (KPI) [56] called Production Time, which corresponds to the elapsed time between an order being placed and the product being packaged for delivery.Consequently, through this scenario result, managers would be able to know whether, with the current plant resources, it could be manageable to produce a moderate amount of orders of luxury articles without significantly disrupting the regular production of other (normal orders) articles and subsequently keeping the regular customers satisfied.To do so, a simulation is conducted, keeping all resources the same for both cases: one without a luxury production line and the other involving the integration of such a line into the organization's operations.In this situation, the Business Process Model in the DTO is manually parameterized to represent scenarios.For instance, we used that an hour of work is needed by a medium-skilled operator to manufacture a highly-customized unit in the CWS.Simulink models for the evolved Business Process Model are available. 4he DTO monitors the current organization, and it can simulate the expected production time for incoming orders.Figure 12 depicts a sample of the simulation results, offering a visual representation of the DTO's predictive insights for both of the aforementioned cases for the next 20 days.According to the simulation, a total of 210 regular (normal) orders have reached the plant in both cases, with 209 of them (shown on the x-axis) being successfully produced (each order demanding a certain amount of articles of the same variant which is not shown in the figure).The blue dashed line in Figure 12 shows the prediction of production time in the current organization, where there is no horizontal integration in place.On the other hand, the red line in Figure 12 represents the orders' production time prediction where the previous simulation trace is replayed, now evaluating the new process model, including the luxury production line.
Comparing the obtained results reveals that adopting horizontal integration to produce a moderate amount of orders of luxury articles in the organization is expected to bring about an upswing in the orders Production Times.As shown in Figure 12, for some specific order IDs, this increment is higher than others due to the arrival of a highly customized order before those orders.For instance, the most significant divergence is observed in order_id = 184, where the time differential for production reaches 0.779 day or 18.69 hours.However, there are also promising indicators that the plant will not saturate.On average, the integration of the luxury production line is estimated to lead to a slight uptick in production time, specifically by 0.0218 day or 32 minutes.The decision on whether that scenario is profitable enough and whether it would be necessary to acquire new machines or hire more employees is left to the managers.

VII. LESSONS LEARNED A. STRENGTHS AND WEAKNESSES
This section discusses the strengths and weaknesses we have found while applying the EA Blueprint pattern to the DTO development and evolution in our specific use case.
Beyond the specific tangible benefits highlighted in Section VI, when an organization's Enterprise Architecture, in a broader view, aligns with TOGAF [57] standards, the expectations from DTO simulation results facilitate the realization of the Architecture Development Method's (ADM) last four phases: Phase E. Opportunities and Solutions, Phase F. Migration Planning, Phase G. Implementation Governance, and Phase H. Architecture Change Management.The organization's management will be able to examine future possibilities and pick their preferred alternative in terms of expected profit, costs, risk, customer satisfaction, and so on by evaluating multiple opportunities and solutions, getting these results, and comprehending the impact of whatif scenarios.Although the future always remains unknown, the DTO offers the possibility to execute what-if scenarios with part of the information coming from the real plant and part of the information coming from assumptions on the predicted characteristics of the new part of the plant.
Actually, the deviations in the simulation results can be used as a warning sign on the accuracy of the EA models and, therefore, help managers understand that the organization processes do not execute as they believed, which contributes to decreasing the uncertainty level on the organization activities.Moreover, while the organization's digitalization journey is in progress and the DTO is not complete, some parameters are modeled with a fixed value, but they actually depend on the decisions of other parts of the organization.For instance, the Delivery activity for the Transportation process has been assumed to be periodic, but it could be renegotiated, updated, or extra-ordinary deliveries could be agreed upon by Sales Department based on the number of articles ready for delivery.
Regarding our lessons learned during the DTO incremental development, the ULS architecture fosters easy and concurrent extension of the BA, while the extension of the Business Process Model may become more challenging.The reason is that the Transportation and Production processes are subsystems in our current Business Process Model implementation, but they are modeled together in the simulable model.This could cause difficulties in the Version Control System when a large change in the organization requires that several developers modify the Business Process Model.We need to further investigate how to increase the independence in the modeling of each business process while they still remain simulable together to manifest the effects of their concurrency.We have also noticed that, when extending the DTO, several components in the pattern may need to know IDs, addresses, and other information about IoT devices to execute their functionality.Using a registry is a good way to provide such mapping information.Currently, the Registry offers its service to the BA.However, replacing the current registry with a new top-level registry that offers its functionality to all the rest of the elements (BA, IA, and Synchronization) can be beneficial.
A challenge for organizations that are looking to develop their DTO, following the EA Blueprint Pattern, would be related to the effective and efficient design of all components within EA Blueprint Pattern, in the design phase of DTO.This requires a profound understanding of the domain, making it a time-consuming and tough process to establish common ground among diverse stakeholders.To address this challenge, regular meetings with all stakeholders are required to foster a collaborative approach to understand their specific needs and translate them into models.For instance, when dealing with ULS (Section V-B), we explored various alternatives, taking into account factors such as granularity and modularity, and ultimately arriving at six distinct services.This challenge was recurrent across other components like the Evaluation Engine, BPM, Information Architecture, etc.
In the implementation phase of DTO development, a challenge was associated with the Evaluation Engine inside the BA and its Business Process Model components.The challenges derived from the decision to represent the Business Process Model in our illustrative case study using MATLAB/Simulink, with the Simulink simulator serving as the Business Process Model component.Specifically, the manual license activation requirements of this tool enter into a process that does not match with automation [58].
During DTO evolution, the ULS architecture has enabled a parallel and independent evolution of the ULS, but their evolved behavior has a dependency on a previous evolution of the Model.The Business Process Evolution is manual at present since the Synchronization component has not been fully developed.The reason is that the automatic discovery of business processes is one of the big challenges in DTO [34], [59] -for instance, using process mining-and, therefore, the automatic synchronization remains a longer-term research objective.At present, the Synchronization is a case-specific component to develop and does not offer any support to the developers for the automatic modification of the business process.Therefore, we limit the application of the approach to the case where the organization's EA is known.Also, during a period after a DTO evolution where data formats have changed, the DTO may not provide accurate results since the ULS computes the average values that are requested by the Simulation Engine using historical values in a sliding window.This limitation may be overcome by incorporating data co-evolution solutions [60] during the DTO evolution process.We leave this as part of our future research work since, at present, no methodology for DTO evolution has been proposed to accompany the EA Blueprint pattern.

B. PRACTICAL IMPLICATIONS
DTOs often require integration with existing in-place software systems.Organizations can not abandon established infrastructures, considering the extensive investment, expertise, and functionality embedded in legacy software, and initiate DTO implementation from scratch.To this end, organizations should ensure that their legacy software is open and adaptable, allowing for a smooth and effective integration with DTOs.
For an organization to fully leverage the benefits of DTOs, having internal expertise as a DTO specialist is essential.This role would be responsible for DTO implementation/evolution, maintenance, and ensuring its integration into the organizational framework for aligning with the specific needs and objectives of the organization.
A practical challenge our organizational partner faced was the uncertainty about where to find the information they were interested in and how to ensure which of the gathered information, from different sources, was accurate and trustable.Implementing DTO could effectively address this by providing a centralized, trustworthy single source of truth (SSOT).This functionality, in the proposed EA Blueprint Pattern, could be achieved through IA where information is collected and can be visualized, making it easier to understand and utilize.

VIII. THREATS TO VALIDITY
Regarding the validity of the models used in the Business Process Model and the accuracy of the simulation, the pattern does not guarantee their minimum accuracy.The granularity of models matters, and there is a trade-off between the quantity of details to model, the effort to model them, and the relevance of details in the results.For example, while we have used skill matrices as a high-level abstract model of humans, a detailed human digital twin could be defined as a virtual replica of an individual that combines data from diverse sources to offer profound insights into an individual's behavior, preferences, etc, [26] surpassing the simplicity of skill matrices.Results would also lose accuracy if, for instance, the time needed by the Manufacturing workstations to produce a concrete article depended on some internal machine wear status that is not modeled nor monitored.We can state an upper bound for the DTO model's accuracy that corresponds to the validity of the EA models that the organization provides to the DTO developers.
The approach's validity is threatened when it is applied in organizations with business processes based on handling infrequent situations or rare events, e.g., organizations whose business is to control the impact of disasters such as flooding or a pandemic.While the DTO is still useful for what-if scenarios evaluation, the continuous simulations and predictions based on real-time monitored data may not be of great help since the events that are relevant to the main processes happen infrequently.In this case, choosing the traditional model-based simulation for the whatif simulations may save the software development effort for continuous data collection and processing.
As a threat to the EA Blueprint Pattern's external validity, which is related to the evaluation of this pattern [61], we assessed the pattern's applicability to a case study from the industry.Even though the case study is realistic, far from trivial, and involves a variety of criteria and characteristics, this is not enough to claim that the pattern generality is validated.Furthermore, the efficacy of the proposed EA Blueprint Pattern is inherently linked to the foundational EA of an organization.Thus, an organization with a less precise or underdeveloped EA may experience a degradation in the effectiveness of EA Blueprint Pattern.

IX. CONCLUSION AND FUTURE WORKS
The Digital Twin of the Organization (DTO) is a virtual model that represents the elements and connections of an organizational system.It enables continuous assessment and optimization of the organization by providing a holistic picture that can be simulated and analyzed from various perspectives.However, developing and evolving such a DTO poses significant challenges and requires engineering best practices.In this paper, we aimed to address these challenges by leveraging concepts from two well-known disciplines: Enterprise Architecture (EA) and Software Architecture (SA).In particular, we sought to facilitate the development of a flexible and evolvable DTO that is adaptable to organizational changes.To achieve this, we utilized the EA Blueprint Pattern, which serves as an architectural reference for DTO development.We provided detailed implementation guidelines for this pattern based on an industrial case study and thoroughly discussed the necessary efforts required to engineer changes in the physical organization to incorporate them into the DTO.Through this research, we gained valuable insights and lessons learned, which we used to highlight critical tasks, as well as the strengths and weaknesses of creating a flexible and evolvable DTO following the EA Blueprint Pattern.By leveraging the knowledge gained from this study, organizations can better navigate the complexities of DTO development and enhance their ability to adapt to evolving organizational needs.
In future work, we follow two main goals containing both general and technical objectives.On a general level, our focus lies in addressing the concerns outlined in Section VIII.The aim in this domain is to employ the EA Blueprint Pattern for developing DTOs tailored to organizations of varying types and sizes and validate generalizability.Shifting to the technical part, we plan to investigate a detailed design for the automatic Synchronization component in EA Blueprint Pattern that identifies and implements Business process evolution from the information architecture.We also plan to investigate the distributed definition of business process models to facilitate the extension tasks when multiple developers are working on the models.Within the case study, we plan to increment the DTO level of automation to directly incorporate its decisions into the ERP and Daily Management Application, then change the plant production without the currently required human approval or intervention.

FIGURE 1 .
FIGURE 1.A high-level abstract view of the organization.

FIGURE 3 .
FIGURE 3. Production line of the industrial case study -illustrative scenario.

FIGURE 5 .
FIGURE 5. Information architecture of the case-study.

FIGURE 6 .
FIGURE 6. Deployment diagram of the DTO.
presents its view page for the monitored section.It contains a showing the lead time of the last 60 articles in the production line, which automatically updates when articles are delivered.The chart in the predicted section is analogous (not shown in the figure for space

FIGURE 8 .
FIGURE 8. Executive manager view page.

FIGURE 9 .
FIGURE 9. Business process model of a) Transportation, b) Organization vertical integration (production + transportation).

FIGURE 10 .
FIGURE 10.IA changes of DTO in organization horizontal integration.

FIGURE 12 .
FIGURE 12. Production Time comparison for normal orders in as-is DTO (without luxury line -blue dashed plot) and to-be DTO (including luxury line -red plot) Transportation process.DTO can facilitate such decision-making through different whatif scenarios.A representative subset of simulation results is presented in Table1for various conditions.From these simulations, three key metrics are extracted and reported: Average Waiting Time (AW) in the Delivery Queue, Average Number of Waiting Orders or Average Length (AL) in the Delivery Queue, and Average rate of resource Utilization (AU).It is worth noticing that, according to the organization Supply chain and Sales Department, the maximum number of trucks that the organization can afford is four.Furthermore, in terms of delivery service, each truck can perform one delivery per day.As indicated in Table

TABLE 1 .
Simulation results of what-if scenarios for resource allocation of Transportation.