Towards a Digital Transformation Hyper-Framework: The Essential Design Principles and Components of the Initial Prototype

Abstract

To cope with the complexity, the digital transformation of cyber-physical and socio-technology systems demands the utilization of heterogeneous tailorable development environments with dynamic configuring ability and transparent integration of independently developed dedicated frameworks. The essential design principles and component-based architecting of the initial prototype of the digital transformation hyper-framework represent this research target. These principles are derived from the broad scope analysis of digital transformation projects, methods, and tools and are glued to the proposed virtual twin hyper-document. The critical analysis of the digital transformation domain influenced the formulation of five research hypotheses that frame digital transformation of digital transformation, as the second goal of this research article. Armed with a meta-modeling layer, the incremental development of hybrid architecture instances focuses on meta-models and their transformations into functional, interpretable environments. The applicability aspects of the formulated hypothesis are verified throughout the architecture, meta-configuration, and handling of information resources as the essential segments of the initial version of the proposed evolution prototype. The detailed illustration of the horizontal and vertical interoperability of the proposed framework is illustrated by the Life Cycle Modeling component framework that creatively integrates the System, Software, and Operation Engineering aspects of the proposed hyper-framework. The proposed prototype capabilities are discussed in the context of the contemporary digital transformation ecosystem. Specification and development of the additional component frameworks, in compliance with specified generative mechanisms, directing further refinements of the proposed hyper-framework.

1. Introduction

The historical road to digital transformation (DgT) assumes the methodology and technical approaches that tend to remove the virtual line, separating the actual system operation from the operation of its digitally empowered version. Although digital transformation opens the possibilities for innovative approaches to re-engineering products and services, it often represents a disruptive mechanism that questions the existing organizational business models, topology, and well-established operation modes. It dynamically associates a concrete real-world organizational system and its virtual equivalent according to the digital sophistication level of involved, coarse-grained stakeholders appearing as subjects (external or internal active participants) or objects (internal, transformation-prone participants) of a digital transformation endeavor. The Digital Engineering (DE) paradigm establishes an enterprise as a socio-cultural-technical system and transforms the Systems Engineering practices towards technology innovation drivers [1]. It assumes the collaboration/cooperation of all relevant stakeholders over a Digital Engineering Systemic Framework that integrates related resources and activities throughout the entire life cycle of a transformed system. DE goes beyond using specific tools and models and frames a culture of innovation, collaborative problem-solving, and continuous improvement [2]. The current orientation towards DgT additionally originates from the vision of the so-called Great Reset, which addresses the essential domains of global crises and urgent needs for a systematic and sustainable globally synchronized response [3]. Unfortunately, recent research shows that the main obstacles come from the inherent complexity of global systems and different approaches to economic and political perspectives [4].

On the other hand, DigT research has a transdisciplinary nature and relies on the Transdisciplinary Systems Research Methodologies (TSRM). Instead of directly implicating a solution, TSRMs aim to provide the necessary context to understand, evaluate, and argue for or against many possible solutions, narrowing down the solution space to specify the directions for future implementation actions [5]. The uncertainties related to the DigT success do not highly correlate with the existence of a solution but, more significantly, with an implementation failure.

In this research, we first focus on the essential drivers determining the context of digital transformation endeavors. They can be roughly divided into two major groups: the external and the internal drivers.

The most influencing external DT drivers are closely related to recent industrial revolution frameworks starting from the Industry 4.0, 5.0, 6.0, and beyond concepts. Although these concepts emerge from the perceived strategic aims of contemporary cyber-physical (systems specified by the synergic interrelation between its virtual, cyber, representation, and its real/physical appearance) and social-cultural (interrelating the system under consideration, in the context of coexisting cooperative/collaborative heterogeneous system-of-systems) systems, they determine the modern trends in information and communication technologies as the essential supportive DgT mechanisms. Consequently, the DgT endeavors are context-dependent with highly interrelated influencers traditionally perceived as the context-related dimensions (concerning at least political, economic, sociological, legal, ecological, and technological).

In this research, we propose switching from dimensional to system-based complexity, treating an arbitrary influencing dimension as an individual system-of-systems. This generalization aids the global applicability of the proposed hyper-framework.

The most influencing internal DgT drivers emerge from the digital sophistication level of a digitally transformed organizational system. Regarding organizational systems’ digital sophistication, two main aspects direct their ability to cope with digitalization and digital transformation: the strategy (higher-order capabilities) and the operation (low-order capabilities). They rely on available organizational resources to guide their transformation and achieve the desired outcome of a transformed system [6].

The development of universal classification and the general typology of organizational systems concerning their DgT abilities has been mainstream in recent scientific research publications. Being business transformation-driven, it has promoted the Business Process Modeling (BPM) foundation for strategic and operational activities. The BPM framework approach to digital transformation, elaborated in [7], defines six core elements of successful BPM initiatives: Strategic Alignment, Governance, Method, Information Technology, People, and Culture, and proposes a set of corresponding recommendations derived through critical analysis of chosen large companies’ DgT projects. The generic and specific practices embedded in the proposed recommendations have strongly influenced the digital transformation hyper-framework requirements model building. Each core element represents a challenging domain-specific digital transformation dimension that deserves full-scale independent support. Configuration-based integration or orchestration of individual domain-specific elements (components or frameworks) enables need-to-have dynamic binding optimized for the particular transformation context.

Second, the digital transformation of the digital transformation principles, concepts, and methodology deserve further research attention. Current theoretical and practical aspects of DgT concentrate on structural and functional upgrades of an organizational system in the context of external and internal drivers, leaving methodology and supportive tools.

The dynamic nature of DgT justifies the current shift to an agile methodology that better suits iterative or incremental development, continuous delivery, customer-priority-driven collaboration/cooperation, and continuous adaptation to change [8]. On the other hand, DgT is not possible if all systems-wide required resources (produced, disseminated, stored, retrieved, and consumed in any different sense) are not digitally twinned. A digitally transformed system is not a system with embedded IT support (composite pattern). It is a new system (decorator pattern) with a different identity and radically changed structure and behavior. Digital transformation endeavors have shown that exclusively focusing on information technologies (IT) supporting the transformation is not enough to guarantee effective and evolutionary transformation and sustainable operation through the entire life cycle of a transformed system. Information technologies, combined with the strategic importance of ethics, introduce a broader sense of systems value network and split the uncertainties into two main categories: external and internal. In addition to the organization’s decision-making mechanisms, with the digital transformation, the impetus moves to society and industry trends [9].

Considering the previous elaboration, this article formulates two essential goals. The first goal is to define the scope of digital transformation holistically concerning its embedded multidimensionality and multilevel complexity. With the holistic approach, it is possible to define long-term DgT goals and stay focused throughout the entire life cycle of a transformed system.

To cope with the complexity introduced by the holistic approach, it is necessary to address the digital transformation of digital transformation as an engineering challenge. The digital transformation of DgT assumes the specification and development of suitable software tools that support different experts throughout the lifelong DgT. Consequently, the second goal of this research is to propose the essential design, architecting, and components interoperability principles that facilitate an incremental and lean approach to DgT. We claim that a suitable software tool is crucial for the sustainable digital transformation of DgT. The specification and development of such a tool demand the incremental and evolutionary-prototyping approach with meta-model-based, stage-driven, and componentized architecture formulation capable of sustainable DgT support throughout the entire life cycle of cyber-physical and socio-cultural technology systems.

The rest of this article contains five sections. Section 2, Research Scope and Hypothesis Formulation, discusses the research foundation emerging from the analyzed references related to the main DgT drivers, resulting in five research hypotheses determining the development of the DgThyper-framework initial prototype. Section 3, Materials and Methods, elaborates on the research foundation of the stated hypotheses and their importance in the DgT process. Section 4, Results, introduces the main conceptual characteristics of the proposed initial prototype of the DgT hyper-framework, meta-specifications enabling dynamic handling of the different life cycle models, Component-based architecture, Dynamic configuration and reconfiguration of participating components, and the generic support to extendible heterogeneous information resources handling. In Section 5, the Discussion, we elaborate on the appropriateness of the proposed DgT hyper-framework in contemporary standards and tools context. Section 6 contains the concluding remarks and the future research directions.

2. Research Scope and Hypothesis Formulation

While engineering or re-engineering complex systems, the analysis, specification, and modeling activities naturally follow a top-down approach in specifying the global characteristic of a system under consideration as broadly as possible. On the contrary, design, implementation, verification, validation, deployment, and operational activities naturally follow a bottom-up approach that guarantees gradual and leaned transformation that does not jeopardize continuous service delivery.

To correctly determine a research scope, we claim that the holistic approach, although the most challenging, guarantees the appropriate comprehension of the DgT’s inherent complexity and enables the simultaneous formulation and application of a lifelong DgT methodology on macro, mezzo, and micro levels. This research activity is essential in creating the domain foundations that enable other researchers to build different solutions on top of mutually acceptable drivers. According to the general finding elaborated in the Introductory section, the most influencing DgT drivers are closely related to recent industrial revolution frameworks, starting from the three-dimensional Reference Architectural Model Industry 4.0 (RAMI 4.0) and its virtual description of production or service objects with Architecture (interoperability layers), Life Cycle, and Value Stream (differentiating product type and product instances), and Hierarchy (hosting of the production process) dimensions [10] (Figure 1).

Industry 4.0 frames a digital transformation from traditional to cyber-physical systems (CPS) with economic benefits in mind. It utilizes innovative methods and technological means to upgrade the organizational system resources (organizational structure, business models, human resources, processes, and assets). Therefore, the existence of an intelligent enterprise information system aids the continuous rise of the system’s maturity level. That is why developing an assessment tool for digital transformation progress tracking, aligned with the Industry 4.0 drivers, appears mandatory [11].

The following essential technology pillars appear as supportive of digital transformation towards Industry 4.0: Big Data and Analytics, Digital Twins and Simulation, Industrial Internet of Things, Augmented Reality, Autonomous Robots, Horizontal and Vertical Software Integration, Cybersecurity, and Cloud-based Additive Manufacturing [12]. While Industry 4.0 assumes intelligent manufacturing with variable degrees of strategic impacts on business model transformation, the importance of intelligent support in the decision-making process, based on the embedded fuzziness of key Industry 4.0 transformation success factors, emerges [13].

On the other hand, Industry 5.0 returns the essential human values and vital social needs on the DgT scene with the recognized duality of virtual and real-world systems. The transition from Industry 4.0 to Industry 5.0 exhibits a four-dimensional paradigm shift: from information to intelligence, from communication to connectivity, from cyber-physical to cyber-physical-social systems, and from physical automation to knowledge automation [14]. The essential novel technologies associated with the Industry 5.0 paradigm include Blockchain, Autonomous Area Vehicles, 5G and 6G Wireless Networks, Exoskeleton, Mixed Reality, Additive Manufacturing, Artificial Internet of Things, Motion Capture, and Digital Twin [15].

Further propositions concerning novel industry revolutions, like Industry 6.0, represent symbiotic integration of technological transformation, production chain innovation, and social sustainability progression towards the Smart Factory 6.0 paradigm as a sophisticated automated manufacturing facility that integrates emerging technologies and digital systems. Smart Factory 6.0 reflects the upcoming wave of cognitive manufacturing [16] and sublimates IoT, AI, ML, robotics, the Blockchain, big Data Analytics, quantum computing, and cloud computing [17,18,19] technologies.

On the other hand, Industries beyond 6.0, announced by arbitrary predictive visions, introduce significant speculative assumptions reflecting turbulences emerging from the contemporary scientific, educational, technology, and social contexts. In Figure 2, a mind map diagram correlates different inclusive technologies related to discussed paradigms that challenge ongoing and future digital transformation projects.

The existence of the appropriate malty-dimensional strategy that guides the creation and manages the conducting of transformation initiatives represents the foundation for a supportive digital transformation canvas [20]. Figure 3 shows the 11 P’s (Purpose, Process, Partner, Platform, People, Project, Product, Performance, Planet, Protection, and Privacy) of the digital transformation strategy foundation, grouped into four pillars (Strategy, Operation, Value, and Pitfalls), adapted and modeled as a mind map diagram. Besides the component-based definition of DgT processes that may constitute an opened digital transformation life cycle model (ODgTLCM), the embedded, role-profiled stakeholders’ support through software-empowered solutions is essential for effective collaborative/cooperative operational framework development.

The importance of organizational culture and people emphasizes the social and organizational aspects that deserve careful analysis before defining the strategic and operational foundations for evolutionary transformation activities guided by the appropriate methodology selection. The categorization of different organizational cultures enables the grouping of potential type-related enablers and disablers that may affect the entire life cycle of a digitally transformed system [21]. The positive synergy between IT and human resource management (HRM) strategy is empirically recognized as a DgT booster [22] influencing future strategy formulation. The digital human resource management (DHRM) strategy combined with the organizational culture typology results in the integrated typology model [23] that better reflects the nondeterministic nature of socio-technology systems.

The existing literature has thoroughly examined the influence of DgT on external stakeholders with a focus on customer relationships, but the crucial importance of internal stakeholders’ (workforce) digital proficiency appears less rigorously addressed. By fostering a culture of collaboration/cooperation, empowerment, and innovation, organizational systems can raise the collective intelligence and creativity of its internal stakeholders and force them to seize emerging opportunities of fostering individual digital literacy and digital readiness and aid the certainty of the overall DgT process in organizations [24].

With human-operated/used systems, success depends on the minimal distance between problem-domain concepts and activities and their digital equivalents. This distance is expressed through two quite different but often interchangeably used terms: User Interface (UI) and User Experience (UX). User Interface addresses the observable (visible) representations of a product, application, system, service, or function serving the purpose of interaction. It is traditionally recognized as a human–computer interaction (HCI), or more generally, human–machine interaction (HMI) engineering domain that has experienced significant changes in the conceptual foundation throughout the entire development history. Initially, general human cognition factors solely directed the design. Later on, user-centric contextual specializations augmented them. With the inclusion of social and cultural impact mitigation, current professional ethics, and fundamental moral principles, the UI design has evolved into a multidisciplinary endeavor [25]. User Experience (UX) encapsulates UI and relates to the end-user’s subjective perceptions experienced through the entire scenario, directing the use of a product, system, service, or function developed by a particular vendor and disseminated as UI usable objects. The scenario includes pre-use, use, and post-use phases that, joined together, build the subjective feeling of a used object. The proliferation of AI and machine learning technologies has opened novel challenges to UI design, adding profile-based dynamic configuration abilities [26,27], shifting from tangible to intangible interactions [28], and integrating emotional intelligence and interaction optimization supporting highly diverse and personalized interactions [29]. Digital Experience Platforms [30], Generative Artificial Intelligence [31,32], Virtual and Augmented reality paradigms additionally foster the UX foundation [33,34].

With digital transformation, it is essential to rely on life-long integrated support that does not separate systems design, software design, and Information Technology operating infrastructure. The successful DgT never ends. It evolutionarily transforms the actual system and the corresponding digital equivalent according to the built-in ability to adapt and operate in the context of any future transition. That is why the sustainable engineering/re-engineering of cyber-physical and socio-technology systems assumes the existence of powerful, tool-based support applied through the entire life cycle at arbitrary abstraction levels or development stages. Consequently, the Systems Engineering (SysEng), Software Engineering (SwEng), and Operations Engineering (OpEng) domains represent three cornerstones in the DgT process of complex cyber-physical and cyber-social systems. The well-balanced approach to process and product synergy enables the continuous assessment of the engineering process maturity level and quality management, flexible product architecting, and the effective collaboration/cooperation of the real-world (Actual) system and its computer-supported virtual reflection. Agile development emerged as a promising approach based on the higher flexibility, continuous delivery of small, usable systems increments, and better response to change management [35]. With the emphasis on agile framework development, machine learning (ML), and artificial intelligence (AI) support, the automation of routine tasks appears feasible.

As an additional challenge, digitally transformed systems exhibit a dramatic growth in volumes and diversity of generated, stored, retrieved, and processed data. The proliferation of the Internet of Things (IoT) and the paradigm introduce the real-time dimension of acquired and stored data instances uncommon with conventional enterprise systems. They demand more sophisticated Data Engineering efforts for storing and retrieving data and the higher involvement of machine learning (ML) and artificial intelligence (AI) powered framework technologies to support valuable Data Analytics [36]. The Internet of Things (IoT) and the Digital Twin paradigm face standardization problems due to many vendors distributing IoT devices. This diversity causes variations in communication protocols, data models, data exchange formats, and security requirements. Therefore, the development of IoT-based systems ends with a higher effort and, due to the characteristics of individual application domains, results in a lower reusability level and higher extendibility risks [37]. The Web-of-Things (WoT) paradigm enables interoperability over IoT platforms by abstracting WoT technology building blocks through properties, events, and actions [38]. The importance of reliable and trustworthy infrastructure supporting the innovative business ecosystem assumes modern technologies used in fifth-generation (5G) networks through slicing, virtualization, and blockchain [39].

Measuring the success level of DgT faces the potential paradox that the transformation process of a successful system never ends. Everything is transient except change (transformation), which is eternal and eternally drives the system’s transformations. The successful DgT involves complex engineering/re-engineering activities framed by three synergic dimensions: forward-looking (vision, specification, modeling, design, implementation activities, methods, techniques, and platforms), backward-looking (product verification and validation), and downward-looking (process monitoring and control). Coping with the inherent complexity, it demands the utilization of corresponding Digital Transformation Environments (DgTEs) with dynamic configuring ability and transparent integration of independently developed dedicated frameworks [40,41,42].

The essential motivation factors for our research directions originate from the Editor’s Corner section of [43], where the Editor-in-Chief estimates the common-values-motivated drivers that will eliminate previously experienced obstacles and support the future challenges towards a total digital transformation. Consequently, the synergic support for DgT drivers assumes a lined, evolutionary process that requires a radical shift in engineering methodology, organizational culture, and expectations.

All engineering activities exhibit the duality of the engineering process and the engineered product. Model-Based Engineering (MBE) represents an engineering approach resulting in a hyper-model instance that digitally connects different types of engineering artifacts created during various engineering process steps, establishes forward and backward artifacts traceability, and minimizes the risks and effort in change management activities. MBE relies on the formal modeling languages that support specification, modeling, simulation, emulation, design, analysis, testing, validation, and verification of a virtual twin representing the structure and behavior of an engineered system. The underpinned formalisms enable the implementation of tailorable workbenches (software tools) providing generic services such as edition, visualization, transformation, comparison, storage, retrieval, export, import, and additional operations on virtual twin instances.

The accurate qualification of the proposed research with the distinction between multidisciplinary, interdisciplinary, and transdisciplinary approaches is essential. Relying on [44], in the context of this article, we have formulated these differences as follows. An approach is multidisciplinary if a research team concurrently and collaboratively studies the same phenomenon from multiple domains but without the integration of individual insights, thus remaining in the particular phenomenon domain. An approach is interdisciplinary if it is multidisciplinary, and a research team, to better understand a researched concept or phenomenon, integrates individual insights coming from the different disciplines. An approach is transdisciplinary if it augments the research team by the stakeholder groups outside the research team, creating a mix of collaborative and cooperative environments and steps beyond the particular phenomenon domain.

According to findings elaborated in the Introductory and this Sections, DgT correlates different complex issues that naturally belong to multiple scientific or pragmatic domains and thereby inclines to the transdisciplinary category. This classification demands a balanced approach to specification and development of a sustainable hyper-framework leveraging unrestricted cooperative/collaborative set of domain-specific hyper-frameworks.

In the context of this research, we have formulated the following five hypotheses that address scope complexity handling throughout the DgThyper-framework initial prototype. Hypotheses H1 and H2 address scope management, while H3, H4, and H5 address the DgThyper-framework’s generic characteristics.

The first hypothesis (H1) is that an interoperable multi-stage, Digital Twin-based, hyper-framework (framework-of-frameworks) that interrelates Systems Engineering (SysEng), Software Engineering (SwEng), and Operation Engineering (OpEng) features into a collaborative/cooperative specification, development, and operational environment based on an extendible library of tailorable life cycle models (TLCMs) is essential.

The second hypothesis (H2) is that the hyper-framework has to mandatory support the stage-based creation of different configurations, ranging from individual services to system-of-systems, that form the executive infrastructure reflecting the events and services supported by the particular stage, independent of their digitalization status.

The third hypothesis (H3) is that each configuration instance has to represent an executable virtual system capable of real-time emulation (imitate with another system, surrogate), simulation (model-based prediction), operation (traceable running), monitoring (noninvasive and secured), modeling, decision-support mechanism, access (User Interface), and evaluation (User Experience) of configured components structure and behavior.

The fourth hypothesis (H4) is that each component needs to rely on abstract information resource conceptualization, hiding the persistency layer typology from the dynamic resource management layer and establishing the foundations for Data Engineering (DatEng) and Data Analytics (DatAna) features.

The fifth hypothesis (H5) is that the explicit support for H1, H2, H3, and H4 has to be meta-specification driven and integrated into the DgT hyper-framework (DgTHyF). Meta-specifications, interpreted by the strategy pattern with extendible Generative Artificial Intelligence-supported concrete strategies, incline to Industry 6.0 and beyond.

Concerning the fact that even the longest journey starts with a first step and faces the coexistence of different approaches and solutions, we hope the stated hypotheses suitably frame a promising one.

3. Materials and Methods

The proposed set of hypotheses sublimates global dimensions that direct the specification and development of the DgTEs family (a hyper-framework following the generic quintuple helix model adopted from [42] and presented in Figure 4). The individual family members are either fabricated according to the course-grained abstract factory or incrementally built by the orchestration strategy of a generative-builder creation pattern. Concerning their mission, we find a detailed elaboration of underlying foundations mandatory.

3.1. The Foundation of Hypothesis 1 (H1)—Integrated Tailorable Life Cycle Models

The first hypothesis addresses the most challenging aspect of the proposed approach and suggests horizontal and vertical integration of traditionally disjoined domains, Systems Engineering (SysEng), Software Engineering (SwEng), and Operational Engineering (OpEng), determining the research scope. Although Systems Engineering and Software Engineering are sometimes interchangeably used, traditionally, there has been a mutual agreement that it is necessary to distinguish them by the separate life cycle models. Additionally, the complexity of the supportive infrastructure design and operation emerges from the technology-prone engineering disciplines (computer networks and communication) and demands additional expertise to mitigate it.

Contemporary systems, software, and operations engineering methodologies rely on the underpinned process-oriented life cycle models (LCMs) specified, developed, and refined throughout the entire history of engineering. They break down engineering activities into manageable groups, streamlining and systematizing their progression from conception to completion and maintenance, operation to migration, and retirement. Focusing on DgT, a suitable business plan moderating the transformation context apostrophes a lean approach [45]. The incorporation of LCMs in the contemporary context of Model-Based-Systems-Engineering (MBSE) modeling formalisms (SySML) through cross-relating with ISO/IEC/IEEE 15288 standard, results by the proposition of 15288-SySML Grid framework, elaborated in [46], where the authors formulate the guidelines that frame SySML models creation by the 15288-standard specified processes.

The rest of the paragraph elaborates on the impact of the individual multidisciplinary domains on the integrated transdisciplinary model of the DgT life cycle.

3.1.1. The Role of Systems Engineering (SysEng)

The multidisciplinary nature of traditional Systems Engineering (SysEng) emerges from the Systems Engineering Body of Knowledge (SEBoK) [47], particularly the SysEng Foundation Knowledge Areas (KAs) (Systems Fundamentals, The Nature of Systems, Systems Science, Systems Thinking, Representing Systems with Models, and Systems Approach Applied to Engineered Systems), Enterprise Systems Engineering KAs (Creating Value, Resource Optimization, enabling Systems Engineering in the Organization, Kinds of Knowledge used by the Enterprise, Projects Programs and Business), Systems of Systems (SoS) KAs, Human Systems Integration KAs, and the variety of associated standards [48]. They specify SysEng as the overall range of knowledge, skills, competencies, and activities appearing, either on the large-scale (socio-technical systems on a national, international, transnational, or global scale) or locally scaled systems with either technology-driven or scope-driven complexity [49]. In the context of digital transformation, SysEng role is to creatively link the problem and operation domains of the digitally transformed system (real twin) with the corresponding model (virtual twin) that reflects the current DgT context and stage.

The emerging concept of integrated cyber-socio-technology-system-of-systems (CSTSoS) transforms traditional Systems Engineering from a multidisciplinary to a transdisciplinary research domain and thereby justifies our approach to DgT support through the hyper-framework. Additionally, with the proliferation of Artificial Intelligence (AI) and machine learning (ML), the autonomous system emerges as an engineered system that leverages AI algorithms to perform specific tasks with or without human involvement.

Consequently, the role of Systems Engineering in the specification of integrated tailorable life cycle models reflects concepts, methods, and tools that enable the creation of problem and operation domains vision of a virtual twin, aka Systems Engineering Vision, that frames the global aspects of contemporary DgTs. According to the conceptual framework model proposed in [42] (Figure 4), Systems Engineering maps to the Problem and Operation helixes.

3.1.2. The Role of Software Engineering (SwEng)

The multidisciplinary nature of Software Engineering (SwEng) emerges from the Software Engineering Body of Knowledge (SWEBOK) [50] Key Knowledge Areas (KAs) (Software Requirements, Software Design, Software Construction, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, Software Engineering Models and Methods, Software Quality), the Related KAs (Software Engineering Professional Practices, Software Engineering Economics, Computing Fundamentals, Mathematical Fundamentals, and Engineering Fundamentals), and the variety of associated Software Engineering Standards defined by the mainstream standardization organizations (the Institute of Electrical and Electronic Engineers (IEEE), and the International Organization for Standardization (ISO)) [51]. The recent modification of SWEBOK V.3.0 preliminary announced as the SWEBOK V.4.0document is, unfortunately, not publicly available at this research preparation time.

A clear distinction between Software Engineering and software development aids the overall understanding of Model-Driven-Software-Development (MDSD), Model-Driven-Software-Engineering (MDSE), and the associated LCMs that address software process management (Figure 5). Software engineering is generally closer to Systems Engineering, assuming that software artifact represents a system. It perceives software as a final product of interleaved engineering activities with a broader scope than just particular software artifacts development. Consequently, software development closely relates to program development, often called programming methodologies.

According to our experience, the only invariant through the entire history of software development (SD) (aka programming) is the eternal balancing between Algorithm and data complexity, presented as the opposite ends of an exotic scale’s arm (Figure 5a), meaning that to decrease the unmanageable data complexity, reached in a particular programming stage, the only possible solution is to increase the Algorithmic complexity and vice versa. Accordingly, the only invariant throughout the entire history of Software engineering (SE) is the eternal balancing between the Abstraction level and the degree of Reusability, meaning that for the sake of higher Reusability, the abstraction level has to decrease and vice versa. Considering that SE encapsulates SD, the overall complexity emerges from the nonlinear synergy of all four dimensions (Algorithm, Data, Abstraction, and Reusability).

On the other hand, the (Effort, Time) and (Quality, Scope) (Figure 5b) represent the essential invariant dimensions of Software process management. The Effort/Time scale arm interrelates two unavoidable project management assets, Budget (Effort) and Deadline (Time), while the (Quality, Scope) scale arm reflects the individual quality and number of delivered services in a particular project stage. Different assessment contexts may result from the universal obstacles during software project management. Assuming, for example, that the quality is not negotiable (aka mutually agreed), with a fixed deadline and budget, when the project runs into problems, the only possible solution to preserve the fixed ends is to negotiate on decreasing the scope.

Research Software Engineering (RSE) has been announced as an emerging profession that highly depends on the stability of novel computing technologies and their adoption by the other dependent professions [52]. The proliferation of quantum Software Engineering (QSE), quantum software life cycle development, and quantum software reuse methodology add challenging concepts to the future Software Engineering profession. Software architecture and patterns for quantum computing systems [53], Software Engineering issues [54], and quantum communications [55] represent typical examples of challenging domains that will affect Software Engineering’s role in framing future DgTs. The novelty of RSE and QSE represents the challenges to current automatic code generation and automated Software Engineering support through more sophisticated frameworks and tools. Incorporating component-based Software Engineering (CBSE) principles in quantum algorithm automation is proposed in [56] as a promising approach to easier development, testing, and optimization of quantum algorithms for different problem domains.

Consequently, the role of Software Engineering in the specification of integrated tailorable life cycle models reflects the virtual world that emerges from the transformation (refinement) of Systems Engineering Vision into a digital system delegate or digital ecosystem. Existing digital ecosystems consist of complex networks of interconnected and globally distributed software-supported assets (systems), adding new value through the transparent and continuous delivery of the embedded system’s services. According to the conceptual framework model proposed in [42] (Figure 4), Software Engineering maps to the Solution and Implementation helixes.

3.1.3. The Role of Operations Engineering (OpEng)

In the context of this research, Operations Engineering (OpEng) is a multidisciplinary field that utilizes operational thinking and skills to establish, support, optimize, and maintain the technical infrastructure of complex cyber-physical or socio-technology systems and uphold standards and internal documents and procedures that regulate structure and behavior of the operational environment. Generally, it represents system-of-infrastructure-systems (SoIS) that can contribute services to one or more logical system-of-systems that run on top of it. The Logical Systems layer corresponds to the digital ecosystem whose configurations represent a dynamic network of logically interrelated software assets implementing concrete component-system’s services or their surrogates depending on the DgT stage of a concrete component-system. Digital technology infrastructure (DTI) abstractions enable the dynamic and transparent creation and maintenance of configuration networks that hyperlink software assets, communication system assets, and computer infrastructure and create the OpEng infrastructure instances (Figure 6). The current concretization of the abstract DTI concept is a computer network (CN).

The design, installation, maintenance, monitoring, control, and recovery of complex OpEng infrastructure assumes explicit incorporation of nonfunctional requirements concerning the uninterruptable, trustworthy, responsive, and transparent physical operation.

A communication system (CS) is the SoIS that establishes, operates, and maintains personal, local, and global multipath connectivity regardless of the access point technology, transmitting media type, communication protocols, and the nature of disseminated communication objects. Currently, the term communication is a synonym for digital communication. Two digital communication reference models, specified to mitigate the inherent complexity through layered architecture, ISO’s Open Systems Interconnection (ISO-OSI) and TCP/IP, are pillars of classical communication systems. ISO-OSI is a generic protocol-independent standard that guides the communication between the network and the end user. On the other hand, TCP/IP is a concrete communication protocol that facilitates host-to-host connectivity over a communication network and, in a way, represents the implementation of OSI guidelines.

From the DgT framework aspect, it is essential to support the simulation and emulation of the architecture, network protocols, and various communication network parameters [57,58,59]. We claim that due to the higher number of layers, ISO-OSI meta-specification is more suitable for verification purposes (due to better fidelity). Consequently, a TCP/IP meta-specification is better suited for validation and monitoring purposes (due to the direct compliance with the real-time operating context).

The digital communication domain faces a fast development of methods, principles, techniques, and technologies challenging the sustainability of contemporary DgT approaches. The most challenging is the transition from contemporary (3G/4G) to 5G/6G and beyond technologies [60,61], the broader incorporation of Blockchain [62], the impact of the artificial intelligence [63], and the predicted transition from classical to semantic digital communications [64,65].

Computer infrastructure (CI) is the SoIS that physically hosts the related digital ecosystem and represents the most inner responsibility layer of DgT endeavors. A dominant fast development of technologies and the proliferation of novel computing principles (primarily quantum computing) represent the additional challenging aspects of a continuous DgT operation independent of infrastructure reconfiguration. Similarly to the CS, CI determines a cost/performance relation of particular DgT activities. A CI incorporates a broad scope of networked computer assets ranging from the IoT edge and cloud [66] support, globally distributed ledgers [67], computer clusters [68], gateway-isolated private computer networks [69], public computer networks [70], to personal and pervasive computer devices [71]. Currently, a computer network topology is a synonym for CI topology, making a computer network a generic CI but with the extracted CS domain. The mind map scope model of CI topology scope is represented in Figure 7 [72] and frames the potential ranges of DgT.

The course of OpEng originates from the technical infrastructure’s similarity with a human’s vegetative neural system. When it functions, nobody even cares or is conscious of its existence. Proper functioning is intrinsically assumed, while continuous service delivery appears as a spontaneous natural phenomenon from the stakeholder’s angle. When the technical infrastructure fails, it appears from the darkness blamed as it has never functioned.

The role of Operations Engineering in the specification of integrated tailorable life cycle models reflects the impact of executive infrastructure that transparently supports a virtually unlimited digital ecosystem in the uninterruptable delivery of the embedded system’s services. According to the conceptual framework model proposed in [42] (Figure 4), Operations Engineering maps to the Execution helix.

In conclusion, the first hypothesis advocates a need for an interoperable multi-stage, Digital Twin-based, hyper-framework hosting the extendible library of collaborative/cooperative life cycle meta-models that integrate Systems Engineering (SysEng), Software Engineering (SwEng), and Operation Engineering (OpEng) activities. Based on a generic artificial intelligence and the information resources harvested from the persistent data layer, individual meta-models transform into particular DgT context instances.

3.2. The Foundation of Additional Hypotheses (H2 to H5)

The additional hypotheses (H2, H3, H4, and H5) address the minimal basic set of essential principles that guide the proposed DTG hyper-framework (DgTHyF) specification and development and augment the generic approach to DgT life cycle model management.

3.2.1. The Collaboration/Cooperation of Heterogeneous Stage Components (Systems) (H2)

The trade between heterogeneity and homogeneity principles in a leaned approach to engineering complex cyber-physical and socio-technology systems has been in the field for a long time. It addresses the basic principles determining the relations between the whole and its parts. One strategic approach is to homogenize the candidate system before the successful integration. This approach assumes the existence of mutually agreed, value-aided, standardized templates that guide every candidate-component system in transforming its structure and behavior to achieve absolute compliance before the possible integration. Collaboration through the gradual transformation is not possible while cooperation prevails.

Although standards and standardization represent the engineering cornerstones, several suspicious factors exist. In [73], the author discusses homogenization, based on decentralized blockchain oracles distributed ledger technology (DTL), to mitigate the diversities appearing in the industrial data and justify the proposed approach by compatibility, security, and efficiency issues. The Smart City (SC) concept has introduced SC hubs to mitigate the synchronized network flow between the virtual worlds and their physical counterparts [74]. The main problems with homogenization are the higher disruption level and the ultimate change pressure, while the main benefits relate to the organizational, structural, procedural, and technological unification that may, in the end, decrease the overall system’s complexity.

The other strategic approach assumes the parallel existence of diverse collaborating/cooperating systems that retain internal mechanisms and comply only through well-defined interfaces, favoring the coexistence of heterogeneous component systems. This strategy is less stress-prone for the component systems but demands more complex interoperability support, usually delegated to the engineering segment of DgT endeavors. Instead of the instant transformation pressures, an accustomed operating environment supports a lined approach and enables uninterrupted operations but may indefinitely preserve the internal status quo. Consequently, the overall system’s complexity may significantly arise, causing the transfer of responsibilities almost exclusively to the technology infrastructure. The role and the significance of systems, software, and operational engineering professionals prevail and justify their effort and expertise to encapsulate the DgT risks. Although demanding, we find the heterogeneity more realistic for a long-range leaned DgT of arbitrary complex cyber-physical or socio-technology systems that highly stimulate novel engineering methods, techniques, and tools specification and development. The role and novel representation of Distributed Computing Continuum (DCC), beyond the traditional computer architecture, assumes the highest possible heterogeneity level of the participating devices or networks and challenging models [75,76]. Distributed task allocation represents another research domain challenged by the collaboration/cooperation of heterogeneous end-point devices [77].

The previous elaboration on DgT fundamentals advocates the lean approach as a foundation of a sustainable DgT life cycle model. Consequently, through the entire life cycle, the transformed system contains the architectural components (parts) that are in one of the following stages: not transformed (performing in a problem domain without digital support), in transition (digital transformation is in progress), transformed (digitally supported, verified, and validated), deployed (installed and usable), operational with refactoring abilities (used with user experience feedback abilities), and occasionally temporarily or permanently removed. The heterogeneity of this form, complexity, and structure represents one of the most challenging interoperability obstacles to continuous service delivery through the entire DgT life cycle.

3.2.2. The Executable Virtualization Ability (H3)

The efficient and effective use of digital technology infrastructure is essential in current enterprise architectures. Two diverse approaches that aid the transparency of software services in a heterogeneous environment are commonly available: containerization and virtualization.

Containers are portable, stand-alone executable units that pack together software asset and all the necessary resources to enable independent running in the arbitrary computer environments. The Docker is currently the most widely utilized containerization tool, while the Kubernetes actually represents an industry standard for containers orchestration. The representative container applications include building the Microservice architectures, continuous integration, continuous deployment, hybrid and multi cloud configuration support, the deployment of artificial intelligence and machine learning applications, and coupling the large language models (LLMs) with the related Generative Artificial Intelligence mechanisms [78].

On the other hand, virtualization assumes replacing the physical computers with software-defined virtual machines (VMs), operated under the control of the VMs manager (hypervisor), enabling the automatic creation of service management workflows by superposing the current configuration-instance portfolio and the current user’s profile (service policies) [79]. While VM virtualizes the hosting machine resources, container virtualizes the hosted operating system. Both mechanisms support the deployment of software services over digital technology infrastructure and enable the run-time separation of the logical operation context (virtual twin) and the physical execution context (physical twin).

Hypothesis 3 (H3) states that each configuration instance has to be an executable virtual entity capable of real-time emulation (imitate with another system, surrogate), simulation (model-based prediction), operation (traceable running), monitoring (noninvasive and secured), modeling, decision-support mechanism, access (User Interface), and evaluation (User Experience) of configured components structure and behavior. The DgTHyF needs to support an open set of modeling and simulation technologies and tools that, packed with the software asset, enable the transparent execution over the entire digital technology infrastructure. The contemporary representative repertoire of modeling techniques and simulation tools, adapted from [80], is presented in Figure 8.

3.2.3. Hiding the Data-Layer Complexity (H4)

Digitally transformed systems exhibit a dramatic growth in volumes and diversity of generated, stored, retrieved, and processed data harvested from different sources and preserved in a distributed data repository (a collection of multiple interconnected data chunks, physically spread across hosting computer network infrastructure, forming a complex data layer). The emerging complexity demands efficient handling and represents one of the most challenging aspects of successful software development.

Engineering rationality prefers data layer homogeneity with uniformity (All nodes utilize the same DBMS software and possess identical database schemas), consistency (Changes made to the database on one node are automatically propagated to other nodes, ensuring data consistency), and simplicity (The same DBMS software exists throughout the data layer) as the primary beneficial features.

Unfortunately, the evolution of digitalization in cyber-physical-socio-technology systems has led to natural heterogeneity (the coexistence of structured, semi-structured, and unstructured data). Heterogeneous data repositories are characterized by flexibility (nodes can employ different DBMS software, such as distributed file system, relational databases, document-oriented, key-value, column-based, and graph-oriented databases), schema mapping (heterogeneous databases necessitate mapping between different schemas to ensure interoperability between nodes), and data transformation (data might need to be transformed or translated between different formats or encodings to maintain consistency). The ability to process and analyze heterogeneous data provides valuable insights, predictive analytics, and decision making, which is crucial in the era of Big Data [81]. The usual approach to cope with the data layer complexity emerging from intensive heterogeneity assumes service-directed modular design (data chunks are clustered according to the specific service needs with possible increases in data redundancy but reducing service dependency), robust data normalization (data is stored in a logical manner optimizing the logical data layer), the efficient management of application programming interfaces (APIs) through API gateways, wrapping data with the additional abstract layers (serving as data encapsulation façade), the use of machine learning algorithms to detect query patterns and enable automatic query optimization, the use of AI for the advanced optimizations (performance monitoring, predictive refactoring, and mitigating the risks related to the data layer change propagation), and providing real-time feedback from physical date layer (physical twin) to logical data layer (data models aka virtual twin) to enable their dynamic synchronization.

The role of the data abstraction layer (DAL) is to create a data virtualization that simplifies repository handling by providing a unique, higher abstraction layer that mitigates the concrete implementation details [82]. It is crucial in software development due to the higher usability and functionality resulting from the creation of a logical data access layer, which ultimately fosters the scalability and maintainability of software systems and can ensure a smooth implementation. When implementing DAL, the frameworks and tools used for a particular project engineering necessitate the highest possible alignment with the project requirements.

DAL usually contains two generic concepts: a generic interface with two methods (load and store) that hide technically diverse repository features from the referencing services, thereby enhancing the usability and functionality of the encapsulated data layer, and the abstract model of the generic data chunk, addressed in this research as an abstract information resource (AIR) generalized by the meta-specification of a large data object (LDO). From the architecture aspect, it is essential to separate the external repository from the internal dynamic storing and presentation layers. This separation hides the particular characteristics of a persistent LDO form from its operational counterparts.

The computational complexity of high-dimensional LDO processing is the main obstacle for real-time or near-real-time applications. Consequently, reducing the complexity of multidimensional LDOs is one of the highly promising approaches to system/problem simplification. As less complex LDOs are easy to navigate, explore, visualize, and analyze in different contexts, they are more suitable for effective machine learning.

Hypothesis 4 (H4) states that the natural heterogeneity of the underlying data layer demands a more sophisticated approach to Data Engineering (DatEng) and Data Analytics (DatAna). Consequently, the use of the abstract information resource concept (AIR) as a Large Data Object’s (LDO) generalization is fully justified. Raising the abstraction level in such a way has a direct payback in hiding the data-layer implementation details emerging from the heterogeneous associations of arbitrary complex LDOs [41].

3.2.4. Meta-Specification-Driven Generative Support (H5)

DgT tools that support creativity in forward-looking and critical thinking in backward-chaining cognition are highly desirable in complex engineering/re-engineering endeavors. With the proposed trinity of Systems, Software, and Operations Engineering, the DgTHyF needs to creatively combine distinct features and reduce possible redundancy while integrating traditionally separated development environments. Every trinity component relies on specification-based engineering (SBE) principles, with specification as a generic document that more or less formally defines relevant aspects of an engineered system at an arbitrary detailed level. Traditionally, even the programming code represents the most detailed specification of the underpinning problem’s solution.

Consequently, model-driven engineering (MDE) is a form of SBE where the specification document emerges from the modeling practices. Modeling is traditionally recognized as a domain complexity mitigation approach, while models (the products of modeling activities) represent scaled multimedia specifications (virtual twins) of problem domain concepts (real twins) [42]. Meta-specification is a specification of a specification. It raises the abstraction level of a concrete specification to mitigate the complexity further and establishes the foundations for the automatic generation of context-dependent specification instances [40,41]. Both concepts (specification and meta-specification) are documents with generative potentials that demand collaborative document management tools. They are digital platforms that enable real-time collaboration/cooperation among stakeholders working on shared documents of arbitrary granularity and abstraction levels [83].

Hypothesis 5 (H5) states that the explicit support for H1, H2, H3, and H4 has to be a meta-specification driven and integrated into the DgT hyper-framework (DgTHyF). To mitigate the domain heterogeneity and support domain adaptability, meta-specification-driven dynamic building and biding of the generic DgTHyF features are mandatory. The shared document instance defines a virtual twin’s content, with time and modal markers, representing a hyper-document that interrelates meta-specifications (Life Cycle, Architecture, Component, Component configuration, data abstraction layer, and Presentation layer), corresponding derived specifications, and real-time execution instances. Meta-specifications, interpreted by the strategy pattern with extendible Generative Artificial Intelligence-supported concrete strategies, incline to Industry 6.0 and beyond.

4. Results

This research combines Digital Twinning, multidimensional cognition processes, and Systems Engineering, Software Engineering, and operational engineering methodology to build an extendable, generic, configurable, and usable hyper-framework prototype that supports the sustainable digital transformation of cyber-physical and socio-technology systems DgT through the entire life cycle of the transformed system. In our previously published research [42], we have proposed the conceptual framework for Digital Twin (DT) verification and validation, based on a quintuple helix model, as a paradigm for DgT hyper-framework (DgTHyF) prototype specification and development.

Due to its inherent complexity, we propose the evolution prototyping, meta-specification-based generation of hyper-document specification instances (models and code), and continuous integration and deployment support through a stage model of composing component systems. We claim that DgTHyF specification, modeling, and prototyping, compliant with the hypotheses (H1-H5), enable its incremental development, tailoring, verification, deployment, and operational validation in the lined agile DgT process.

Currently, there exists a large family of commercially available Integrated Development Environments (IDEs) representing interactive, GUI (Graphical Users Interface)-oriented event-driven, software systems commonly supporting multiple programming languages, syntax-sensitive code editing, compiler or interpreter support, symbolic debugger, extendible library support, code search, version control, and code integration features. The proposed DgThyper-framework (DgTHyF) is a prototype software system with configuration-based architecture, components, and service orchestration abilities. It comprises the extendible set of component frameworks, each supporting distinct closed systems (closed for modification but opened for extension) with internally extendible functionality.

Following the Model-based-engineering approach, we have defined a starting hyper-document represented as the AstahProfessional modeling tool component-based project suite (Figure 9).

It is composed of the extendible collection of underpinned hyper-documents that represent either atomic-grained (non-hyper-linked) or course-grained (hyper-linked) large data objects representing the specifications (models) of corresponding building blocks. The overall project suite represents a hyper-graph (a graph whose nodes are graphs) and is a starting meta-specification (meta-model) of the proposed DgTHyF, which we address as a DgTHyF generic virtual twin. Its highest granulation level is presented in Figure 9a and augmented by the package-contained example of the DgTHyF generalized architecture model (Figure 9b) as an object-oriented model (class diagram—Figure 9c). The initial repertoire of General Purpose Components (Figure 9d) and Life Cycle Model Handler Domain-Specific Component (Figure 9e) represent the highest granularity specification of the corresponding hyper-document model.

The Generic Framework is a recursively orchestrated abstract Hyper Framework, at the highest hierarchy level of the generic architecture meta-model, that specifies common structural and behavioral characteristics of an arbitrary hyper-framework. The DgTHyF Application Prototype is a Generic Framework that aggregates an open set of abstract DgTHyF Component abstractions that either belong to the General Purpose Components Registry (a configuration of abstract General Purpose Component specializations) or Domain-Specific Components Registry (a configuration of abstract Domain Specific Component specializations) and forms a dynamic Architecture configuration. Each Domain Package is a stand-alone container composed of DSC Meta handler (Domain-Specific Component Meta-Handler) supporting the dynamic generation of domain-specific context and configuration and an arbitrary domain-specific component that encapsulates domain-specific services, in this version represented by a Life Cycle Model Handler (LCM Handler).

The generic architecture specification (Figure 10) serves as a referent meta-model for the automatic generation of the initial prototype-shell code (Figure 11), thereby illustrating the whole spectrum of features announced by the stated hypotheses (H1–H5).

The Generic Framework abstraction encapsulates common structural and behavioral characteristics related to the recursive hyper-framework meta-model. DgTHyF Application Prototype and each DgTHyF Component represent distinct specializations that enable the creation of arbitrary architectures and their versions (configurations), managed by the Integration Component’s Configuration Handler. Each General Purpose Handler component implements the Meta Specification Services interface. General purpose Components form a reusable pool, while Domain-Specific Components extend it dynamically throughout the DomainSpecificPackages.

The specified meta-model integrates the following design patterns: Proxy (Generic Framework) and Singleton (Hyper Framework auto-reflection association), Abstract Factory (DIGTHyF Components), and Composite Pattern (DGT Application Prototype), and Command Pattern (Meta Specification Services Interface with the corresponding concrete components as implementers).

4.1. The Multi-Stage Hyper-Framework Requirements Model

The high-level generic requirements model of the proposed DgTHyF defines a universal proto-iterative starting point of an arbitrary evolution prototype as an interactive, event-driven, graphical users interface (GUI)-oriented, component-based, meta-specification configurable, software tool with flexible, profile-based, architecting features (Figure 12), designated as a hyper-document node 00-01-DGRHyF Requirements Model (see Figure 12a).

In the current stage, the generic requirements (Figure 12a) are composed of three specification documents models: 00_DG_Domain-related requirements (specifies the highest level DgT domain-related (Systems) requirements, Figure 12—(1)—with detailed representation shown in Figure 12), 01_GenericAssetRequirements (the highest level software requirements, Figure 12—(2)—with detailed representation shown in Figure 13), and further hyper document layer 02_DecisionSupportMechanisms (specifies component’s internal decision-making mechanisms, Figure 12—(3)—with detailed representation shown in Figure 13).

Specified systems requirements (Figure 13) correspond to the Systems Engineering virtual twin at the highest abstraction level and split overall responsibilities into two hierarchies: the Strategy Method and Expertise (01.01) and Technology Operation Sustainability (01.02).

They are mainly process oriented. The DgT Framework requirements model (Figure 14) is a virtual twin corresponding to the highest abstraction level of a product specification belonging to the Software Engineering solution domain. On the other hand, the Decision Support requirements model corresponds to the virtual twin that specifies the internal control mechanisms of arbitrary component decision-making core related to the highest level of the implementation domain (Figure 15).

4.2. The DgTHyF Generic Behavioral Model

Based on Hypothesis 3 (H3), through the entire life cycle, the digitally transformed system contains architectural building blocks (component/service/microservice) that are in one of the following stages: not transformed (performing in a problem domain without digital support), in transition (digital transformation is in progress), transformed (digitally supported, verified, and validated), deployed (installed and usable), operational with refactoring abilities (used with user experience feedback abilities), and occasionally temporarily (disabled) or permanently removed (retired).

The DgTHyF generic behavioral model, presented as a UML state diagram (AstahProfessional modeling tool), is shown in Figure 16.

These components are dynamically configured and support the intended services in a technically possible and time-dependent manner or form. Depending on the particular component service stage, the transformation activities belong to the operational, engineering, or re-engineering category.

Consequently, the service discovery mechanism demands the establishment of traceable navigation paths reflecting the overall architecture. It assumes the creation and continuous maintenance of multi-layered hyper-structures of self-contained autonomous systems with arbitrary granularity levels (from atomicgrained to globallygrained), exclusively interrelated through interfacing points that enable the dynamic creation of horizontal (connecting different type ingredients) and vertical (connecting same type ingredients) associations.

On the other hand, the complexity mitigation of the service invocation mechanism assumes the stage-based polymorphism reduced to the meta-invocation defined by the statement:

with (context-bb: Building Block; current-stage: Stage; invoke-se: Service)

that decuples the service invoker from the service discovery mechanism and service provider Building Block’s context.

Figure 17 defines a meta-object-specification model corresponding to the specified generic behavioral model (Figure 16) as a further model refinement towards the executable specification (a programming code).

In the stated model, the Chain Of Responsibility design pattern specifies Building Block service invocation, while Context and abstract Stage, joined by the Stage Package containing the concrete stages according to the behavioral mode (Figure 16), represent a State Pattern.

The sample Java code, generated from the OOM class model, extracted from the further refinements of the behavioral model’s transformation to Java programming code, is presented in Figure 18.

Currently, various formalisms rely on transforming behavioral models into corresponding analytical models. While these formalisms offer flexibility due to the range of available analytical languages and notations, they introduce additional complexity and require proper handling. The interoperability of different tools, general-purpose or domain-specific languages, and integrated production environments supporting simulations is one of the most challenging issues for further research and engineering directions. If we define software and technical infrastructure as systems, it is possible to raise the abstraction level and concatenate similarities in the higher abstract concept whose specializations redefine or add specific state and behavior refinements.

4.3. The DigT Life Cycle Model Handling Component

According to Hypothesis 1 (H1), the DgT Life Cycle Model (DgTLCM) Handling Component represents a central domain-specific DgTHyF component for this article’s mission. The DgTLCM is a hyper-document that sublimates conceptual, logical, and physical repository models serving as meta-specifications canvas for data-driven generation of arbitrary DgTLCM instances.

The model specification development environment used for data layer modeling illustrates interoperable collaboration/cooperation (Figure 19) between the Astah Professional UML2 modeling tool that hosts Object-Oriented Models and the Power Designer Data Architect Version 16.1 modeling tool that hosts data layer models in platform-independent form (conceptual and logical data layer model Figure 20) and platform-dependent specialization (physical model Figure 21) with MySQL relation database as a hosting database server (Appendix A—Sample Data Definition Language script).

Conceptually, the presented model possesses three of four Meta-Object Facility (MOF) data layer abstraction levels (meta, model, and instance-configuration) represented with related ER sub-models, with naming convention related to the data abstraction layer (DAL) specification discussed in Section 2.

The multidimensional data models rely on the data modeling principle of the deepest possible primary key propagation, which better suites database queering purposes and fosters model-based transformation from relational to arbitrary NoSQL counterparts (document, graph, column table, or key-value) due to the substitution of multilevel joins by embedded selections exclusively with the primary key, from bottom layer to higher layers perspective. In such a model, all queries start on the lowest hierarchy level where all related primary keys exist as composite primary identifiers (see Figure 21, Used Meta Activity Graph table example).

5. Discussion and Related Work

As pointed out in the previous elaboration on a digital transformation natural transdisciplinary, it claims that the uncertainties affecting the final success do not strongly correlate with the existence of a solution but, more significantly, with the implementation failures.

Consequently, this DgT research aims to provide the necessary context to understand, evaluate, and argue for or against many possible solutions and thereby demands an expertise-empowered software tool supporting the DgT simulation-based decision-making compliant with the run-time claims feedback related to the DgT activities, either belonging to the system under consideration internal influencers, or context-related impacts of the collaborative/cooperative external system-of-systems drivers, and vice-versa.

The DgTHyF initial meta-specifications frame the development of a software-supported development environment (tool) with generic impacts on future DgT endeavors. Such a tool has to support a wide range of problem domains and sustain through the entire life cycle of digitally transformed systems. Due to its inherent trinity, the superimposing of traditional Systems Engineering, Software Engineering, and Operation Engineering Life Cycle models [84,85] appear as the ultimate starting point for DgTHyF verification and validation purposes (Hypothesis H1). The Collaboration/Cooperation of heterogeneous stage components (systems) (Hypothesis H2), Executable Virtualization Ability (Hypothesis H3), hiding the data-layer complexity (Hypothesis H4), and the overall meta-specification-based generativity (Hypothesis H5) creatively incorporated in the specification and modeling of the extendible integrated Life Cycle Model management domain-specific DgTHyF component (Section 3). The DgTHyF is not a replacement for the existing or future incoming frameworks but a self-extendible hub for an open set of collaborative frameworks.

Software development environments of arbitrary kinds are usually targeted in model-driven software development (MDSD) or model-based system engineering (MBSE) suits. They are closely related to the general architecture modeling paradigms and constitute the core of different contemporary Enterprise Architecture frameworks (EAF).

In the proposed approach, the DgT project is specified by a model-based hyper-document (currently defined as an Astah Professional project) supporting the open, collaborative interoperability with arbitrary external tools (currently illustrated with the Power Designer Data Architect modeling tool hyper-linking) that may be either containerized or virtualized over the underlining digital technology infrastructure.

The specified hyper-document enables the integration of arbitrary collections of virtual twins, representing context-related external (ecosystem relevant) and content-related internal (internal organizational structure) system-of-systems configurations. The physical counterpart relates to the real-time synchronization between the tangible parts of the underpinning system-of-systems and the virtual twin instances representing the foundation of the working prototype. This elaboration completes the cyber-physical aspects of the supportive hyper-framework.

Socio-cultural-technology reflections emerge throughout the dynamic synergy of the targeted system’s internal configurations and the externally configured cooperative/collaborative systems representing the overall digital transformation ecosystem.

The specific hypothesis, H3, and the related behavioral and structural model described in Section 4.2, the DgTHyFgeneric behavioral model, digital transformation stages and explicitly support service discovery mechanism, conscious of the collaboration and cooperation of the participating systems being at different digital transformation stages, enable specification, modeling, and deployment of ad libitum configured hyper-systems.

Consequently, we direct the discussion and related work analysis to the conceptual or software-empowered hyper-document-based collaborative frameworks framed by the specified five hypotheses in the contemporary DgT context.

The elaborated DgTHyF is modeled and specified as an evolution prototype of heterogeneous collaborative component frameworks belonging to an ontology-based or tool-based group of EAFs (Figure 22), integrated over a virtual twin hyper-document instance.

The selected EAFs belong to three general groups: ontology-based, model-based, and tool-based EAFs. Although a more detailed discussion of all available and selected frameworks is far beyond the scope of this article, it is necessary to highlight their core foundations.

The ontology-based group has a long development tradition focused on the fundamental principles and practices that form the boundaries of the addressed problem domain and serve as a starting point for concept clarification purposes. These specifications form the data structure skeleton of software tools supporting systems, software, and operations engineering activities. The most referenced ontology-based EAF are: the Zachman Framework (ZF) [86], the Open Group Architecture Framework (TOGAF) [87], the Federal Enterprise Architecture Framework (FEAF) [88], the Defense-oriented group of frameworks (US Department of Defense—DoDAF [89], NATO Architecture Framework—NAF [90], and International Standards Organization on EAF [91]), the Capability Maturity Model Integrated (CMMI) Framework [92], the International Council On Systems Engineering (INCOSE) framework discussed in the introductory section [1], and the Skills Framework for the Information Age (SFIA) [93].

The model-based EAF group directly impacts the current stage of DgTHyF regarding its inherent model-based orientation. It is used similarly as an ontology-based group but with extensive augmentation by the formal modeling languages. We have solely appointed the Object Management Group (OMG) [94] due to its relevancy, with the most referenced members being the Unified Modeling Language (UML2), Systems Markup Language (SySML), Business Process Modeling (BPM+), Information Exchange Framework (IEF), Meta-Object Facility Framework (MOF), and the Unified Architecture Framework (UAF).

The selected subset of tool-based EAFs splits into three main groups. First, the Ontology-supported EAF tools (the Sparx System EAF [95] and SAP LenIX [96], with dominantly TOGAF and FEAF ontology foundation). The second, general agile (the Scaled Agile Framework [97] heavy-weight tool), and the third, Scrum-based EAF light-weight tools group (the Large Scale Scrum (LeSS) [98], Nexus [99], Scrum@Scale [100], and the Enterprise Scrum [101]) (see Figure 22).

The DgTHyF is a software-empowered heterogeneous hub promoting interoperability as an essential requirement. Although cooperative interoperability is usually assumed while developing tool-based frameworks, we predict the collaborative interoperability approach as a further universal direction.

Consequently, the briefly discussed sample context justifies the proposed DgTHyF’s fundamental hypothesis as fostering mechanisms that place the collaborative heterogeneity in the core of arbitrary DigT context.

6. Conclusions

The addressed research topic frames a complex System-of-Systems specification, modeling, development, verification, validation, deployment, refactoring, and retirement life-long DgT support, with component systems persisting at arbitrary advanced DigT stages.

This article addresses two general challenging aspects of DgT scope management and software-supported incremental transformations. The research methodology approach assumes that the DgT scope has to be as wide as comprehendible to create a big picture, hyper-document-based representation of the virtual twin mitigating DgT process management task (Section 1—Introduction and Section 2—Research Content and Hypothesis). The cognition-based foundation of the proposed context is compliant with estimated Industries 4.0, 5.0, 6.0, and current-beyond challenges.

Additionally, we claim that horizontal and vertical structural and behavioral integration of a digitally transformed system demands DgThyper-framework supporting the digital transformation of future DgT endeavors. The essential design principles and components of the initial DgTHyF software tool prototype are expressed through five stated hypotheses (H1-H5) that define an extendible multidimensional context for systems-thinking-principles-based critical analysis and creative reasoning as the root of all innovativeness in process specification and product generation. Section 3, Materials and Methods, elaborates on the foundations and roles of individually specified hypotheses in creating the initial DgTHyF prototype.

In Section 4, Results, we illustrate the horizontal and vertical interoperability aspects of DgTHyF, supported by the Astah Professional Project hyper-document, and the macro, mezzo, and micro aspects of the initial prototype specification and development in compliance with the five stated hypotheses. Consequently, this practical verification assured us that the stated principles justify the operational applicability of the proposed hyper-framework.

In Section 6, Discussion and Related Work, we emphasize the collaborative potentials of mainstream meta-specifications, related hypotheses, and further perspectives (beyond the current stage).

In conclusion, the inherent complexity of digital transformation demands the development of appropriate mitigation frameworks. With this article, we have made an initial hyper-scratch of the underlying problem and hope the results presented will inspire a broader initiative for further research endeavors. The specified approach has at least three limitations that need to be appointed.

First, the applicability of stated principles and practice demands expert knowledge and the appropriate systems, software, and operational engineering competencies. Gaining them is a lifelong upgrading process that significantly lowers the number of efficient and effective DgT participating stakeholders.

Second, the expertise is not free of prejudices and reluctance to hot topics and approaches that go beyond the current comprehension. With DgTHyF, we do not intend to replace domain experts but to support them in lifelong DgT transformation of complex cyber-physical and socio-technology systems, supposing they are open for novelties.

Third, the DgT ecosystem with the available software-supported DgT tools demands additional expertise in the interoperability features of independently developed legacy, free, or open-source representatives. Integrating them at the appropriate levels of the proposed hyper-framework and keeping them operational despite further decentralized vendor enhancements is a mission-critical activity.

In the context of this article, the future research directions include but are not restricted to the full application support for the core DgTHyF principles explicated through the stated hypotheses (H1–H5), the formation of heterogeneous hyper-data repository transparently supporting the relational, document-oriented, graph-oriented, distributed file-system-oriented, column-table-oriented, and key-value-oriented counterparts interoperated over the meta-specification-driven data abstraction layer (DAL) support, and further spreading of the underlining functionality. One of the most ambitious further directions is making the foundation for the Open Source Community Project—Open Source Digital Transformation Hyper-Framework (OSDgTHyF).