The identified adaptability constructs and their mapping, as listed in Appendix C.2. Adaptability Requirements & Capability Mapping, have been presented to each of the case study participants to validate their applicability and relevance with regards to the selected DBE case. Consequently, through the collected feedback, several refinements have been made with regards to the initial mapping of the constructs. Below, the refined and final overview of the adaptability requirements, capabilities, sub-capabilities and their mapping is presented.
Table 25: Final Adaptability Constructs Mapping
Adaptability Requirements Adaptability Capabilities Adaptability Sub-Capabilities Awareness Environmental Transparency Insights Open Mindset
Open Working Environment Team Support Analytics & Insights Analyses Analytics Customer Feedback Market Scans Sensing Participant Maturity Experience Industry Knowledge Vendor Selection Vendor Specialisation Continuity Prerequisite Alignment Ecosystem Thinking
Holistic Ecosystem Interpretation Participant Framework Alignment Prerequisite Checks Requirement Alignment Requirement Management Task Separation Contingency Management ESCROW Agreements Lifecycle Management Process Monitoring Service-Level Agreements TOGAF Checklists Vendor Autonomous Vendor Selection Integration Strategy Generic Integrations Intelligent Integrations Rate of Change Support Technology Renewal Uptime Management Version Support Flexibility Integration Configuration APIs Componentisation Configurable Code
Connectable Layers Generic Connections
Loosely Coupled Architecture Modularity Overhead Reduction Participant Selection Advanced Partners Experience
Modern Technological Offering On- and Offboarding Support Sourcing Strategy
Scalability
Boarding Support
Partner & Vendor Support Personnel Management Service Management Ecosystem Balancing Event-Driven Architecture Power Balancing Elasticity Cloud Technology Elastic Infrastructure Open Source Tools
Participant Size Management Scalable Frameworks
Self-Organisation
Agility
Agile Frameworks
Minimum Viable Ecosystem (MVE) Short Cycles
Decentralisation
Autonomy
End-to-End Responsibilities End User Thinking
High Performing Teams Governance Decision Maker(s) Governance Thresholds Service Assurance Participant Management Communication Management
Continuously Redefining Relationships Interdependence Management
Interests Alignment Partner Involvement Partner Management
Appendix J: Architecture Development Method Phases
In this section, concise descriptions for each of the phases included in the TOGAF ADM cycle are presented. These descriptions address the primary objectives of each of the phases and, subsequently, cover some essential inputs and outputs. The presented descriptions are based on the specification provided by The Open Group (2018).
J.1. Preliminary Phase
The Preliminary Phase serves to prepare and initiate the necessary activities for the creation of an architecture capability for an organisation. In this phase, it is permitted to tailor TOGAF to accommodate the needs of the involved organisation and define the architectural principles. Summarising, through this phase, architectural principles are defined, a framework definition is
provided, and the project’s goals and drivers are demonstrated.
J.2. Phase A: Architecture Vision
The second phase of the ADM is Architecture Vision. In this phase, the scope of the architecture development initiative should be defined. In addition, it is vital to identify the architecture’s
stakeholders and develop a vision. To proceed to the following phases for the architecture development, approval should be obtained. Lastly, the architectural principles defined in the previous phase can be further refined, as basis for the architecture vision.
J.3. Phase B: Business Architecture
In this phase, the Business Architecture is developed in support of the approved Architecture Vision developed in the previous phases. Subsequently, the baseline and target architecture descriptions should be developed, and a gap analysis must be performed.
J.4. Phase C: Information Systems Architectures
Similar to description provided in Phase B yet focussed on the development of the Information Systems Architecture.
J.5. Phase D: Technology Architecture
Similar to description provided in Phase B yet focussed on the development of the Information Systems Architecture.
J.6. Phase E: Opportunities & Solutions
In this phase, the initial implementation planning is conducted through the determination of
crucial change attributes and implementational constraints. Furthermore, the ‘delivery vehicles’
for the defined architecture are identified, and the gap analysis conducted in the architectural phases is reviewed. Concluding, an architecture roadmap and implementation migration plan should be developed to guide the remaining phases of the architecture development process.
J.7. Phase F: Migration Planning
In this phase, the necessary process for the shift from the Baseline to the Target Architecture is addressed. Primarily, this is achieved by the finalisation of a detailed implementation and migration plan, introduced in the previous phase. This plan furthermore (i.e.) includes resource requirements, availability details and benefit assessments.
J.8. Phase G: Implementation Governance
In short, this phase is conducted for the provision of an architectural oversight of the implementation process. As such, the development and solution deployment work is guided and EA compliance reviews are performed.
J.9. Phase H: Architecture Change Management
In the Architecture Change Management phase, procedures for managing the changes to the new architecture requirements management are established. Furthermore, value realisation processes
are established, and the development process’ risks are managed. Through this phase, the process
of implementing change should be activated.
J.10. ADM Architecture Requirements Management
Being not an immediate part of the architecture development cycle, it is stressed that every stage of the project is based on and validate the defined business requirements. In addition, changed requirements should be identified and processed, and the requirements repository must be kept up to date at all times.
Appendix K: Relationship ArchiMate Extension to Core Layers
In this Section, the proposed graphical notations, and their relationships with elements originating from the ArchiMate® 3.0.1 Specification are visualised and addressed. A viewpoint, illustrating the combined usage of the novel extension is illustrated in Section 6.5.4.
K.1. (Composite) Ecosystem
The proposed element for the (Composite) Ecosystem and a corresponding Ownership relationship can be seen below. These elements can be ideally utilised when numerous similar elements, such as application elements, are visualised next to each other, yet their ‘ownership’
originates both from within the ecosystem and from outside.
Below, the original situation, as modelled in Figure 43, can be seen. In this viewpoint, the usage of a core application component developed in the ecosystem by ecosystem participants is visualised. The figure contains numerous relationships used to visualise through what interfaces each of the applications collects their information and what component is owned by what participant. Nevertheless, using the proposed elements described above, it is believed that this model can be made simpler and less complex.
As visible below, two viewpoints containing the proposed elements have been developed. The first viewpoint illustrates the exact usage of the notation illustrated above and clearly separates
the ecosystem ‘internal’ parts from the application components that are active and owned by several participants in their application layers. This is further substantiated by the ownership
relationships that connect the participant types to their applications that use the ecosystem core data through interfaces.
The first usage of the proposed extension is most useful in case the internal and external
components are grouped. Only in that scenario, a ‘box’ or ‘group’ can be made from the
components. Above, a second utilisation of the extension is illustrated, although identical in its meaning. In this viewpoint, instead of grouping the components by means of their colour, the difference in internal and external component is expressed.
K.2. Ecosystemic Organisation
Another extension that was proposed comprises the taxonomy surrounding the different types of ecosystem participants that were identified. Below, the graphical notation of these elements is illustrated.
A part of the Flexibility viewpoint illustrated in Figure 44 is shown below. It contains several roles involved in the viewpoint and shows the composition of the board of the ecosystem. Nevertheless, from this business layer, it remains challenging to identify which actors and roles are actual clients or external organisations and which of those is, in fact, a participant of the ecosystem. As such, the layers show several customer and platform users alongside some partners of the ecosystem.
However, both types of ‘actors’ are visualised through the same element.
Consequently, several graphical notations have been proposed to mitigate this degree of ambiguity and complexity and clearly differentiate internal from external actors. In the viewpoint below, this is illustrated. From the figure, it becomes immediately visible what the participants of the ecosystem are and how the respective board is formed, in addition to the clients and users of the platform.
K.3. Ecosystem Participants Interests
The final graphical notation that was proposed after the modelling of the DBE adaptability constructs is Participant Interest. From the research, the importance of carefully balancing each of the interests of the ecosystem participants to join and collaborate in an ecosystem became apparent. Consequently, due to a lack of clear modelling support on this matter, a final element was proposed in this research, as illustrated below.
When utilising the core elements currently provided by ArchiMate, it becomes apparent that the modelling of ecosystem participants must go through the usage of the Motivation extension of ArchiMate, as illustrated below. Nevertheless, this leads to increased complexity when using the Motivation extension for its original purposes as well. Also, as visible in this figure, for the roles and actors, the proposed extension has not been used.
In the figure below, the proposed extension is used for modelling the same components. As visible, the complexity of the overall model can be reduced and, in this case, a direct element exists for the modelling of the interests of each participant.