Integrating TOGAF ADM, ArchiMate, and Scrum to Align Enterprise Architecture with Agile Software Delivery: A Case Study of a Digital Learning SME

1. Introduction

Digital transformation changes not only an organization’s technology portfolio but also its operating model, decision rights, products, and capability configuration. Research therefore increasingly treats transformation as an organizational process rather than a sequence of isolated IT projects [1,2,3]. Small and medium-sized enterprises (SMEs) face the same need for coherent transformation as large organizations, but they operate with more limited specialist capacity, less formal governance, and stronger dependence on a small number of digital platforms [4,5]. These conditions make architectural coordination important while simultaneously reducing the amount of architecture work that can be sustained.

Enterprise architecture (EA) addresses the structure and evolution of business capabilities, processes, information, applications, and technologies. Its core promise is to create a shared representation of an enterprise and to connect strategic intent with implementation decisions [6,7,8,9,10]. Empirical studies associate EA with improved decision quality, transformation coordination, transparency, reuse, and platform development, but they also show that value is contingent on service quality, governance, stakeholder participation, and practical use in projects [10,11,12,13,14,15,16,17]. An EA function that produces comprehensive models without influencing delivery can become a documentation overhead; a delivery organization without architectural coordination can accumulate local optimization, duplicated capabilities, inconsistent data, and technical debt.

TOGAF provides a broad architecture framework and the Architecture Development Method (ADM), while ArchiMate provides a modeling language for representing motivation, strategy, business, application, technology, physical, and implementation concepts [18,19,20,21,22]. Neither standard requires a waterfall implementation. Both are intended to be tailored. Nevertheless, the visible breadth of the standards can encourage organizations to treat architecture as a front-loaded phase or to generate more artifacts than a small organization can maintain.

Scrum addresses a different problem. It creates an empirical control loop for delivering value through a Product Backlog, time-boxed Sprints, inspection, and adaptation [23,24]. The wider agile literature documents gains in responsiveness and stakeholder learning, but it also identifies recurring challenges involving requirements coordination, cross-team dependencies, documentation, governance, and alignment with organizational functions outside the development team [25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40]. These challenges become material when a product depends on several applications, data stores, infrastructure services, suppliers, and business capabilities.

Software architecture research has long distinguished architecture from a one-time design document. Architecture expresses consequential structures and decisions, requires communication across stakeholder viewpoints, and evolves with implementation evidence [41,42,43,44,45]. Studies of agile architecture emphasize a balance between intentional architecture and emergent design, with sufficient up-front reasoning to manage risk without freezing the solution prematurely [46,47,48]. Documentation must be useful and maintainable [49], architectural knowledge must be connected to decisions [50,51], and modeling must support rather than replace engineering work [52,53,54]. Recent model-based studies in Software demonstrate that an explicitly defined process can connect iterative delivery with architectural evidence, but they also underline the need for evaluation beyond a conceptual mapping [55,56].

The practical and research problem addressed here is therefore not whether EA and Scrum can coexist in principle. The problem is how to define a lightweight, traceable, and governable integration that preserves enterprise-level coherence without creating a parallel delivery process. Existing literature covers EA value, agile delivery, software architecture, and model-driven engineering, yet it provides limited operational detail for integrating TOGAF ADM activities, ArchiMate concepts, Scrum accountabilities, and software-delivery artifacts in a resource-constrained SME.

This article develops and demonstrates such an integration using a digital learning SME as a single case. The contribution is an explicit design artifact consisting of: (1) four iterative ADM cycles; (2) three architecture detail levels; (3) an ADM-Scrum mapping; (4) minimum and extended ArchiMate modeling profiles; (5) a governance interface between an EA function and a Scrum Team; and (6) an execution protocol that links strategic drivers to implemented increments and feedback.

The study answers three research questions:

• RQ1: How can TOGAF ADM activities be aligned with Scrum events and artifacts while preserving enterprise-level architecture governance?
• RQ2: Which ArchiMate concepts can be retained in minimum and extended profiles to preserve strategy-to-implementation traceability in a digital learning SME?
• RQ3: What does an analytic single-case application reveal about lifecycle coverage, traceability, parsimony, governance clarity, and applicability?

The article makes a bounded claim. It demonstrates design feasibility and analytic fit to one enterprise context. It does not claim that the framework improves delivery speed, quality, or business performance, because no longitudinal comparison or controlled evaluation was available.

2. Background and Related Work

2.1. Enterprise Architecture and Business-IT Alignment

Early architecture frameworks organized heterogeneous descriptions of information systems and enterprises into coherent viewpoints [6]. Subsequent business-IT alignment research showed that alignment is dynamic, multidimensional, and dependent on organizational mechanisms rather than a static correspondence between plans [7,8]. EA extends this concern by representing interdependencies among strategy, capabilities, processes, information, applications, and infrastructure. Tamm et al. identified a broad set of potential EA benefits but also noted fragmentation in causal explanations [9]. Their later benefit-mechanisms model explains value through improved IS decision making, improved project delivery, and improvement of the IS platform [10].

The EA literature consistently warns against equating value with the number of models produced. Gong and Janssen found that the concept has accumulated both value claims and myths because EA is interpreted differently across contexts [11]. Schmidt and Buxmann identified governance as a central success factor for enterprise IT architecture management [12]. Niemi and Pekkola connected benefits to organizational transformation and highlighted the role of shared understanding [13]. Beese et al. showed that EA management can moderate the negative effects of information-systems architecture complexity [14]. Historical and systematic reviews similarly show a shift from descriptive frameworks toward continuous management and implementation concerns [15,16]. Foorthuis et al. linked concrete EA practices with benefits, reinforcing the need to study what architects actually do and how project teams use the outputs [17].

2.2. TOGAF ADM and ArchiMate as Tailorable Standards

ArchiMate was developed to provide a coherent language for integrated enterprise architecture modeling [18]. Its layered and aspect-oriented structure allows motivation and strategy to be connected to business behavior, application services, technology, and implementation. The language is intentionally generic; value depends on selecting viewpoints and concepts that answer stakeholder concerns rather than using every available element [19]. Architecture principles provide complementary decision guidance by expressing durable constraints and preferences [20].

The TOGAF Standard, 10th Edition presents ADM as an iterative method covering preliminary preparation, architecture vision, business architecture, information-systems architecture, technology architecture, opportunities and solutions, migration planning, implementation governance, architecture change management, and continuous requirements management [21]. The ArchiMate 4 Specification extends the language while retaining continuity with earlier concepts [22].

The source case was originally modeled using a pre-ArchiMate-4 concept set. In this study, concepts were reviewed at the level of meaning and layer coverage; a full formal migration, notation-level conformance test, and tool validation against ArchiMate 4 remain outside the study scope.

A critical terminological distinction follows. The two artifacts developed here are not presented as new metamodels that redefine ArchiMate syntax or semantics. They are tailored modeling profiles: selected subsets of standard concepts, together with usage rules and mappings to a delivery process. This wording avoids overstating the design contribution and makes the artifact reproducible.

2.3. Scrum and Agile Software Delivery

The Agile Manifesto and its principles emphasize working software, customer collaboration, responsiveness to change, technical excellence, simplicity, and sustainable development [23]. Scrum operationalizes empirical process control through three accountabilities, three artifacts with commitments, and five formal events within a Sprint [24]. The Product Owner is accountable for maximizing value and effective Product Backlog management; the Scrum Master is accountable for Scrum effectiveness; and Developers are accountable for creating a usable Increment. Any architecture-specific role introduced by an organization must not overwrite these accountabilities.

Evidence on agile development is generally positive but context-dependent. Reviews by Dybå and Dingsøyr and by Dingsøyr et al. found a growing evidence base alongside methodological limitations and a strong focus on team-level settings [25,26]. Conboy reconstructed agility as the continual readiness to create and respond to change [27]. Serrador and Pinto found an association between agile use and project success, while Chow and Cao identified organizational, process, people, technical, and project factors influencing outcomes [28,29].

Self-organization does not eliminate specialized knowledge or coordination. Hoda et al. identified informal roles that emerge in agile teams [30], and Moe et al. showed that shared mental models, trust, coordination, and leadership remain necessary [31]. At scale, transformations encounter integration with other functions, architecture, governance, and dependencies [32,33]. Agile requirements engineering must continuously manage changing needs, nonfunctional requirements, and stakeholder availability [34,35]. Migration from plan-driven practices also requires changes in culture, management, and knowledge-sharing mechanisms [36,37]. Continuous software engineering and DevOps further compress the feedback loop by integrating development, release, operation, and monitoring [38,39,40].

2.4. Software Architecture in Iterative and Model-Based Development

Software architecture provides the structures needed to reason about qualities, dependencies, and evolution [41]. Multiple viewpoints are necessary because no single representation adequately addresses all stakeholder concerns [42]. Architecture decisions should capture the issue, alternatives, rationale, and consequences rather than only the resulting structure [43]. Jansen and Bosch described architecture as a set of design decisions, making change and knowledge management central [44]. Reviews of architecture knowledge management show that decision capture remains difficult when documentation is separated from daily engineering work [45].

Agile architecture research rejects both comprehensive design before implementation and architecture by accident. Waterman et al. found that teams vary the amount of up-front architecture according to risk, project size, novelty, and organizational context [46]. Technical debt research provides a vocabulary for deliberate deferral and the future cost of inadequate design decisions [47].

Brown et al. argued that agility and architecture can coexist when architectural work supports incremental delivery and is continuously revisited [48]. Documentation studies show that developers use documentation selectively and value content that supports concrete tasks [49]. Architectural decision records and explicit design rationale therefore provide a practical bridge between models and implementation [50,51].

Model-driven engineering can increase consistency and traceability, but industrial adoption depends on tool usability, domain fit, and integration with engineering practices [52,53,54]. Huss et al. demonstrated an agile model-based software engineering process in the development of a health technology system and subsequently compared measured performance between process variants [55,56]. These studies provide a close precedent for combining an iterative process with formalized architecture artifacts, while the present study differs by focusing on enterprise-to-delivery traceability in an SME and by limiting its evaluation to analytic and case-based evidence.

2.5. Research Gap and Design Objectives

The literature yields five design tensions. First, EA must provide broad coherence without becoming a detached documentation function. Second, Scrum must retain its accountabilities while accepting inputs and constraints from outside the team. Third, the modeling language must preserve cross-layer traceability with a concept set small enough to maintain. Fourth, architecture decisions must be updated by implementation evidence. Fifth, a single-case design must distinguish demonstrated coverage from unmeasured performance effects.

Accordingly, the artifact is designed as an interface between an EA control plane and a Scrum delivery loop. TOGAF ADM supplies lifecycle concerns, ArchiMate supplies traceable representations, and Scrum supplies the empirical cadence. Integration occurs through backlog items, decision records, release planning, architecture evidence attached to Increments, and feedback to higher-level architecture.

3. Materials and Methods

3.1. Research Design

The study follows a retrospective design-science case-study strategy. Design science is appropriate because the research objective is to construct and evaluate an artifact intended to address an organizational problem [57,58,59,60]. The artifact is a method configuration rather than executable software: a defined set of process cycles, mappings, modeling profiles, roles, views, and decision rules. Case-study guidance was used to preserve the context in which the artifact was developed and demonstrated [61]. Literature identification combined prior source material with backward and forward snowballing logic [62], while the design-to-practice orientation follows the principle that research artifacts should be evaluated in conditions that expose both utility and limitations [63]. Review concepts were organized consistently with established software-engineering evidence-synthesis guidance [64].

The research process had six steps: problem framing; construction of a knowledge base from standards and peer-reviewed literature; extraction of case evidence; artifact construction; demonstration in the case organization; and analytic evaluation. Iteration between artifact construction and evaluation was allowed. Figure 1 presents the process.

3.2. Case Organization and Unit of Analysis

The case organization is IT Academy, s.r.o., a Slovak digital learning SME located in Bratislava. At the time represented by the source case, the organization had 13 employees in instructional, consulting, administrative, marketing, and software-development roles. It delivered certified in-person courses and online learning through the VITA platform. The unit of analysis is the organization’s enterprise-architecture-to-software-delivery configuration, not the commercial performance of individual courses or the quality of teaching.

The architecture included two customer-facing web estates. The in-person course site used TYPO3 and MySQL. The VITA online-learning site used WordPress, WooCommerce, custom PHP functionality, and MariaDB. Both were served through nginx in a hosted environment. The internal technology estate included Windows endpoints, MikroTik and UniFi networking, a VMware-based HP ProLiant server, virtual Windows and Linux workloads, database and data-processing software, and an externally hosted virtual private server. Table 1 summarizes the baseline relevant to the research artifact.

3.3. Data Sources and Evidence Processing

Four evidence groups were used. First, primary design artifacts produced during the study included the tailored ArchiMate profiles, the adapted ADM process, the proposed role structure, capability views, and the TOGAF-Scrum mapping. Second, the TOGAF, ArchiMate, Agile Manifesto, and Scrum Guide specifications supplied normative definitions [21,22,23,24]. Third, peer-reviewed literature supplied design principles, evaluation criteria, and known implementation risks. Fourth, organizational records, system documentation, and the verified application and technology inventory supplied the empirical context for the case study.

Evidence was processed in three passes. In the extraction pass, statements were classified as case facts, standard-defined concepts, proposed design elements, or expected benefits. In the normalization pass, terminology was aligned with current standard language. In particular, the proposed ArchiMate subsets were renamed modeling profiles, and the proposed Architecture Owner was redefined as an architecture liaison outside Scrum accountabilities. In the claim-control pass, expected benefits were separated from observed results. Claims about faster delivery, better quality, lower risk, or higher flexibility were not treated as findings unless direct evidence existed.

3.4. Artifact Construction Procedure

Artifact construction used five linked decisions. First, ADM concerns were grouped into four iterative cycles: Architecture Context, Architecture Delivery, Transition Planning, and Architecture Governance. Second, work was organized at enterprise strategic, segment, and capability levels. Third, ADM outputs were translated into backlog, release-planning, iteration, review, and implementation evidence. Fourth, ArchiMate concepts were selected for minimum and extended profiles according to traceability needs. Fifth, the governance interface was designed so that architectural advice reaches the Product Owner and Developers without adding a fourth Scrum accountability.

Concept selection followed an explicit inclusion rule. A concept was retained when it was required to represent at least one of the following: strategic motivation; capability or value flow; accountable business behavior; externally visible application or technology service; implementation dependency; transition state; or traceability from a requirement to a delivered solution. A concept was omitted from the minimum profile when the same decision could be communicated adequately by a retained concept and the additional semantic precision was not essential for the case. The extended profile added concepts needed for events, physical assets, interfaces, migration, and gaps.

3.5. Analytic Evaluation Criteria

Because no controlled comparison or longitudinal delivery dataset was available, the artifact was evaluated analytically. Six criteria were defined: (C1) standards continuity, meaning that the artifact does not contradict the core semantics or accountabilities of the source standards; (C2) lifecycle coverage across Preliminary, ADM A-H, and requirements management; (C3) cross-layer traceability from drivers to implementation evidence; (C4) parsimony of the modeling profile; (C5) governance clarity regarding decision rights and feedback; and (C6) applicability to the documented case architecture. A seventh possible criterion, causal delivery improvement, was explicitly marked not evaluated.

Table 2. Research questions, evidence, and evaluation logic.

Research question	Primary evidence	Evaluation output
RQ1	TOGAF ADM concerns, Scrum accountabilities/events/artifacts, source mapping, architecture-governance literature.	ADM-Scrum mapping and governance interface; assessed for lifecycle coverage and standards continuity.
RQ2	Case architecture inventory, ArchiMate concept semantics, source profiles.	Minimum and extended profiles; assessed for traceability and parsimony.
RQ3	Case demonstration and traceability chains.	Criterion-by-criterion analytic evaluation and explicit limitations.

Table 2. Research questions, evidence, and evaluation logic.

Research question	Primary evidence	Evaluation output
RQ1	TOGAF ADM concerns, Scrum accountabilities/events/artifacts, source mapping, architecture-governance literature.	ADM-Scrum mapping and governance interface; assessed for lifecycle coverage and standards continuity.
RQ2	Case architecture inventory, ArchiMate concept semantics, source profiles.	Minimum and extended profiles; assessed for traceability and parsimony.
RQ3	Case demonstration and traceability chains.	Criterion-by-criterion analytic evaluation and explicit limitations.

3.6. Validity, Ethics, and Use of Generative AI

Construct validity was addressed by defining each evaluation criterion and linking it to observable artifact properties. Internal validity is limited because the design is not a causal evaluation. External validity is analytic rather than statistical: transfer depends on similarity of organizational scale, platform structure, governance needs, and available architecture competence. Reliability was supported by documenting concept lists, mappings, rules, and the execution protocol in the article and Appendices.

The study used organizational architecture information and did not involve experiments with human participants, personal data, or clinical data. Some infrastructure details were generalized to avoid creating a security inventory more detailed than necessary for scientific interpretation. Generative AI assisted manuscript drafting, literature organization, language editing, diagram preparation, and DOCX formatting. It did not generate case measurements or substitute for author review.

4. Results

4.1. Design Requirements

Eight design requirements were derived from the problem, standards, and literature. They define what the integration must provide without assuming a specific tool.

Table 3. Design requirements for the integrated framework.

ID	Requirement	Rationale
DR1	Preserve strategy-to-implementation traceability.	EA must influence concrete delivery decisions rather than remain a high-level repository.
DR2	Operate iteratively and permit parallel work.	ADM concerns must be revisitable and compatible with Sprint-based inspection and adaptation.
DR3	Retain Scrum accountabilities.	Architecture governance must not displace Product Owner, Scrum Master, or Developer accountability.
DR4	Use a maintainable modeling subset.	The SME cannot sustain every language element and viewpoint continuously.
DR5	Represent cross-domain dependencies.	Business, application, data, technology, and transition concerns affect the same delivery decisions.
DR6	Connect architecture and solution backlogs.	Architectural work must be prioritized and translated into implementable items.
DR7	Capture decisions and implementation evidence.	Models must evolve from delivery feedback and expose deliberate technical debt or exceptions.
DR8	Support incremental adoption.	The organization must be able to start with a minimum profile and add precision when needed.

Table 3. Design requirements for the integrated framework.

ID	Requirement	Rationale
DR1	Preserve strategy-to-implementation traceability.	EA must influence concrete delivery decisions rather than remain a high-level repository.
DR2	Operate iteratively and permit parallel work.	ADM concerns must be revisitable and compatible with Sprint-based inspection and adaptation.
DR3	Retain Scrum accountabilities.	Architecture governance must not displace Product Owner, Scrum Master, or Developer accountability.
DR4	Use a maintainable modeling subset.	The SME cannot sustain every language element and viewpoint continuously.
DR5	Represent cross-domain dependencies.	Business, application, data, technology, and transition concerns affect the same delivery decisions.
DR6	Connect architecture and solution backlogs.	Architectural work must be prioritized and translated into implementable items.
DR7	Capture decisions and implementation evidence.	Models must evolve from delivery feedback and expose deliberate technical debt or exceptions.
DR8	Support incremental adoption.	The organization must be able to start with a minimum profile and add precision when needed.

4.2. Integrated Control Plane and Delivery Loop

The resulting framework separates, but does not isolate, two loops. The EA control plane maintains enterprise strategic architecture, segment architecture, and capability architecture. The Scrum delivery loop maintains the Product Backlog, Sprint Goal, Sprint work, usable Increment, review, and retrospective. Integration occurs through architecture backlog items entering prioritization, implementable capability increments constraining and informing solution work, implementation evidence updating architecture records, and change signals triggering reassessment at segment or enterprise level.

Enterprise strategic architecture provides a high-level view of direction, principles, capability priorities, and major constraints. Segment architecture translates that direction into product, service, process, data, and platform boundaries. Capability architecture defines increments detailed enough to enter delivery planning. The levels are not sequential gates. A strategic decision may be refined while a capability increment is being implemented, provided affected assumptions and dependencies are visible.

Figure 2. Integrated enterprise architecture control plane and Scrum delivery loop.

Figure 2. Integrated enterprise architecture control plane and Scrum delivery loop.

4.3. Four Iterative ADM Cycles

The ADM was configured as four interacting cycles. Architecture Context covers preliminary governance, principles, scope, stakeholders, and Architecture Vision. Architecture Delivery covers Business, Information Systems, and Technology Architecture together with identification of candidate solution building blocks. Transition Planning covers Opportunities and Solutions and Migration Planning. Architecture Governance covers Implementation Governance and Architecture Change Management. Requirements management remains continuous across all cycles.

This grouping is a navigation structure, not a replacement for ADM. It makes iteration visible and reduces the temptation to interpret phases as a one-pass waterfall. A Sprint may address concerns from several ADM phases. For example, implementation of an application service can reveal a technology constraint, produce a new architecture decision, and create a change item for the segment backlog.

4.4. Mapping TOGAF ADM to Scrum

The mapping in Table 4 answers RQ1 at an operational level. It distinguishes an architecture backlog from the Product Backlog. The architecture backlog contains concerns that require architectural analysis or governance, such as cross-product dependencies, principles, target-state options, standards, and exceptions. Items that require software work are expressed in the Product Backlog under Product Owner accountability. Architecture information can shape acceptance criteria, Definition of Done practices, nonfunctional requirements, and decision records, but it does not create a competing prioritization authority.

Architecture release planning in the source design was retained as a forecasting activity, not a fixed commitment. An architecture development iteration may occur within one Sprint or span several Sprints, depending on the uncertainty and scope. The review point is the availability of usable evidence: a decision, model, experiment, interface contract, migration result, or running Increment. A retrospective examines the effectiveness of both delivery and architecture collaboration.

4.5. Tailored ArchiMate Modeling Profiles

The minimum profile contains 25 concepts across motivation, strategy, business, application, technology, and composite categories. The extended profile contains 42 concepts and adds event detail, technology interfaces and artifacts, physical concepts, and implementation-and-migration concepts. The minimum profile therefore contains 17 fewer concepts, a reduction of 40.5% relative to the extended profile. The reduction is a parsimony result, not evidence of lower modeling effort in practice.

Table 5. Comparison of the minimum and extended ArchiMate modeling profiles.

Category	Minimum profile	Extended profile	Purpose of extension
Motivation	Stakeholder; Driver; Goal; Requirement; Principle	Adds Assessment; Outcome	Express diagnosis and measurable result.
Strategy	Resource; Capability; Value Stream; Course of Action	Same as minimum	Retains capability-based planning in both profiles.
Business	Business Actor; Business Role; Business Process; Business Service; Business Object; Product	Adds Business Event	Represent triggers relevant to delivery and operations.
Application	Application Component; Application Interface; Application Function; Application Service; Data Object	Adds Application Process; Application Event	Add behavioral detail when services and integrations require it.
Technology	Node; System Software; Technology Service	Adds Device; Technology Interface; Communication Network; Artifact	Represent deployment, networks, and implementation artifacts.
Physical	Not included	Equipment; Facility; Material	Represent physical learning and infrastructure dependencies when required.
Implementation and migration	Not included	Work Package; Deliverable; Implementation Event; Plateau; Gap	Represent transition planning and release states.
Composite	Grouping; Location	Same as minimum	Structure views and show relevant sites or environments.

Table 5. Comparison of the minimum and extended ArchiMate modeling profiles.

Category	Minimum profile	Extended profile	Purpose of extension
Motivation	Stakeholder; Driver; Goal; Requirement; Principle	Adds Assessment; Outcome	Express diagnosis and measurable result.
Strategy	Resource; Capability; Value Stream; Course of Action	Same as minimum	Retains capability-based planning in both profiles.
Business	Business Actor; Business Role; Business Process; Business Service; Business Object; Product	Adds Business Event	Represent triggers relevant to delivery and operations.
Application	Application Component; Application Interface; Application Function; Application Service; Data Object	Adds Application Process; Application Event	Add behavioral detail when services and integrations require it.
Technology	Node; System Software; Technology Service	Adds Device; Technology Interface; Communication Network; Artifact	Represent deployment, networks, and implementation artifacts.
Physical	Not included	Equipment; Facility; Material	Represent physical learning and infrastructure dependencies when required.
Implementation and migration	Not included	Work Package; Deliverable; Implementation Event; Plateau; Gap	Represent transition planning and release states.
Composite	Grouping; Location	Same as minimum	Structure views and show relevant sites or environments.

The minimum profile is intended for initial landscape, capability, service, and dependency views. The extended profile is activated when the question requires more precise transition, physical, deployment, event, or interface semantics. This progressive rule implements DR4 and DR8: the team begins with the least semantic load that preserves the decision, then expands only when additional precision changes analysis or implementation.

4.6. Governance and Role Interface

The source case proposed Chief Architect, Enterprise Architects, Architecture Owners, Scrum Masters, and Development Teams. The revised framework preserves the useful liaison function but avoids presenting Architecture Owner as a Scrum accountability. The chief or enterprise architect is accountable for principles, cross-segment coherence, architecture exceptions, and maintenance of reference views. The EA function curates models and decision records. An architecture liaison works with one or more Scrum Teams to explain constraints, facilitate decisions, and return implementation evidence.

The Product Owner remains accountable for value and Product Backlog management. Developers remain accountable for the usable Increment and technical quality. The Scrum Master remains accountable for Scrum effectiveness. The architecture liaison advises and facilitates; it does not order the Product Backlog or direct Developers. Figure 3 and Table 6 formalize these boundaries.

4.7. Demonstration in the Digital Learning SME

The case architecture was represented as a chain from business services to applications, databases, hosting, internal infrastructure, and virtual workloads. Figure 4 provides a simplified view. The purpose is not to publish a security-sensitive inventory but to show that the framework can connect customer-facing value to software and infrastructure decisions.

Three illustrative traceability chains were constructed. The first begins with the driver to expand digital learning, proceeds to a goal for reliable online course delivery, identifies the online-learning capability and VITA service, and reaches application and hosting changes. The second begins with a driver for consistent customer information, proceeds to a requirement for controlled data exchange between sites, and reaches interface and data-object decisions. The third begins with operational resilience, proceeds to technology-service and deployment requirements, and reaches VPS, backup, monitoring, and recovery backlog items.

Table 7. Illustrative strategy-to-implementation traceability chains.

Traceability stage	Digital learning chain	Data consistency chain	Operational resilience chain
Driver / goal	Growth of online learning / dependable course access.	Consistent customer and order information.	Continuity of customer-facing services.
Capability / value	Online learning delivery and course-commerce capability.	Customer and order data management.	Platform operations and recovery capability.
Business / application service	VITA learning and commerce services.	Course catalogue, registration, order, and account services.	Web hosting, database, backup, monitoring, and restore services.
Architecture decision	Keep incremental enhancement of the existing platform while isolating custom functionality behind explicit interfaces.	Define authoritative data objects and interface ownership before synchronization.	Separate deployment and recovery concerns; document external-hosting dependencies.
Product Backlog examples	Upgrade path, custom PHP refactoring, automated acceptance checks.	Interface contract, data mapping, validation, migration test.	Backup verification, observability, recovery rehearsal, dependency documentation.
Increment evidence	Running feature and updated application view.	Tested exchange and updated data/interface record.	Observed restore result and updated technology decision.

Table 7. Illustrative strategy-to-implementation traceability chains.

Traceability stage	Digital learning chain	Data consistency chain	Operational resilience chain
Driver / goal	Growth of online learning / dependable course access.	Consistent customer and order information.	Continuity of customer-facing services.
Capability / value	Online learning delivery and course-commerce capability.	Customer and order data management.	Platform operations and recovery capability.
Business / application service	VITA learning and commerce services.	Course catalogue, registration, order, and account services.	Web hosting, database, backup, monitoring, and restore services.
Architecture decision	Keep incremental enhancement of the existing platform while isolating custom functionality behind explicit interfaces.	Define authoritative data objects and interface ownership before synchronization.	Separate deployment and recovery concerns; document external-hosting dependencies.
Product Backlog examples	Upgrade path, custom PHP refactoring, automated acceptance checks.	Interface contract, data mapping, validation, migration test.	Backup verification, observability, recovery rehearsal, dependency documentation.
Increment evidence	Running feature and updated application view.	Tested exchange and updated data/interface record.	Observed restore result and updated technology decision.

The demonstration also shows where the minimum profile becomes insufficient. Migration from one platform state to another benefits from Plateau and Gap. Recovery design benefits from Device, Technology Interface, Communication Network, and Artifact. Events become useful when course enrollment, payment, provisioning, or operational alerts trigger behavior. These needs justify progressive movement to the extended profile rather than permanent use of the full concept set.

4.8. Analytic Evaluation

Table 8 presents the criterion-based evaluation. Standards continuity, lifecycle coverage, traceability, parsimony, and case applicability are supported analytically. Governance clarity is partially supported because responsibilities are explicit, but the arrangement was not independently observed across multiple teams. Causal delivery improvement was not evaluated.

4.9. Reusable Execution Protocol

The artifact can be executed as a repeating protocol. Step 1 identifies a change signal and determines whether it is local, segment-wide, or enterprise-wide. Step 2 updates the relevant driver, goal, requirement, capability, and principle records. Step 3 selects the minimum ArchiMate view sufficient for the decision. Step 4 records alternatives and an architecture decision. Step 5 translates implementable consequences into Product Backlog items under Product Owner accountability. Step 6 selects work through normal Sprint Planning. Step 7 attaches architecture evidence to the resulting Increment. Step 8 reviews conformance, exceptions, outcomes, and new signals. Step 9 updates higher-level architecture only where implementation evidence changes assumptions, dependencies, or priorities.

The protocol is intentionally compatible with different repository and work-management tools. Traceability can be implemented through identifiers rather than a single integrated platform. A practical identifier scheme is DRV for driver, GOL for goal, CAP for capability, REQ for requirement, ADR for architecture decision record, PBI for Product Backlog item, and INC for Increment evidence. The minimum requirement is that a decision can be traced backward to its motivation and forward to implementation and review evidence.

5. Discussion

5.1. Answer to RQ1: Aligning ADM with Scrum

The case shows that alignment is feasible when ADM is treated as a set of continuously revisited architecture concerns rather than a project stage model. The four cycles make the concerns navigable, while the Scrum delivery loop remains intact. The key integration mechanism is not a phase-to-event equivalence. It is controlled translation between architecture concerns and Product Backlog items, followed by implementation evidence returning to architecture. This finding is consistent with EA benefit research that emphasizes improved decision making and project delivery [10,17] and with agile research that emphasizes feedback, self-organization, and context-sensitive coordination [25,26,27,28,29,30,31,32,33].

The governance result also resolves a common role ambiguity. Organizations may need a named architecture liaison, but Scrum already defines its accountabilities. Treating the liaison as an external organizational role preserves architecture expertise without creating a competing backlog owner. This arrangement is especially relevant in an SME where one person may perform several organizational roles but must still distinguish the decision right being exercised at a given moment.

5.2. Answer to RQ2: Minimum and Extended Modeling Profiles

The minimum 25-concept profile is sufficient to express motivation, capability direction, core business behavior, customer-facing application services, essential technology services, and grouping by location or concern. It supports landscape and decision views without requiring the modeler to navigate the whole language. The 42-concept extended profile adds the precision required for migration, events, interfaces, deployment, networks, physical assets, and gaps. The profiles therefore implement progressive disclosure: use the minimum semantics that preserve the decision, then add concepts when they change analysis or implementation.

This result should not be interpreted as a universal optimal profile. Different industries may require contracts, security, manufacturing, physical flows, or regulatory evidence not emphasized in the digital learning case. The contribution is the selection logic and explicit list, which can be evaluated and adapted, rather than the claim that 25 or 42 is an ideal number.

5.3. Answer to RQ3: What the Case Demonstrates

The single case demonstrates lifecycle coverage and the ability to trace three representative concerns across organizational and technical layers. It also demonstrates that a small organization can separate enterprise, segment, and capability reasoning without creating three bureaucratic approval hierarchies. The levels describe scope and decision horizon; they do not determine team structure.

The strongest analytic result is parsimony: the minimum profile is 40.5% smaller by concept count than the extended profile. The most important unresolved result is utility in sustained use. The study does not establish whether model maintenance remains timely, whether Product Backlog quality improves, whether architecture exceptions decline, or whether lead time and defect rates change. Those questions require prospective evaluation.

5.4. Theoretical Implications

The framework contributes a boundary-object interpretation of enterprise architecture. Architecture models and decisions are useful not because they are complete descriptions but because they mediate between strategic, product, and engineering conversations. The architecture backlog and Product Backlog are distinct but linked boundary objects. This separation protects both enterprise coherence and product accountability.

The study also clarifies the relationship between intentional and emergent architecture. Intentional architecture is represented by principles, capability direction, reference views, constraints, and transition hypotheses. Emergent architecture enters through implementation evidence, experiments, changed assumptions, and technical discoveries. The feedback link in Figure 2 is therefore as important as the forward link. Without it, EA becomes prescriptive and stale; without intentional direction, delivery becomes locally optimized.

Finally, the modeling-profile concept provides a bridge between language completeness and method usability. Model-driven engineering research often focuses on language and tool capability [52,53,54], while agile research emphasizes working outcomes. A profile makes the modeling commitment explicit and testable. It allows researchers to ask whether a smaller concept set improves comprehension, traceability, or maintenance without conflating those outcomes with the underlying standard.

5.5. Practical Implications

For practitioners, the framework suggests starting with one capability and one product area. The organization should define a small set of principles, create a capability and service view, document one or two consequential decisions, and link those decisions to Product Backlog items. Architecture evidence should be reviewed with the Increment, not collected months later. Expansion to the extended profile should be triggered by a concrete question, such as migration sequencing, interface ownership, recovery, or physical dependencies.

The framework also provides a control against architecture theater. Every maintained view should answer a named concern and have a review trigger. Every architecture backlog item should either produce a decision, evidence, a model update, a Product Backlog item, or an explicit decision to stop. Every exception should have an owner, consequence, and review date. These rules reduce the risk of accumulating diagrams that no delivery decision uses.

In the case organization, immediate use cases include coordinating changes across the TYPO3 and VITA estates, clarifying authoritative data and interfaces, managing custom PHP evolution, representing hosting dependencies, and treating backup and recovery work as capability increments rather than isolated technical tasks. The same logic can support security, observability, platform upgrades, and eventual replacement decisions.

5.6. Limitations

The study has six principal limitations. First, it is a retrospective single-case study in a 13-person organization. Second, the author was also associated with the case organization and the original artifact, creating a risk of confirmation bias. Third, no independent architecture experts, Product Owners, Scrum Masters, or Developers rated the artifact. Fourth, no longitudinal metrics were collected. Fifth, the detailed profile originated before ArchiMate 4, and only concept-level continuity was reviewed. Sixth, some technical detail was generalized for security and maintainability.

The analytic evaluation mitigates overclaiming but cannot replace field evidence. Supported criteria indicate that the artifact is internally coherent and applicable to the documented case. They do not demonstrate that another organization will adopt it successfully or that delivery outcomes will improve.

5.7. Future Research

Future work should conduct a prospective multi-case evaluation. At least three organization types should be compared: a small single-product digital firm, a multi-product SME, and a regulated organization. Evaluation should combine architecture-quality measures, practitioner ratings, repository data, and delivery metrics. Candidate outcomes include trace-link completeness, time to architecture decision, backlog aging, exception aging, change failure rate, lead time, deployment frequency, defect escape rate, rework, model update latency, and perceived decision usefulness.

A formal ArchiMate 4 migration should test each selected concept, relationship, viewpoint, and constraint in a conformant modeling tool. Controlled comprehension studies could compare the minimum profile, extended profile, and unrestricted language. Process-mining or repository-mining studies could examine whether architecture decisions and models are updated in response to actual delivery events. Finally, independent expert review should evaluate semantic completeness, role clarity, and transferability.

6. Conclusions

This study developed an integrated TOGAF ADM-ArchiMate-Scrum framework for aligning enterprise architecture with agile software delivery in a digital learning SME. The framework organizes ADM concerns into four iterative cycles, separates enterprise strategic, segment, and capability architecture, maps architecture outputs to Scrum delivery interfaces, defines minimum and extended ArchiMate profiles, and clarifies governance roles without changing Scrum accountabilities.

The analytic case application supports standards continuity, lifecycle coverage, strategy-to-implementation traceability, profile parsimony, and applicability to the documented architecture. The minimum profile contains 25 concepts, 40.5% fewer than the 42-concept extended profile. The framework offers a concrete execution protocol based on backlog translation, architecture decisions, Increment evidence, and feedback.

The contribution is a reproducible design artifact and a bounded demonstration. No causal improvement in delivery performance was established. Before operational or scientific claims are strengthened, the framework requires independent expert review, formal ArchiMate 4 validation, prospective use, and multi-case evaluation with longitudinal metrics.

Appendix A.1. Minimum Profile: 25 Concepts

Motivation: Stakeholder, Driver, Goal, Requirement, Principle. Strategy: Resource, Capability, Value Stream, Course of Action. Business: Business Actor, Business Role, Business Process, Business Service, Business Object, Product. Application: Application Component, Application Interface, Application Function, Application Service, Data Object. Technology: Node, System Software, Technology Service. Composite: Grouping, Location.

Appendix A.2. Extended Profile: 42 Concepts

The extended profile contains all minimum-profile concepts and adds: Assessment, Outcome, Business Event, Application Process, Application Event, Device, Technology Interface, Communication Network, Artifact, Equipment, Facility, Material, Work Package, Deliverable, Implementation Event, Plateau, and Gap.

Selection rule: use the minimum profile by default. Add an extended concept only when it materially changes stakeholder understanding, analysis, implementation, migration, or verification. A project may use a mixed profile across views, provided each view states its concern, audience, and modeling convention.