Set B
Enterprise Architecture Work Scenario
1: Building the Innovation Architecture for a 21st Century University
Scenario: NovaTech University (NTU) is a leading Higher Education Institute (HEI) in India known for its strong foundation in engineering, science, and management education. Traditionally, NTU focused on teaching and academic research, producing high-quality graduates and scholarly publications.
Over the past decade, NTU’s leadership has recognized a paradigm shift in global higher education — where universities are not just knowledge creators but also innovation engines that convert research and intellectual property (IP) into economic and social value.
To align with this vision, NTU has launched a strategic initiative titled “Innovation-to-Income 2030”, with the ambition to become a world leader in IP-driven, industry-integrated education — an ecosystem at the intersection of technology, intellectual property, and enterprise creation.
As part of this transformation, NTU has begun to digitize its innovation value chain — from research ideation and IP generation to commercialization and industry partnerships. Historically, NTU’s digital systems supported only academic and administrative functions (such as admissions, grades, HR, and finance). However, the new vision requires digital capabilities for managing: IP creation and protection, Industry and startup collaborations, Licensing, royalty, and revenue-sharing processes and Partner and alumni innovation ecosystems
To enable this, NTU established an Enterprise Architecture (EA) function tasked with designing an integrated Institutional Innovation Relationship Management (IIRM) platform — a unified system to manage relationships and data across students, faculty, IP assets, startups, and industry partners.
Problem(s): A recent Business Architecture review involving academic, research, and industry stakeholders revealed several key findings: The existing value streams (from research to commercialization) are fragmented across departments. Information flows between research offices, IP cells, and industry partners are inconsistent, leading to delays in IP commercialization and poor partner experience. Stakeholders identified three core motivations: Accelerate IP-to-market outcomes, Enhance partner and learner experience and Reduce sustained operational costs
While all stakeholders agree that the partner experience must improve, the EA team leader notes that the current value streams consume substantial IT and administrative resources, driving up long-term costs.
Solution(s):
You are a Senior Architect in NTU’s Enterprise Architecture team. Your responsibility is to guide the CRM-to-IIRM transformation roadmap — ensuring that architectural decisions align with NTU’s strategic motivations of innovation agility, partner experience, and cost efficiency. During a review meeting, the EA team leader asks: “What information do we need to focus on to address the motivation to drive down sustained costs, while improving innovation speed and stakeholder experience across the IP value chain?”
Based on the TOGAF Standard and the scenario above, which of the following is the best approach to take?
A: Identify where the Application Architecture, especially the information system services and logical application components, fail to support IP time-to-market, partner experience, and cost efficiency. Determine the changes to the information flows that will enable faster innovation cycles and improved experiences while lowering sustained costs. Finally, identify stakeholder priorities for enhanced innovation capabilities, refined value streams, and optimized process flows.
B: Produce application and data models of the current state of NTU’s systems, then develop a Target Architecture showing how the future system will enhance IP time-to-market and cost efficiency. Create architectural views describing these changes, and identify gaps between current and target architectures to build a transformation roadmap.
C: Determine where the Application and Data Architectures cause information flow issues across the research-to-commercialization process. Identify incremental improvements that enhance partner experience, assess their one-time implementation cost, and evaluate the ongoing operational impact. Engage stakeholders to confirm whether these improvements justify the cost trade-offs.
D: Determine where the Application Architecture and Data Architecture fail to support IP time-to-market, partner experience, and cost optimization. Focus on the logical application and logical data components, identifying changes that enable faster innovation delivery and lower costs. Define the work required to improve systems in terms of innovation agility, experience, and cost. Finally, obtain stakeholder priorities for enhancing applications, data structures, and interfaces aligned with NTU’s Innovation-to-Income vision.
Answer
What do we need to know to drive down sustained costs using Phase C: Information Systems Architecture?
Option A Rank: 2nd Best Option. 3 Points
Identifies where the Application Architecture (information system service, logical app component) fails to support goals → Determines info flow changes → Identifies stakeholder priorities.
Strengths: Connects motivation (time-to-market, cost, experience) to Application Architecture. Considers information flow improvements. Ends with stakeholder prioritization.
Weaknesses: Focused only on Application Architecture — does not explicitly integrate Data Architecture. Emphasizes “information flow” but not the broader “logical data components.” Doesn’t explicitly describe the work required or target architecture definition.
Evaluation & Explanation (Why Scond Best): Good conceptual understanding. Lacks completeness in coverage of architecture domains.
It focuses on architectural components and info-flows but stops short of analysing the cost/benefit of actual changes (one-time vs sustainment). Without that feasibility/cost analysis, you cannot reliably create Phase E roadmaps or Phase F implementation plans accepted by stakeholders.
A links motivations to Application Architecture and information-flow improvements, and it captures stakeholder priorities for capabilities and flows.
Option B Rank: 4. Distractor (Wrong Answer). 0 Point
Produce application and data models of current state → develop target → identify gaps → roadmap.
Strengths: Uses standard TOGAF steps: Baseline → Target → Gap → Roadmap. Addresses systematic modeling and transition planning.
Weaknesses: Mechanically correct, but misses the motivation linkage — focuses on deliverables, not on why (the stakeholder motivations). Doesn’t cover how architecture changes improve customer/partner experience or cost. More of a method procedural answer, not a motivational alignment answer.
Evaluation & Explanation (Why Incorrect): Technically fine, but shallow in strategic reasoning. Suitable if question asked “What steps would you follow?” — but here it’s about what you need to know to address motivation.
B is a Baseline→Target→Gap approach (models and views), but it jumps into modeling/targeting without anchoring back to the Business Architecture’s identified value-stream and information-flow deficiencies.
It fails to show how the proposed Application/Data target will resolve the known shortfall or whether stakeholders will accept the necessary cost/trade-offs. Thus it doesn’t answer the “what you need to know” for driving down sustained costs.
Option C Rank: 1. Correct Answer. 5 Points.
Analyze why systems (Application + Data) cause those issues and what architectural changes could fix them. While in Phase B , it about how to identify value streams, capabilities, and issues (e.g., poor experience, cost drivers). Downstream Phase E would gGroup architectural changes into work packages (roadmap) and Phase F would plan implementation and cost sequencing.
Determine where architectures create information flow problems → identify incremental improvements → assess one-time and ongoing cost → check with stakeholders if worth it.
Strengths: Balances cost and stakeholder perspective. Realistic (incremental improvements). Explicitly investigates where information flow problems arise in current Application & Data Architectures (Root cause focus, information flow/flaw analysis). Evaluates cost and sustainment impact and tests stakeholder acceptance (Stakeholder realism). Provides input (cost, feasibility, benefit) to Phases E & F (Use in later phases). Covers Application + Data, root cause, value, cost, stakeholder validation (Architectural completeness).
Weaknesses: Too operational, not architectural. Talks about “one-time work” and “ongoing cost,” but not architecture components or domains. Missing logical structure or system-level change planning. Evaluates cost trade-offs rather than architectural motivations.
Evaluation & Explanation (Why Best) : Pragmatic but low in TOGAF maturity. Would be a tactical project manager’s answer, not an architect’s. (1) C focuses on analysis of the known issue — correct for Phase C. (2) C matches how stakeholders actually decide on changes (based on value vs cost). (3) C better supports downstream planning. (4) C aligns with the case context. (5) C gives a more usable architectural picture.
Phase C’s job here is diagnosis and analysis of the current Application + Data Architectures in the context of known information-flow problems that are causing customer/partner experience shortfalls.
Stakeholders will accept changes only when they see the cost of change (one-time) and the ongoing sustainment cost versus expected outcomes/benefits.
Option C explicitly: (a) finds where the systems cause the information-flow deficiency, (b) identifies incremental changes that improve experience, and (c) evaluates one-time and sustained costs so stakeholders can decide.
Those cost/benefit results feed directly into Phase E (Opportunities & Solutions / roadmap of work packages & dependencies) and Phase F (Migration planning / implementation plan).
In short: C gives the practical, stakeholder-validatable information Phase E/F need — so it’s the correct Phase-C answer. Choose C because Phase C must analyze where information systems cause the known information-flow shortfall and quantify the one-time and ongoing costs of fixes — that cost/benefit judgment is what stakeholders use to accept a Target Architecture and for Phases E/F to build realistic roadmaps and implementation plans.
In Phase C, to drive down sustained costs, you must: Identify where the current Application & Data Architectures cause information flow inefficiencies (known pain points). Analyze what architectural changes could fix these deficiencies. Estimate one-time and ongoing (sustained) costs of those changes. Evaluate whether the improved outcomes justify the cost. Confirm stakeholder acceptance before proceeding to roadmap (Phase E).
What Phase C is About? Information Systems Architecture in the TOGAF ADM includes two major parts: Application Architecture — how logical applications and their interactions support business processes and capabilities. Data Architecture — how data is structured, stored, accessed, and shared across the enterprise. Phase C defines the Target Application and Data Architectures that will enable business goals such as agility, experience improvement, or cost reduction. The Motivation: “Drive Down Sustained Costs” . Sustained cost refers to ongoing operational and maintenance costs — not one-time project expenses. Typical examples: Cost of running and maintaining multiple legacy systems. Data duplication and synchronization overheads. Expensive integration interfaces. Fragmented applications causing redundant processes or licensing fees. Poor data quality leading to rework or manual correction. So, in Phase C, your goal is to architect the information systems (apps + data) to reduce these ongoing costs without hurting agility or experience.
Option D Rank: 3rd Best Option. 2 Points
Determine where Application and Data Architectures fail to support goals → focus on logical components → identify changes → determine required work → get stakeholder priorities.
Strengths: Explicitly integrates Application and Data Architectures. Focuses on logical components → aligns with Phase C (Application & Data Architecture). Links motivations (cost, experience, time-to-market) to architectural change. Ends with stakeholder prioritization — directly aligned with TOGAF ADM objectives. Balanced, strategic, and architecture-driven.
Weaknesses: Slightly more work-centric phrasing but conceptually strong. Assumes deficiencies but jumps to defining changes at logical component level. Gathers stakeholder priorities, but at implementation detail level (apps, data, interfaces). Doesn’t provide this practical information — remains conceptual. Omits this key linkage, focusing narrowly on logical components. Covers Application + Data, logical components, stakeholder priorities — but without cost or flow analysis.
Evaluation & Explaination (Why Third): Complete, coherent, and motivation-aligned. Fully satisfies TOGAF’s “traceability from stakeholder concern to architecture change.”
D considers both Application + Data logical components and asks for stakeholder priorities about app/data/interfaces.
It fails to analyse the information flows (the known root cause of poor experience) and doesn’t require the cost/acceptability analysis of the actual changes. It’s more design-centric (logical decomposition) than validation/feasibility-centric, so it doesn’t provide the inputs Phase E/F require.
Note: We’re in Phase C: Information Systems Architecture, and the question is: “What do you need to know to drive down sustained costs?”. The case study explicitly establishes: Known deficiencies in information flows (causing poor experience). A motivation to drive down sustained costs. A requirement to make realistic, stakeholder-accepted change decisions — not purely conceptual designs. So, while both C and D discuss Application and Data Architectures, the difference lies in depth of analysis vs. conceptual coverage.
Option D: Jumps directly into defining logical components and changes (a design activity). Doesn’t analyze the why (information flow deficiencies). Misses the cost/value feasibility check that determines whether stakeholders accept the change. Thus, D is architecturally structured but incomplete, while C is analytical, stakeholder-aware, and actionable.
Final Ranking
1st (Correct)
C
Focuses on information flow deficiencies, analyzes cost/benefit, ensures stakeholder acceptance — the essence of applying Phase C to a known shortfall.
2nd
A
Conceptually sound and aligned with motivations but lacks data layer and cost realism.
3rd
D
Covers both architectures but misses information flow analysis and stakeholder feasibility; too conceptual.
4th (Wrong)
B
Process-oriented (Baseline/Target/Gap) but disconnected from
motivation and stakeholder cost considerations.
HINT: Quick Mental Checklist for Similar Questions
Phase C, you are analyzing and scoping architectural changes — not yet defining implementation detail, but you do need to understand cost, value, and acceptability of those changes to ensure feasibility later. Option C aligns with how architects actually bridge architecture and business feasibility: You don’t yet define the target model in detail (that’s Phase D → E work). You analyze the current Application/Data architectures and their information flows to find where problems (and costs) originate. You assess the cost/benefit trade-offs of possible corrections. Stakeholders decide if those corrections are worth implementing.
What Phase C must deliver (so stakeholders can accept a Target Architecture and allow Phase E/F planning). When evaluating multiple-choice questions like this in EA or TOGAF exams:
Does it address both Application and Data Architecture domains? Does it focus on logical components rather than physical or implementation specifics? Does it connect stakeholder motivation → architectural gap → required change? Does it avoid getting stuck in method steps (too procedural)? Does it avoid tactical/operational fixes (too project-level)?
When applying Phase C to drive down sustained costs in the HEI case, ensure Phase C discovers and documents:
Root cause mapping: exactly where current application(s) and data artifacts create information-flow failures in the research → IP → commercialization value stream.
Change candidates: the specific application or platform changes (including incremental options) that would correct the flows.
Benefit estimate: expected improvements to partner/learner experience and IP-to-market throughput (quantified where possible).
Cost estimate (two parts): One-time change cost (development, migration, integration) and Sustained (operational) cost after change (hosting, licensing, support).
Feasibility & risk: technical feasibility, data migration risk, interoperability issues.
Prioritization input: stakeholder willingness to trade cost vs benefit (so they can prioritize work packages).
Traceability: clear linkage from Business Architecture deficiency → Phase C analysis → inputs required for Phase E roadmaps and Phase F migration planning.
What You Need to Know (Checklist)
When the EA team leader asks, “What do you need to know to address the motivation to drive down sustained costs?” Here’s what you — as the architect — should find out within Phase C scope:
1.
Which logical applications and data stores overlap or duplicate functionality
Redundant systems increase license, integration, and maintenance cost.
2.
Where information flows are inefficient or fragmented
Poor integration causes manual reconciliation and system bloat.
3.
Which applications are misaligned with business capabilities or value streams
Misalignment means you’re maintaining systems that don’t add business value.
4.
What the key data entities and information services are and how they’re shared
Data inconsistency drives rework and governance cost.
5.
Which technologies, platforms, or vendors contribute to technical debt
Legacy technologies can be expensive to maintain or scale.
6.
Where integration patterns are complex (point-to-point vs. service-based)
Simplifying interfaces reduces ongoing support cost.
7.
What opportunities exist for consolidation or standardization (e.g., shared services, common data models)
Consolidation reduces infrastructure, licensing, and operations overhead.
8.
How data lifecycle and storage are managed (archival, retention, backups)
Poor data lifecycle management inflates storage and compliance cost.
9.
What non-functional requirements (NFRs) drive cost — e.g., performance, availability
Overengineering NFRs can raise sustained infrastructure cost unnecessarily.
10.
Stakeholder priorities among cost, agility, and experience
You need to know acceptable trade-offs — some cost-saving measures may slow delivery or reduce flexibility.
How Phase C Outputs Address Cost Drivers
Redundant applications
Application rationalization
Identify overlap, merge or retire systems
Legacy technologies
Platform modernization
Move to shared cloud platforms or low-maintenance environments
Integration complexity
Integration simplification
Use APIs/service bus instead of custom connectors
Data duplication
Data standardization
Define master data and shared repositories
Manual data handling
Information automation
Enable event-driven data flow or self-service analytics
Licensing and vendor sprawl
Platform consolidation
Negotiate enterprise-wide licenses or adopt open-source equivalents
In the Higher Education “Innovation-to-Income” Context
For your HEI scenario, to drive down sustained costs through Phase C, you would need to know:
Application
Which systems manage research IP, startups, and industry partners separately
Consolidate into a single “Institutional Innovation Relationship Management” platform
Data
How IP data, partnership records, and royalty data are stored across systems
Create shared data services or data lake to eliminate duplication
Integration
Whether academic, finance, and IP systems integrate manually
Automate through APIs or integration hub
Technology
Whether legacy ERP modules are being repurposed inefficiently
Refactor or retire unnecessary modules
Operations
How often data is reconciled manually across departments
Automate reconciliation and validation to save time and cost
To drive down sustained costs using Phase C: Information Systems Architecture, you need to identify where the Application and Data Architectures fail to efficiently support business processes and information flows, and determine what changes to logical application components, data entities, and interfaces will: Eliminate redundancy, Simplify integration, Improve data consistency, and Reduce ongoing maintenance and licensing costs. Finally, confirm stakeholder priorities to balance cost savings against innovation speed and experience goals.
When evaluating the best answer to a TOGAF-style question like this (especially around motivation, cost reduction, and architectural response), we look for four key dimensions:
1
Architecture Alignment
Connects motivations (cost, experience, time-to-market) with architectural domains (Business, Application, Data).
2
Scope of Analysis
Considers both logical (design-level) and information flow (process-level) perspectives, not just current models.
3
Stakeholder Engagement
Recognizes that stakeholder priorities must guide trade-offs (e.g., between experience vs. cost).
4
Outcome Orientation
Focuses on what needs to change (logical components, data, flows) and why (link to motivations), not just documentation (models or views).
Let’s break it down in plain language — and then map each question to what it would mean in your NovaTech University / IIRM scenario.
Step1 : Select Reference Models, Viewpoints, and Tools (in Phase C)
Purpose: Before you start modelling or designing the Application and Data Architectures, you must decide: What perspectives (viewpoints) you’ll use to look at the system — i.e., what your stakeholders care about. Which reference models or architectural frameworks you can reuse (instead of reinventing). Which tools and techniques you’ll use to model, analyse, and communicate your architecture. This ensures you don’t model for the sake of modelling — you model with intent, aligned to stakeholder concerns and enterprise context.
Apply to the HEI Case (NovaTech / IIRM): Context recap: The university is transforming from a traditional academic model to an IP-to-Income (I2I) innovation ecosystem — integrating research, patents, licensing, and industry partnerships into one digital and data-driven flow. Phase C here focuses on designing the Information Systems Architecture (Data + Applications) that support this integrated value stream.
Practitioners’ Questions — Interpreted for the HEI Case:
1. “Given a set of stakeholders and concerns, what information do you need to know about the system being examined to address their concerns?” Translation for NovaTech: Stakeholders: faculty innovators, IP office, industry liaisons, research administration, finance, and students. Their concerns: Faculty → IP capture is too bureaucratic. IP Office → no single source of truth for patent data. Industry → poor visibility into available innovations. Finance → unclear cost attribution and licensing revenue tracking. So you need to know: Where the information breaks occur across research → IP filing → licensing → revenue. What applications handle these processes (e.g., RIMS, DMS, CRM, finance ERP). How data flows between them (manual or automated). Which processes are duplicated or delayed.
Goal: understand the real information landscape that affects cost, time-to-market, and experience.
2. “Given a set of information, how will you model, represent, capture, and analyse it?” Translation for NovaTech: Decide how to represent the current and target Application Architecture and Data Architecture: Use Application Communication Diagrams to show how RIMS, IP registry, and CRM connect. Use Data Dissemination or Entity Relationship Models (ERDs) for how invention data, inventor data, and license agreements flow. Use Information Flow Diagrams to map how data moves across departments. Choose modelling languages and tools: ArchiMate for high-level architecture views. UML for logical data structure or system interfaces. BPMN for workflow/value-stream integration. TOGAF Content Metamodel to maintain consistency.
Goal: use the right representation so that each stakeholder can understand how the architecture supports their concern.
3. “Are there reference models that allow you to skip to gathering and analysing rather than inventing?” Translation for NovaTech: Instead of designing from scratch, leverage proven reference models, for example: TOGAF TRM (Technical Reference Model) for layered services and infrastructure. Education Domain Reference Models (e.g., CAUDIT EA Framework, EDUCAUSE Core Data Service, or IMS Global standards). Industry Architecture Reference Models for Research Management, IP Management, and Innovation Ecosystems. Example: use a reference model for Research Lifecycle Management to identify standard data entities like Project, Researcher, Output, Patent, License, etc. This accelerates your work and ensures alignment with best practice, while still tailoring it to the university’s unique I2I focus.
Goal: stand on the shoulders of existing models — customize, don’t invent.
4. “What information is missing from the EA Landscape right now?” Translation for NovaTech: Identify data and model gaps in your current Enterprise Architecture repository: Missing current-state diagrams of the research-to-commercialization flow. Missing data lineage for IP-related datasets. No record of integration between CRM (industry partnerships) and finance (royalties). No governance model for shared data ownership between schools, labs, and central administration. Knowing what’s missing directs your next data-gathering activities (interviews, system inventories, etc.).
Goal: pinpoint missing architectural knowledge so your Phase C modelling is complete and trustworthy.
Summary Table: Step Purpose in HEI Context
What info do stakeholders need?
Identify where the digital IP-to-Income flow fails or is costly.
Info-flow maps, stakeholder concern matrix
How will you model/represent?
Decide on tools/notations for Application & Data Architecture.
ArchiMate diagrams, ER models, BPMN flows
Are there reference models?
Reuse proven education/IP/TOGAF models.
Adopt domain reference models, TRM/SIB
What info is missing?
Identify architecture gaps in EA repository.
Gap list for current state documentation
Why This Step Matters for Driving Down Sustained Costs: By selecting the right reference models, viewpoints, and tools, you: Avoid redundant modelling effort (cost saving). Ensure your architecture directly answers stakeholder concerns (efficiency). Build on best practices (reducing long-term maintenance cost). Identify missing or redundant systems early (targeted rationalization).
This Phase C discipline sets the foundation for cost-effective change planning in Phase E (Opportunities & Solutions) and sustainable cost reduction in Phase F (Migration Planning).
Step 2: Develop Target, Baseline, and Gap Architectures
Purpose (in TOGAF terms) (within Phase C: Information Systems Architecture): To describe the current state (Baseline) and the desired future state (Target) of your Application and Data Architectures, and then identify the gaps — the differences that represent required change. But — “just enough” modelling is the rule: don’t model every system; only model what matters to stakeholder concerns and traceability to business outcomes. A gap is anything that changes — a new system, a modification, data model update, new integration, or even a decommissioned legacy system.
Step Explained — in General (before HEI context)
1. Develop the Baseline Architecture
Describe the as-is applications, data entities, and information flows supporting current operations.
So everyone agrees on what exists — and what’s actually causing pain.
2. Develop the Target Architecture
Describe the to-be structure — the applications, data, and flows that would meet stakeholder needs and solve the issues.
Provides the vision of where the institution is heading.
3. Perform Gap Analysis
Identify what must change between baseline and target — additions, removals, modifications.
Defines the scope of projects and informs Phase E’s roadmap.
4. Apply “just enough” principle
Only document details that matter to the transformation or to traceability. Don’t waste effort describing stable, irrelevant parts of the landscape.
Keeps the work lean, relevant, and cost-effective.
Apply to the NovaTech University / IIRM Case Study: (A Higher Education Institute evolving into an IP-Driven Innovation-to-Income ecosystem)
Develop the Baseline Architecture (As-Is): Goal: Understand the current information system landscape supporting research, IP, and commercialization.
Applications
Separate Research Management System (RMS), IP Registry (Excel), CRM for industry partners, Finance ERP.
Siloed systems, manual updates, inconsistent data.
Data Architecture
Disconnected datasets — researcher data, patent records, project grants, license income — stored separately.
Broken information flow; duplicate entries; poor visibility.
Information Flow
Data flows manually via emails/spreadsheets between research office, IP cell, and finance.
Slow, error-prone, inconsistent — high sustainment cost.
Deliverables: Application Communication Diagram showing isolated systems. Data Entity Catalog (e.g., Research Project, Inventor, Patent, License). Information Flow Map showing manual, duplicated steps.
Develop the Target Architecture (To-Be) : Goal: Design the desired Application and Data Architecture that supports the integrated IP-to-Income value stream.
Applications
Unified Research-to-Commercialization Platform integrating RMS, IP registry, CRM, and Finance via APIs or shared data lake.
Seamless experience for faculty, IP managers, and partners.
Data Architecture
Shared Master Data for Inventions, Researchers, Partners, and Licenses; automated data lineage and audit trail.
One source of truth; reduced reconciliation effort.
Information Flow
Automated, event-driven data exchange between systems.
Reduced latency and error; faster commercialization; lower sustainment cost.
Deliverables: Target Application Interaction Diagram (showing integrations via middleware/API). Target Logical Data Model (harmonized entities). Information Flow Diagram (showing automated workflows).
Perform Gap Analysis: Goal: Identify the changes needed to move from Baseline → Target.
New Applications
IP Management Portal for faculty/industry.
Budget for design & rollout.
Application Enhancements
Add API layer to connect CRM and ERP.
Integration project required.
Data Gaps
No central “License Agreement” entity in current model.
Data model redesign needed.
Process Gaps
No automated workflow for patent filing approval.
Workflow automation required.
Decommissioning
Legacy spreadsheet-based IP registry.
Migration & retirement planning.
Deliverables: Gap Table (Baseline vs Target comparison). List of required changes (inputs to Phase E). Change Impact & Complexity Assessment.
Apply the “Just Enough” Principle: In NovaTech’s case: Do document: IP-related applications, research data models, integration points (they’re changing). Skip documenting in detail: Student Information System (if untouched), HR payroll (no change), learning management system (not part of the IP flow). Because they don’t affect the IP-to-Income transformation or drive sustained cost reduction, modelling them adds no value.
Why This Step Is Critical for Sustained Cost Reduction
Focus on change areas only
Avoids unnecessary analysis = reduces architecture effort cost.
Identifies high-impact system overlaps
Enables consolidation → lowers maintenance cost.
Clarifies data ownership and flow
Eliminates duplication → reduces ongoing data reconciliation effort.
Feeds the Roadmap (Phase E)
Gap list becomes the input to define work packages and sequencing.
Example: Deliverables Overview for NovaTech (Phase C, Step 2)
Baseline App Map
Diagram of current systems and flows
Identify where issues exist
Target App/Data Architecture
Future integrated landscape
Show desired end state
Gap Analysis Matrix
Differences between baseline and target
Define what must change
“Just Enough” Filter
Notes on areas excluded from scope
Keep the work efficient
In the NovaTech HEI case, developing Target, Baseline, and Gap architectures means describing just enough of the current and desired Application + Data landscape to identify what must change to fix broken information flows in the IP-to-Income process — focusing effort only on areas that drive down sustained costs or affect stakeholder outcomes.
Step 3: Identify the Work to Reach the Target — Considering Cost and Value
What the Step Means in TOGAF: Once you’ve defined the Baseline, Target, and Gaps, you must: Identify the concrete “work” (activities, initiatives, or projects) required to move from the Baseline to the Target. Estimate the cost and value of those changes. Check feasibility and stakeholder acceptance — because stakeholders might otherwise approve a beautiful but impossible architecture.
This is where architecture becomes actionable: it’s not enough to say what needs to change; you must describe what it takes to get there and why it’s worth it.
Key TOGAF Principles in This Step
“Work”
The specific projects or work packages needed to implement each gap — e.g., integration development, data migration, platform upgrade, process redesign.
“Cost of change”
Includes one-time cost (development, training, licensing) and ongoing cost (support, maintenance).
“Value”
The expected benefit — better user experience, faster time-to-market, reduced errors, lower maintenance cost, or strategic positioning.
“Practitioner guards value”
The architect ensures that the promised benefit justifies the cost — avoiding gold-plated or unrealistic targets.
“Without understanding work…”
Stakeholders might approve an architecture vision that’s too expensive, too risky, or operationally infeasible.
Apply to the NovaTech / IIRM Higher Education Case: Context Recap: NovaTech is transforming into a world-leading IP-to-Income Innovation University, integrating research, IP, partnerships, and commercialization systems. Phase C revealed information-flow gaps causing poor experience and high sustainment cost. Now we ask: “What actual work do we need to do to reach the target architecture?”
Step: Identify the Work Packages (What must be done): From the Gap Analysis, you extract the real “work” items. For NovaTech: Output: list of specific projects/work packages that move the enterprise toward the Target Architecture.
Siloed systems (RMS, IP, CRM)
Build middleware/API layer to integrate systems
Application development & integration
Manual IP registry (Excel)
Deploy IP Management Portal with workflow automation
New application implementation
Duplicate researcher data
Create centralized Researcher Master Data Service
Data architecture work
Inconsistent license revenue tracking
Integrate Finance ERP with IP Portal
Data interface development
Poor analytics on commercialization
Build Innovation Analytics Dashboard
BI / reporting project
Step : Estimate Cost and Complexity: For each work item, estimate both one-time and sustainment cost (Figures illustrative — in architecture we seek relative scale more than precision at this stage.):
Integration middleware
₹25 L
₹2 L/yr
Medium
IP portal
₹40 L
₹3 L/yr
High
Master data service
₹15 L
₹1 L/yr
Medium
ERP integration
₹10 L
₹1 L/yr
Low
Analytics dashboard
₹8 L
₹0.5 L/yr
Medium
Step : Assess Value/Benefit: Value here isn’t just monetary — it includes strategic and experiential value. Combine value + cost + feasibility to judge priority.
Integration middleware
Reduced data latency & duplication
Operational cost savings
IP portal
Better faculty/industry experience
Strategic differentiation
Master data service
Reliable IP ownership data
Compliance, accuracy
ERP integration
Transparent royalty flow
Financial efficiency
Analytics dashboard
Insight into innovation pipeline
Decision-making support
Step : Guard Value (Architect’s Role): As the Practitioner, your responsibility is to ensure: The proposed work aligns with enterprise goals (e.g., “IP-to-Income leadership”). The benefit outweighs the cost — both one-time and ongoing. The scope is achievable with available resources. Example guardrails for NovaTech: If integrating all systems at once is too costly, propose a phased roadmap (start with IP–CRM sync, then ERP). If a flashy analytics system doesn’t materially improve commercialization speed, defer it. Eliminate redundant systems rather than layering new ones. Thus, the architect acts as a value steward, not just a designer.
Step : Translate into Inputs for Phase E (Opportunities & Solutions): Once the work packages, costs, and values are clear: Group them into work packages or solution building blocks. Prioritize based on value vs cost. Use this to build the Implementation Roadmap in Phase E. Example categorization:
High value, low cost
ERP integration, master data service
Quick wins
High value, medium cost
IP portal, middleware
Core enablers
Medium value, medium cost
Analytics dashboard
Later phase (Phase E prioritization)
Why This Step Is Critical for HEI Transformation
Prevents unrealistic approval
Avoids “architectural dreams” that no one can fund or sustain.
Links value to investment
Stakeholders see tangible ROI (improved experience, reduced cost).
Prioritizes high-impact work
Enables a focused, phased roadmap instead of all-at-once chaos.
Protects institutional sustainability
Ensures changes reduce long-term operational costs, not increase them.
Summary: In NovaTech’s IP-driven innovation transformation, “Identifying the Work to Reach the Target — Considering Cost and Value” means translating each architectural gap into real, costed, and value-assessed work packages, so stakeholders approve feasible, high-value change rather than an idealized but unaffordable vision — thereby ensuring that the architecture truly drives sustained cost reduction and innovation outcomes.
Step 4: Resolving Impacts
What This Step Means in TOGAF Phase C: In Phase C (Information Systems Architecture), after defining target architectures, identifying gaps, and estimating work and value, the EA team must test and resolve potential conflicts or dependencies before finalizing the architecture. This involves analyzing:
How your candidate architectures (different possible designs for systems, applications, or data flows) interact with each other.
How proposed changes might impact in-flight projects (those already being implemented).
How the target architecture affects transition architectures (intermediate states before reaching the final architecture).
How these changes affect enterprise risk — both operational and strategic.
The Practitioner’s responsibility is to ensure the architecture:
Delivers business value without introducing unacceptable risk or conflict.
Fits within enterprise constraints — budgets, timelines, existing initiatives, and regulatory obligations.
Has a clear understanding of side effects — e.g., changing one application’s data model may break another system’s integration.
How to Apply “Resolving Impacts” in the HEI Case Study
Context Recap: The HEI (Higher Education Institution) faces: Poor student experience due to fragmented information flow. High sustainment costs due to redundant systems and unintegrated applications. A goal to reduce sustained cost and improve information flow using Phase C – Information Systems Architecture. Application of “Resolving Impacts” :
Step: 1. Explore Candidate Architectures: EA practitioners might propose multiple solutions such as: Option 1: A unified student information platform integrating admissions, academics, and finance modules. Option 2: API-based integration between existing legacy systems to improve data flow. Option 3: Migration to a cloud-based ERP suite. Each of these is a candidate architecture for Phase C.
Now, the EA practitioner must analyze their impact: Does Option 1 require decommissioning multiple existing systems (high cost, high benefit)? Does Option 2 still rely on fragile legacy databases (lower cost, limited benefit)? Does Option 3 require retraining staff or compliance adjustments?
Step 2. Assess Impact on Transition and Target States: Example: Moving to a unified student system (Target Architecture) might need an intermediate phase where data is first centralized in a shared data lake (Transition Architecture). The practitioner must evaluate if ongoing projects (e.g., a new e-learning portal) are compatible with this data transition or need adjustment. This avoids duplicated effort and ensures alignment across ongoing and future projects.
Step 3. Assess Impact on In-flight Projects: For example: The HEI might already be implementing a new “Library Management System.” If the new data architecture changes how student IDs are stored, that ongoing project might be affected. The EA practitioner must work with the Project Manager to realign data model specifications. This ensures changes don’t disrupt other deliverables or waste investment.
Step 4. Engage Enterprise Risk Management: Each architectural change introduces risk: Operational risk: downtime during migration. Data risk: inconsistencies or loss. Compliance risk: new data flows might affect GDPR/FERPA compliance. The EA team collaborates with Enterprise Risk Management to quantify and mitigate these: Implement data migration validation scripts, Plan parallel run before switching to the new system, Ensure data privacy compliance during system integration
Step 5. Document and Resolve Trade-offs: Finally, the EA practitioner documents: The impact analysis (cost, value, and risk per candidate architecture), The chosen trade-offs (e.g., choosing moderate cost with moderate benefit for faster implementation), The rationale for rejecting other options
Step 6. Deliverables Produced: During this step, the following artifacts are refined or produced: Impact Analysis Matrix (mapping architecture changes → affected systems/projects → risks), Risk Register updates, Architecture Decision Log, Stakeholder impact assessment
Summary (Applied to HEI): “Resolving Impacts” in Phase C ensures the HEI doesn’t just design an elegant architecture, but a realistic, low-risk, value-driven one — accounting for ongoing work, transition feasibility, and enterprise-level risk. It’s where architecture becomes actionable, not just conceptual.
Candidate Architectures
Unified student system vs API-based integration vs Cloud ERP
Compare each for cost, benefit, risk
Transition State Impact
Legacy systems phased out over 2 years
Identify dependencies and timing
In-flight Projects
Library & LMS implementations ongoing
Coordinate data & identity management
Enterprise Risk
Student data migration errors, downtime
Work with Risk team to plan mitigations
Outcome
Target Architecture selected, impacts resolved
Ready for Phase E (Opportunities & Solutions)
Step 5: Approval
What This Step Means in TOGAF Phase C: The Approval step formalizes the work done in Phase C — it’s where the target architecture (the future state for applications and data) is validated and endorsed by stakeholders. By this stage, the EA practitioner has: Explored multiple candidate architectures. Analyzed their costs, values, and risks. Assessed impacts on other projects and enterprise risks. Recommended the best-fit target architecture. Now, the practitioner must help the organization agree on: Which path forward (architecture option) to adopt. Why this choice makes the best trade-off between value, cost, risk, and feasibility. How it links back to strategic and business objectives. Key Activities:
Synthesize Findings
Compile all the architectural analyses, impacts, trade-offs, and stakeholder inputs
A clear architectural recommendation document
Facilitate Stakeholder Review
Present to business, IT, finance, and risk stakeholders
Consensus on the recommended Target Architecture
Perform Trade-Off Justification
Demonstrate how cost, value, and feasibility were balanced
Stakeholders see rationale and approve
Obtain Formal Approval
Secure sign-off from Architecture Board or Governance Committee
Target Architecture becomes official EA baseline for Phase E
Ensure Traceability
Maintain linkage from business goals → architectural decisions → target design
Enables future audit and roadmap planning
Why Approval Matters: Approval ensures: The future state is no longer theoretical — it’s authorized to guide implementation. There’s traceability from business drivers (like “improve student experience” or “reduce cost”) to architectural choices. The trade-offs are transparent — everyone understands what was gained, what was deferred, and why. It marks the transition point between architecture design (Phases A–D) and implementation planning (Phases E–F).
Applying the “Approval” Step in the HEI Case Study: Context Recap: Your HEI (Higher Education Institution) faces: Poor student experience due to disjointed data and applications. High sustainment cost from redundant systems and manual workflows. The goal in Phase C was to improve information flow and reduce long-term cost through Information Systems Architecture refinement. During Phase C, the EA team developed and compared three candidate architectures: Unified Student Information System (SIS). API-based integration of existing systems. Migration to a Cloud ERP platform. They performed gap analysis, impact assessments, and cost/value trade-offs.
Step-by-Step Application of Approval in HEI Context:
1. Summarize and Present Findings: The EA practitioner consolidates: Baseline vs Target Architectures (showing current fragmentation vs integrated data model). Gap analysis (highlighting needed changes in applications, data repositories, and integrations). Impact assessments (on cost, risk, and ongoing projects). Example deliverable: A “Target Architecture Recommendation” slide deck summarizing the options, impacts, and trade-offs.
2. Facilitate Stakeholder Dialogue: Stakeholders include: Registrar and Academic Affairs (student processes). IT Services (platforms, integration). Finance (cost of change). Risk & Compliance (data governance). The EA practitioner facilitates review workshops, ensuring each stakeholder’s concern — usability, cost, scalability, data privacy — is addressed in the decision.
3. Perform Trade-Off Justification: The EA team demonstrates: This shows that Option 2 is a tactical fix, Option 1 (Unified SIS) delivers strong value with acceptable risk, and Option 3 is long-term but costly — thus Option 1 becomes the approved target.
4. Secure Formal Approval: The practitioner submits the Target Information Systems Architecture for: Review by the Architecture Review Board (ARB), Endorsement from the Strategic IT Steering Committee, Once approved: The future architecture is defined (Unified SIS), Traceability is ensured (from the “improve student experience” business goal to the chosen target), Trade-offs are documented (e.g., not moving to cloud ERP immediately due to cost)
5. Transition to Next Phases: The approved Target Architecture feeds directly into: Phase E (Opportunities & Solutions): Defining the roadmap of implementation projects. Phase F (Migration Planning): Scheduling work packages and estimating resources
Deliverables in the HEI Approval Step
Target Architecture Document
Final blueprint of approved systems, data flows, and integrations
Architecture Decision Record (ADR)
Summarizes chosen option, rationale, and trade-offs
Approval Minutes / Sign-off Sheet
Governance artifact showing stakeholder endorsement
Traceability Matrix
Links objectives → requirements → architecture decisions
Summary: In the HEI case, “Approval” in Phase C means the EA Practitioner helps the university officially choose the best-fit Information Systems Architecture — one that balances value, cost, and feasibility, defines the future state, and provides traceability to the strategic goal of improving student experience while lowering sustained IT costs.
Purpose
Gain consensus and authorization for the selected Target Architecture
EA team seeks approval for Unified SIS
Value
Ensures alignment, traceability, and realistic trade-offs
Stakeholders understand cost vs value
Outcome
Approved architecture ready for implementation roadmap
Target IS Architecture drives Phases E & F
EA Practitioner Role
Facilitator and advisor guiding toward an informed, balanced decision
Present options, clarify impacts, secure buy-in
Step 6: The EA Repository
What It Means: In TOGAF, the Enterprise Architecture (EA) Repository is the central knowledge base that stores all architectural artifacts, models, principles, standards, reference architectures, viewpoints, and decisions. It is the starting point and the endpoint of every ADM phase — including Phase C (Information Systems Architecture). When we say: “Practitioners should start and finish with the contents of the EA Repository,” it means that every new architectural effort should: Begin by consulting what is already known, documented, and approved. End by updating the repository with new knowledge, models, and lessons learned. This prevents reinventing the wheel, ensures consistency, and builds a shared architectural memory for the organization.
Key Practitioner Tests: The practitioner applies three critical checks:
1. Availability Test
“Is the information that addresses the question at hand already available?”
Avoid duplicating work — reuse existing data, models, or viewpoints.
2. Guidance Test
“Is there a superior (enterprise-wide) architecture that guides or constrains this work?”
Ensure compliance with existing principles, standards, and target architectures.
3. Shortfall Test
“What is the minimum information needed to cover gaps in the EA Repository?”
Identify only what new data or models must be created to fill gaps relevant to this phase.
Why This Step Is Important: Prevents redundant modeling and analysis. Ensures alignment with enterprise standards and strategic direction. Builds traceability and reuse across projects. Anchors architectural decisions in governance and evidence, not intuition. It transforms the EA function from isolated documentation to a living knowledge system.
Applying This Step in the HEO (Higher Education Organization) Case Study: The HEO aims to become a world leader in IP-driven innovation, bridging technology, IP, and industry. It is undergoing a digital transformation to improve: Research-to-revenue (IP-to-income) value stream, Student–faculty experience, and Sustained cost efficiency in information systems. The EA team, during Phase C, is developing an Information Systems Architecture that will unify research management, IP management, student innovation platforms, and industry partnership systems. Step-by-Step Application of “EA Repository” in the HEO Case:
1. Start with the EA Repository: Before beginning the new architecture work, the EA Practitioner reviews: Existing business architecture artifacts (e.g., Research Value Stream, IP Commercialization Process). Current application and data architecture diagrams. Established architecture principles (e.g., “Reuse before build,” “Data is an institutional asset”). Reference architectures — perhaps a Digital Campus Reference Model or Research Data Management Framework. Prior project deliverables (e.g., pilot innovation platform architecture)
Purpose: To reuse and not re-create. For instance, if a data integration pattern for “student data APIs” already exists, it can be adapted for “IP asset data APIs.”
2. Apply the Practitioner Tests
Availability Test
Check if the repository already contains models for data entities like “IP asset,” “research project,” “industry partner.” If available, use and extend them.
Guidance Test
Verify if there’s an approved Digital Transformation Reference Architecture or Data Governance Policy that constrains how new information systems can be built. For example, must all new systems align to a “cloud-first” or “API-first” principle?
Shortfall Test
Identify missing information — e.g., there may be no current model for the IP commercialization workflow or the integration between research and finance systems. The practitioner then plans to create just enough architecture artifacts to fill these gaps.
3. Develop and Store New Artifacts: Once the Target Application and Data Architecture is developed (e.g., a new integrated “Innovation and IP Management System”), it is uploaded and indexed into the EA Repository. Artifacts might include: Application communication diagrams , Data entity relationship diagrams, Gap analysis matrices, Architecture decision records (ADRs) explaining trade-offs, Traceability links from objectives → requirements → architecture elements
Outcome: The repository evolves — it now includes new knowledge that will inform future initiatives.
4. Finish with the EA Repository: The practitioner ensures that: All newly created artifacts comply with repository standards (naming, metadata, tagging), Architecture decisions are recorded and cross-linked to earlier phases, Lessons learned from the Phase C exercise (e.g., integration complexity, data ownership issues) are documented
Outcome: The repository becomes richer, and future architects can leverage this work rather than starting from scratch.
Benefits to the HEO:
Reusability
The IP data model created in this project can later be reused by the Legal or Finance team.
Governance Alignment
Ensures all new systems comply with institutional digital strategy and data protection policy.
Efficiency
Reduces analysis time in future architecture phases — the repository acts as a “knowledge accelerator.”
Traceability
Every new IS design can be traced back to strategic goals like “Reduce cost of sustaining innovation infrastructure.”
Summary : In the HEO case, the EA Repository acts as the institution’s architectural memory — the practitioner begins by mining it for reusable models and ends by enriching it with the new Target Information Systems Architecture for IP–technology–industry integration, ensuring all future initiatives are aligned, efficient, and knowledge-driven.
Purpose
Ensure architecture work starts from existing knowledge and ends by enriching the institutional knowledge base
Begin by checking existing “Research & IP Systems Architecture”
Practitioner’s Questions
What’s already available? What guides me? What’s missing?
Reuse data model for “research projects,” add new for “IP commercialization”
Outcome
Updated EA Repository with reusable, governed artifacts
Repository now includes a full “Digital Innovation Architecture” package
Value
Reduces duplication, improves traceability, and supports continuous architectural learning
Ensures all digital initiatives align with the IP-driven innovation vision
Here are the steps we’ve already covered in Phase C (Information Systems Architecture):
✅ Select Reference Models, Viewpoints, and Tools
✅ Develop Baseline, Target, and Gap
✅ Identify the Work to Reach the Target (Considering Cost and Value)
✅ Resolving Impacts
✅ Approval
✅ The EA Repository
Netx is a critical cross-cutting theme in the TOGAF ADM lifecycle — Risk and Security Considerations across Phases B, C, and D.. Let’s unpack what this means in general, and then apply it specifically to your Higher Education Institution (HEI) case — which aims to be a world leader in IP-driven innovation and technology–industry education, with a digital transformation focus.
Overview: Risk & Security Across ADM Phases (B, C, D): In TOGAF, security and risk are not standalone activities — they are embedded within each architecture domain:
Phase B
Business Architecture
Business-level risk, trust, governance, control frameworks
Phase C
Information Systems (Applications & Data)
Functional security services, classification of data and systems
Phase D
Technology Architecture
Implementation of controls and mechanisms ensuring secure operations
Security matures as we move through the phases — from trust and policy (B), to information and system-level controls (C), to technical enforcement mechanisms (D).
Phase B: Business Architecture — Risk & Security: What It Means: At the business level, we are defining the trust framework, risk appetite, and governance model for the enterprise — not specific IT controls. Key security and risk tasks: Identify business assets that must be protected (e.g., intellectual property, student and partner data), Define the trust relationships between internal and external actors, Apply or align to enterprise control frameworks (like ISO 27001, COBIT, or NIST) and Identify high-level business risks (e.g., IP leakage, partner data misuse, loss of reputation)
In the HEI Case: In your IP-driven Higher Education Organization: The business-level trust framework defines how faculty, students, and industry partners collaborate and share innovation data safely. The business risks include: Leakage of patentable research data, Unauthorized publication of IP before filing, Misuse of student data by partner systems, Applicable frameworks: ISO 27001 for information security, and COBIT for IT governance.
Deliverable Example: A Business Risk and Trust Model showing which stakeholders can access what kind of research or innovation data, under what legal/ethical constraints.
Phase C: Information Systems Architecture — Risk & Security: What It Means: This phase focuses on application and data architecture — so security considerations move from business trust to functional security services and information classification. Key practitioner activities: Identify security services (authentication, authorization, audit logging, data encryption, access control, integrity validation, etc.), Define security classifications for data and systems (e.g., public, internal, confidential, restricted), Map security requirements to application and data components, Assess information flow vulnerabilities — where insecure handoffs occur between applications or partners, Ensure alignment with business risk posture defined in Phase B.
In the HEI Case: Context: The HEI is integrating digital platforms for: Research & IP Management, Student Innovation Projects, Industry Collaboration Portals, Financial Systems for royalty and IP income tracking
Application in Practice: The EA Practitioner, working in Phase C, ensures: Functional Security Services are Defined: SSO (Single Sign-On) across research, student, and partner portals, RBAC (Role-Based Access Control) — e.g., only authorized IP officers can view patent documentation, Data encryption for IP records in transit and at rest, Secure APIs for partner integration (OAuth 2.0, TLS), Audit logging for IP creation and modification events. Security Classification: Public Data: Published research abstracts, Internal Data: Student innovation project metadata, Confidential Data: Patent drafts, licensing negotiations, Restricted Data: Financial terms of IP contracts, proprietary algorithms. Information Flow Assessment: The EA identifies potential risks in information exchange between: Research database ↔ Industry collaboration platform, Student project system ↔ IP management system, → Mitigation: Enforce API-level security and data masking policies. Document in Architecture Artifacts: Annotate data models with security classification labels, Add security services as application components in the Application Architecture views, Capture these in the EA Repository for governance traceability
Deliverable Example: A Security-Enhanced Application and Data Architecture View, showing data flows, system boundaries, and associated security services.
Phase D: Technology Architecture — Risk & Security: What It Means: By Phase D, the Technology Architecture implements the required security controls and mechanisms defined earlier. Key activities: Ensure the technical infrastructure (network, cloud, storage, compute) includes required controls: Firewalls, IDS/IPS, Secure VPN access, Encryption services, Backup and recovery mechanisms, Security monitoring and SIEM integration, Verify the efficiency and effectiveness of these controls, Conduct a technical risk assessment — e.g., cloud hosting risks, service continuity
In the HEI Case: For the HEI’s cloud-based digital innovation platform: The Security Architect ensures: Cloud provider adheres to ISO 27001, GDPR, and institutional data residency policies, Database encryption keys are managed securely, Multi-factor authentication (MFA) is enforced for admin access, Network segmentation isolates student, faculty, and partner systems, Technology Risk: Evaluate potential vendor lock-in or data migration risks.
Deliverable Example: A Technology Security Architecture Overview, showing infrastructure zones, controls, and compliance mappings.
Integration Across Phases (B → C → D): Key Takeaways for the EA Practitioner: Security is cumulative: Phase C builds on business-level trust from Phase B and sets up controls for implementation in Phase D. In Phase C, you design how security is functionally delivered — not just as policies but as architecture services. For the HEI, this means ensuring every system that handles intellectual property, innovation data, and partner collaboration is secure by design, classified appropriately, and aligned with institutional governance and compliance frameworks.
Phase B – Business Security
Define trust and risk framework
Create “Research–Industry Trust Framework” for IP collaboration
Phase C – IS Security
Identify functional security services and classify data
Define SSO, RBAC, encryption; label IP data as Confidential/Restricted
Phase D – Tech Security
Implement technical controls
Enforce MFA, encrypted cloud storage, and network isolation
In the HEI case, Risk and Security in Phase C means embedding security functions and data classification directly into the Information Systems Architecture — ensuring that as the institution digitizes its IP and innovation ecosystem, it remains trusted, compliant, and resilient from the start.
Step 3: Relevant Information to Produce Outputs Valuable to the Architecture Development
In the Higher Education Institution (HEI) innovation case, the Enterprise Architecture (EA) practitioner begins Phase C by consolidating all relevant contextual information from previous ADM phases to ensure that the Information Systems Architecture directly supports institutional goals. The practitioner aligns the system design with business principles, goals, and drivers such as “fostering secure open innovation,” “enhancing IP commercialization efficiency,” and “enabling digital collaboration with industry partners.”
Inputs from Phase A (Architecture Vision) define the scope of the problem—improving the innovation and IP management ecosystem—and identify key stakeholders such as faculty researchers, students, IP officers, and industry collaborators. The agreed Architecture Vision—a “unified, secure, and collaborative digital ecosystem for innovation and research”—serves as the guiding reference.
From Phase B (Business Architecture), the practitioner draws on the capability map, value streams, and process dependencies to identify where new or improved information systems are needed. Supporting documents such as the Request for Architecture Work, Approved Statement of Architecture Work, Tailored EA Framework, and Architecture Principles help maintain governance and consistency with enterprise policy. The Enterprise Continuum and Architecture Repository provide reusable models, reference patterns, and integration standards to accelerate development.
By integrating this information, the practitioner ensures that Phase C outputs—Application Architecture and Data Architecture models—are relevant, traceable, and valuable. These architectures explicitly demonstrate how information systems will address business capability gaps, support secure IP lifecycle management, and enable end-to-end digital collaboration across the HEI’s innovation ecosystem.
Before you start designing application and data architectures (the core of Phase C), you must bring together all relevant inputs that will anchor your design to business reality — ensuring your architecture decisions directly support organizational goals, constraints, and stakeholder needs.
This step is essentially about alignment and traceability: Alignment → with business principles and goals. Traceability → to Phase A (Architecture Vision) and Phase B (Business Architecture) outputs
So, in Phase C, your job as the Enterprise Architect is to use this relevant information to guide, constrain, and justify all the information system design decisions you make.
1. Business Principles, Goals, and Drivers: Meaning: These define why the enterprise is doing this architecture work and what success looks like. They are the anchor points to keep your system design relevant to organizational strategy.
In Phase C (for HEI): They set the context and boundaries for how you design the data and application systems. Example – HEI Context:
Business Principles
“All IP data must be secured by design”, “Collaboration platforms must support openness with accountability.”
Business Goals
“Enhance innovation commercialization efficiency by 30%”, “Integrate industry partners into the digital ecosystem.”
Business Drivers
National innovation policy, competitive IP environment, need for faster research-to-market transitions.
What it means for Phase C: When designing data and application architectures, you ensure: Applications enable secure collaboration across students, faculty, and industry. Data architecture supports traceable IP workflows. Systems are interoperable and scalable to handle growth and partnerships.
Outcome: Architecture that produces direct business value — e.g., a unified innovation data platform aligned with institutional goals.
2. Relevant Information from Phase A (Architecture Vision): Meaning: Phase A defines what problem you are solving, who cares about it, and what success looks like at a high level.These guide you in shaping the technical solution (Phase C) so that it remains fit for purpose. Phase A Inputs to Use: Scope of the problem: The boundaries — what’s in/out. Stakeholders and their concerns: Who needs what from the architecture. Architecture Vision: The agreed “future state” snapshot that all stakeholders support. In Phase C (for HEI): Scope: You focus only on systems supporting innovation, IP, and collaboration (not the entire university ERP). Stakeholders:Faculty researchers → need IP management tools. Industry partners → need secure access to research outputs. Students → need innovation project tracking systems. Administration → need performance and compliance dashboards. Architecture Vision: “A unified, secure, and collaborative digital ecosystem that integrates innovation, research, and IP management processes.”
Outcome: Every data and application component you design in Phase C must be traceable back to this agreed vision and stakeholder set.
3. Architecture Development Phase B Inputs: Meaning: Phase B (Business Architecture) defines how the organization operates, key capabilities, and process dependencies. These provide the functional blueprint for the Information Systems you will design in Phase C. You now translate the business view (Phase B) into application and data views (Phase C). Key Phase B Inputs Explained:
Request for Architecture Work
The formal mandate to perform this architecture
Ensures you stay within approved scope — e.g., “Develop IS architecture for innovation and IP ecosystem.”
Business Principles, Goals, Drivers
Business context, as above
Used to ensure systems deliver measurable business value.
Capability Assessment
Identifies strengths/gaps in current capabilities
Guides where new applications or integrations are needed. E.g., “Weak IP tracking capability” → design an IP lifecycle management system.
Communications Plan
Defines stakeholder communication approach
Helps align system design and rollout with user readiness and adoption plans.
Organizational Model for EA
Defines who governs architecture work
Clarifies decision-making authority for selecting application platforms.
Tailored Architecture Framework
The EA framework adapted to HEI’s environment
Ensures consistency with HEI’s processes, e.g., adapting TOGAF to academic structures.
Approved Statement of Architecture Work
The formal project charter for this architecture effort
Confirms deliverables, scope, and schedule for the Information Systems Architecture.
Architecture Principles
Rules and guidelines (e.g., “Data is an enterprise asset”)
Used to govern all design decisions in Phase C.
Enterprise Continuum & Architecture Repository
Central store of models, standards, and previous architectures
Helps reuse models (e.g., templates for student systems, existing API patterns).
Architecture Vision
High-level target model and value proposition
Ensures continuity between conceptual (Phase A) and logical (Phase C) design.
Draft Architecture Definition Document (ADD)
Early outputs from Phase B
Forms the foundation for completing the Phase C ADD with IS views.
Outcome: You integrate these inputs to produce valuable, coherent outputs in Phase C — namely the Application Architecture and Data Architecture models that enable the HEI’s innovation ecosystem.
Summary: What This Step Achieves in Phase C
Alignment
Ensures the Information Systems design aligns with business priorities, not just technical convenience.
Traceability
Links every system and data model element back to business goals and stakeholder needs.
Reuse
Leverages repository artifacts and past architectures for efficiency and consistency.
Governance
Ensures compliance with organizational EA principles and control frameworks.
In the HEI Case – How to Apply It Practically: Here’s how an EA practitioner at the HEI would apply this step: Gather Context: Review the HEI’s business principles (e.g., “Foster secure open innovation”), Review Phase A outputs (Vision, Stakeholders), Review Phase B deliverables (Capabilities, Business Processes, Architecture Principles), Extract What’s Relevant for IS Design: Identify business capabilities needing digital support (e.g., “IP Lifecycle Management”), Identify stakeholder data needs (e.g., students need project dashboards; IP officers need patent filing data), Identify governance or security principles (e.g., “Data classified and secured per institutional policy”). Use These to Drive Phase C Outputs: Design Application Architecture that supports all key business processes → e.g., Integrated Research Collaboration Portal, Design Data Architecture that aligns with classification and sharing policies → e.g., Unified IP Data Repository with role-based access, Document these in the Architecture Definition Document (ADD), showing alignment back to business goals.
Result: Phase C outputs (data models, application landscapes, integration diagrams) are not just technically sound, but strategically valuable, directly supporting HEI’s mission to become a globally competitive innovation hub.
This step ensures that when you develop the Information Systems Architecture (Phase C) for the HEI, you do it with full awareness of the business vision, scope, stakeholder needs, and prior architectural inputs — so that your outputs are aligned, reusable, and valuable to the institution’s digital transformation.
Step 4: How to Apply Phases B, C, and D — and How They Contribute to the Architecture Development Work
1. Conceptual Explanation (TOGAF View): This step explains how the three architecture development phases — Business, Information Systems, and Technology — work together to: Define the as-is (baseline) and to-be (target) enterprise. Identify gaps between current capabilities and desired future outcomes. Determine the work packages required to close those gaps. Build stakeholder-approved domain architectures (Business, Data, Application, Technology). Each phase builds on the prior one and contributes distinct insights:
Phase B – Business Architecture
What the enterprise needs to do
How does the current business fail to meet stakeholder goals?
Business Capability Map, Value Streams, Target Business Model
Phase C – Information Systems Architecture
How information and systems enable those needs
What changes in data and applications are needed to deliver those capabilities?
Data Architecture, Application Architecture, Gap Analysis
Phase D – Technology Architecture
What technology supports the systems
What infrastructure and technical capabilities are required?
Target Technology Architecture, Technology Standards, Infrastructure Blueprint
All three phases feed into Phase E (Opportunities & Solutions), which translates these architectures into actionable projects and roadmaps.
2. Application to the HEI Case Study: IP-Driven Innovation Ecosystem: Context Recap: The university (HEI) is evolving from a traditional academic institution into an innovation-led, IP-driven ecosystem that connects research, intellectual property, and industry collaboration through digital transformation.
Applying Phase B – Business Architecture: Purpose: Define what the institution wants to achieve and where current operations fall short. Discover Business Gaps: Identify that current academic and research workflows are siloed — IP management, industry outreach, and research funding processes are disjointed. Develop Target Capabilities: Define new capabilities such as:“End-to-end IP lifecycle management”. “Industry collaboration management”. “Innovation analytics & commercialization tracking”. Value Streams: Map the “Idea → IP → Industry → Income” value stream. Business Drivers: Global competitiveness, translational research outcomes, and sustainable income generation.
Output: Target Business Architecture (value streams, capabilities, stakeholders, governance).
Applying Phase C – Information Systems Architecture: Purpose: Define how information systems and data will enable the new business capabilities. Data Architecture: Establish a unified IP and research data model integrating researcher profiles, patents, publications, and partnership data. Define data governance policies for sensitive IP and industry data. Plan data migration from legacy academic databases to a new integrated research-IP platform. Application Architecture: Identify core applications: IP Management System, Research Collaboration Portal, CRM for industry relations. Define application interfaces for cross-campus integration. Address information flow deficiencies that caused poor partner/learner experience.
Output: Target Data and Application Architectures, showing how digital systems enable the new IP-to-market value chain.
Applying Phase D – Technology Architecture: Purpose: Define what technology platforms and infrastructure will support the systems. Adopt cloud-based platforms for scalability and collaboration. Ensure security and access control for IP data (in alignment with risk and compliance frameworks). Introduce AI tools for research analytics and patent mapping. Use APIs and integration middleware for data exchange between academic, industry, and government systems.
Output: Target Technology Architecture — defining hosting, networking, integration, and security mechanisms supporting the digital ecosystem.
3. Integrative Outcomes Across Phases B–C–D
Approved Domain Architectures
Business, Information Systems, and Technology architectures validated by stakeholders (research heads, IP office, CIO, industry partners).
Gaps Identified
Gaps in data integration, legacy applications, missing collaboration tools, lack of unified IP management.
Work Packages
Specific projects: e.g., “Develop Research-IP Portal,” “Integrate CRM with Patent DB,” “Deploy Secure Cloud Platform.”
Stakeholder Alignment
Consensus built through trade-offs between cost, value, and risk.
The Architecture Repository’s Role: Throughout these phases, the EA team checks the Architecture Repository for reusable artifacts: Reference models for CRM or IP systems. Data governance frameworks. Security and compliance models (e.g., ISO 27001, FAIR data principles). They update the repository with new artifacts developed during this engagement, ensuring traceability and reuse in future projects.
Summary — What This Step Means for the HEI Case: In the HEI scenario, applying Phases B → C → D systematically: Converts strategic ambition (“world leader in IP-driven innovation education”). Into business, information, and technology architectures that are: Aligned with stakeholder goals, Realistic to implement, Cost-effective, and Secure and compliant. This ensures the university’s digital transformation is not just visionary, but architecturally sound, value-driven, and operationally executable.
Step 5: Information Relevant to Phase C (Data and Applications) — Explanation
Purpose: Before starting design or analysis in Phase C, the Enterprise Architecture (EA) team must ensure it has all relevant information, artifacts, and contextual understanding needed to: Create Data Architecture and Application Architecture models that are aligned with business goals. Identify gaps between the current and target state. Define the work packages that can realize those changes.
This information comes from: External and organizational reference materials. Non-architectural inputs (like governance and communication plans). Outputs from previous ADM phases (A & B). Existing artifacts within the Architecture Repository
Essentially, Phase C sits in the middle of the ADM cycle and acts as a translation point — converting business goals (from Phase B) into digital and data systems that can make those goals achievable.
How This Step Applies to the HEI Case: Let’s go section by section and translate it into your case context — a Higher Education Institution (HEI) transforming into an innovation-focused, IP-driven digital ecosystem.
1. Reference Materials External to the Enterprise: These are global or sectoral frameworks that influence your Data and Application Architectures. For the HEI, these may include: UNESCO and WIPO guidelines for research and intellectual property data. ISO/IEC 27001 (information security management) for IP protection. COBIT or ITIL frameworks for IT governance and service delivery.FAIR Data Principles (Findable, Accessible, Interoperable, Reusable) for research datasets. Higher Education reference models for digital learning or research collaboration. How applied: The EA team uses these references to ensure the university’s data and systems meet both international standards and best practices for IP security, data interoperability, and digital trust.
2. Non-Architectural Inputs: These inputs come from organizational planning and governance.
Request for Architecture Work
Formal mandate from the University’s Innovation and Digital Council to design the architecture for the “IP-to-Income” ecosystem.
Capability Assessment
Evaluation of current digital and data capabilities — identifies gaps like fragmented IP databases, limited analytics tools, and low system integration.
Communications Plan
Plan for stakeholder engagement — ensures communication across faculty, IP office, IT services, and industry partners during design.
3. Architectural Inputs: These are formal architecture documents and resources that guide Phase C activities.
Organisational Model for EA
Defines EA roles: Chief Architect, Data Architect, Application Architect, and Domain Experts (Research, IP, Industry).
Scope of Organisations Impacted
Faculties, research centers, IP office, and industry liaison cells.
Tailored Architecture Framework
The university adapts TOGAF with extensions for academic research and IP data governance.
Data and Application Principles
“Data as a Strategic Asset”, “Secure by Design”, “Interoperability First”, and “Reuse before Build”.
Statement of Architecture Work
Defines objectives: integrate research, IP, and industry data; improve partner experience; reduce sustained cost.
Architecture Vision (from Phase A)
“A unified digital platform for innovation-to-income across research, IP, and industry.”
Architecture Repository
Holds baseline system inventories, process maps, data dictionaries, and prior project models.
Reusable Building Blocks
Existing CRM modules, learning management systems, and legacy research databases reused for integration.
Draft Architecture Definition Document (ADD)
Contains the first-cut structure of data and application components.
Draft Architecture Requirements Specification (ARS)
Details stakeholder concerns (e.g., data protection for industry IP, analytics for commercialization).
Business Architecture Components of Roadmap
Business-level priorities (from Phase B) mapped to upcoming digital initiatives (e.g., “IP Analytics Dashboard”).
4. Essential Knowledge: This defines the key analytical mindset the EA practitioner must bring during Phase C:
How does the current enterprise fail to meet stakeholder preferences?
Researchers and IP officers face delays due to disconnected data systems; industry partners lack visibility into collaboration progress.
What must change to meet stakeholder preferences (Gaps)?
Integration of IP, research, and partnership data; real-time collaboration tools; analytics dashboards for commercialization.
What work is necessary to realize the changes (Work Packages)?
Develop IP data hub, integrate CRM with research database, deploy secure collaboration portal, migrate legacy data.
How do stakeholder priorities adjust with value, effort, and risk?
IP office prioritizes compliance and data integrity; researchers value ease of use; leadership emphasizes cost control and income generation.
5. Outcome: By applying all these inputs and essential knowledge, the EA team can: Produce a Target Data Architecture (common IP & research data model, governed and secure). Produce a Target Application Architecture (integrated CRM + IP Management + Research Collaboration Portal). Identify Gaps (legacy systems, missing APIs, security vulnerabilities). Develop Work Packages to implement changes — each aligned with stakeholder value and feasibility.
Summary — What This Step Means for the HEI Case
Purpose
Gather all relevant business, data, and architectural inputs before designing Data & Application Architectures.
Why It Matters
Ensures alignment with academic, research, and industry stakeholders before any system design starts.
Outcome
Actionable Data & Application Architectures that trace directly back to business goals (IP monetization, digital collaboration).
EA Value Add
Moves from scattered digital tools to a coherent, value-based architecture roadmap grounded in global standards.
Step 6: Information needed in Phase D to produce outputs relevant to the architecture development
Purpose of Phase D: Phase D develops the Technology Architecture, which describes the logical and physical technology components (hardware, software platforms, networks, cloud, security layers, etc.) required to enable the target Information Systems Architecture (Phase C) and Business Architecture (Phase B). In simple terms, Phase D answers: “What technology infrastructure and platforms do we need to implement the data and applications designed in Phase C — securely, efficiently, and in alignment with enterprise goals?”
So, Step 6 is about identifying what information is needed to produce Phase D outputs — such as the Target Technology Architecture, gap analysis, and architecture roadmap for the technology layer. The table below summarizes what each category of input means:
Reference Materials External to the Enterprise
Industry standards, technology reference models, vendor information, open architectures
Ensures compatibility and modernity (e.g., cloud frameworks, ISO/IEC standards)
Non-Architectural Inputs
Mandates, governance, capability assessments
Provides organizational readiness and constraints
Architectural Inputs
Artifacts from earlier phases (A–C) — Business, Data, Application architectures
Ensures continuity and traceability from strategy to technology
Essential Knowledge
Analytical understanding of stakeholder needs, gaps, and priorities
Guides design and prioritization of work packages
Applying Step 6 to the HEI Case: Context Reminder: The HEI’s digital transformation goal is to integrate research, IP management, and industry partnerships through a secure, scalable, and innovation-oriented digital ecosystem. Phase D now focuses on designing the technology backbone — infrastructure, platforms, networks, and security — that will host and support those applications and data services.
(A) Reference Materials External to the HEI
Architecture Reference Models
TOGAF TRM (Technical Reference Model), Open Academic Analytics Framework (OAAF) for research data systems.
Product Information on Candidate Technologies
Evaluations of cloud vendors (AWS, Azure, GCP) for hosting research & IP data; LMS vendors for academic integration; open-source IP management systems.
Standards and Frameworks
ISO/IEC 27001 (security), NIST SP 800-53, ITIL 4 (service management), and national education ICT standards.
Purpose: These ensure the HEI’s technology design aligns with global standards and interoperates with research and industry ecosystems.
(B) Non-Architectural Inputs
Request for Architecture Work
The University Council’s directive to build a “Digital Innovation Infrastructure for IP Commercialization and Research Collaboration.”
Capability Assessment
IT infrastructure maturity assessment showing current gaps — e.g., limited cloud use, siloed research servers, weak cybersecurity posture.
Communications Plan
Ensures coordination across IT Services, Research Centers, IP Office, and external tech partners.
(C) Architectural Inputs
Organisational Model for EA
Defines technology architecture roles (e.g., Cloud Architect, Network Architect, Security Lead). Identifies impacted organizations — IT, Research, and Innovation Office.
Maturity Assessment and Gaps
E.g., legacy on-prem systems vs. planned hybrid-cloud infrastructure; lack of integrated security management.
Constraints on Architecture Work
Budget ceilings, existing vendor contracts, national data residency regulations.
Governance & Support Strategy
Defines how IT operations, support, and maintenance will work post-deployment (e.g., shared services model).
Tailored Architecture Framework
Adapts TOGAF to include education-sector reference architectures and cloud adoption frameworks.
Technology Principles
“Cloud-First, Secure-by-Design, Interoperable Systems, Open Standards Preference.”
Statement of Architecture Work
Defines Phase D scope: design technology architecture for research-IP integration, analytics platform, and digital collaboration tools.
Architecture Vision (from Phase A)
A “Smart Innovation Ecosystem” connecting students, researchers, IP creators, and industry partners on a unified digital platform.
Architecture Repository
Holds reusable assets — templates for APIs, security policies, server configurations, integration patterns.
Draft Architecture Definition Document (ADD)
Contains baseline tech stack (current servers, networks, databases) and target stack (cloud-native microservices, API gateway, data lake).
Draft Architecture Requirements Specification (ARS)
Includes technical requirements like encryption, performance, high availability, and integration interfaces.
Outputs from Previous Phases
Business, Data, and Application architectures define what technologies must support (e.g., IP Analytics Dashboard, Research Data Hub).
(D) Essential Knowledge
How does the current enterprise fail to meet stakeholder preferences?
Slow research data access; IP system not integrated; security gaps; poor scalability for industry portals.
What must change to meet those preferences (Gaps)?
Shift to cloud infrastructure; implement secure single sign-on (SSO); deploy enterprise data lake; automate backups and disaster recovery.
What work is necessary to realize the changes (Work Packages)?
Work packages like: “Cloud Migration for Research Data,” “Deployment of Secure IP Data Hub,” “Network Upgrade for High-Performance Computing.”
How do stakeholder priorities adjust with value, effort, and risk?
IT team prioritizes stability; researchers prioritize speed and access; leadership prioritizes ROI and compliance. Balancing these defines roadmap sequencing.
Outcomes of This Step for the HEI Case: After processing these inputs and knowledge, Phase D for the HEI would produce:
Target Technology Architecture
Defines technology components (servers, cloud platforms, networks, security layers, middleware). E.g., hybrid cloud setup with centralized data lake and identity federation.
Baseline vs. Target Gap Analysis
Shows gaps like outdated servers, missing integration middleware, lack of redundancy.
Technology Standards Catalog
Specifies preferred technologies (databases, middleware, security tools).
Architecture Roadmap (Tech Layer)
Prioritized list of technology initiatives: cloud migration, security enhancement, network modernization.
Updated Architecture Definition & Requirements Documents
Reflect the new technology blueprint and constraints.
Summary — What This Step Means for the HEI Case
Phase Objective
Define the technology infrastructure to support IP-driven innovation and digital transformation.
Inputs Used
Business, Data, and Application architectures; standards; capability assessments.
Core Focus
Cloud strategy, integration, scalability, performance, and security controls.
Outputs
Target Technology Architecture, gap analysis, roadmap, and standards.
Value for HEI
Enables secure, scalable, and sustainable digital infrastructure for research-industry collaboration and IP monetization.
Step 7: Outputs of Phases B, C, and D necessary to proceed with the Architecture Development work
Phases B, C, and D correspond to the core architecture development domains:
B
Business Architecture
“What the organization does” — processes, functions, roles, governance
C
Information Systems Architecture
“What information and applications enable the business” — data & applications
D
Technology Architecture
“What technology enables those applications” — platforms, networks, infrastructure
Step 7 asks: After performing Phases B, C, and D, what tangible outputs and outcomes must exist before we proceed to later stages (Phase E: Opportunities & Solutions, and beyond). So, this step is about consolidating, refining, and validating the outputs of these three architecture domains.
Key Outputs Required from Phases B, C, and D
1. Refined and Updated Deliverables from the Architecture Vision (Phase A): Update the Statement of Architecture Work if the scope, constraints, or priorities changed. Revisit or validate Architecture Principles — add new ones if discovered (e.g., “Cloud-first” may emerge in Phase D). Ensure all work remains aligned with the Architecture Vision (the overall goal).
2. Draft Architecture Definition Document (ADD): The ADD now includes detailed: Business Architecture views (Phase B). Data & Application Architectures (Phase C). Technology Architecture (Phase D). It defines both Baseline and Target states for each domain and the gaps between them.
3. Draft Architecture Requirements Specification (ARS): Collects all architecture requirements (functional and non-functional) gathered or refined through B–D. Includes traceability back to stakeholder needs, risks, and business goals. Example: “The IP Management Portal shall support role-based access for researchers and industry partners.”
4. Architecture Roadmap (Domain Components): Each phase contributes to parts of the Architecture Roadmap: Phase B → Business changes and process initiatives. Phase C → Information and system integration initiatives. Phase D → Technology upgrade and modernization initiatives.
5. Outcomes: A set of domain architectures approved by stakeholders (Business, Data, Application, and Technology). A clear understanding of gaps and work packages to address them — forming the foundation for implementation planning in later phases.
Applying Step 7 to the HEI Case Study: Context: Your HEI (Higher Education Institution) is transforming into a digital innovation ecosystem, enabling research collaboration, IP commercialization, and industry partnership through integrated data, applications, and technology systems. Now let’s see how the outputs of Phases B, C, and D materialize in this case.
Phase B: Business Architecture Outputs
Business Processes & Functions
Defines key business capabilities supporting the HEI’s innovation and IP goals.
Research collaboration, IP registration, technology transfer, partner engagement.
Roles & Governance
Defines ownership, decision rights, and responsibilities.
Research Office, IP Cell, Industry Liaison Office.
Business Principles & Policies
Ensure business consistency and compliance.
“All research outputs must pass through IP verification before publication.”
Gaps Identified
Inefficient manual IP tracking, unclear ownership, poor collaboration workflows.
These drive automation and integration needs in later phases.
Phase C: Information Systems Architecture Outputs
Data Architecture
Defines how institutional data (research, IP, collaboration, funding) is structured, stored, and governed.
Central Research Data Repository; IP Metadata Standards; Unified Data Dictionary.
Application Architecture
Defines the core systems supporting data flow and business processes.
IP Management Portal, Research Analytics Dashboard, Partner Collaboration Platform.
Integration Model
Shows how systems communicate.
API Gateway connecting LMS, IP Office, Research Data Lake, ERP.
Gaps Identified
Data silos, redundant systems, no single research data source.
Drives design of data lake and unified access in Phase D.
Phase D: Technology Architecture Outputs
Technology Stack Design
Logical and physical technology blueprint supporting Phase C systems.
Cloud-based hybrid infrastructure (Azure + On-prem), API management layer, secure VPN, SSO.
Security Architecture
Security controls and mechanisms.
Identity federation, encryption, backup & DR policy.
Technology Standards
Approved tech products, tools, and configurations.
Database (PostgreSQL), Middleware (Kong API Gateway), Analytics (Power BI), Cloud (Azure).
Gaps Identified
Legacy servers, lack of security monitoring, poor network bandwidth.
Drives modernization roadmap and budget proposals.
Integrated Outcomes (Across Phases B–D)
Updated Statement of Architecture Work
Includes refined scope after understanding IT constraints and business priorities.
Scope expanded to include external partner portal.
Validated Principles
Reviewed and updated architecture principles.
“Secure-by-Design,” “Open Data Standards,” “API-first Integration.”
Draft ADD
Comprehensive documentation of business, data, application, and technology architectures.
Includes models for research process, data lake schema, cloud tech stack.
Draft ARS
Consolidates all architecture requirements (technical, security, compliance).
e.g., “Data retention policy for research data = 10 years.”
Architecture Roadmap
Sequenced work packages for transformation.
Year 1: Data Lake & Cloud Infra; Year 2: IP Management Portal; Year 3: Analytics Dashboard & Partner Portal.
Outcomes of Step 7 for the HEI Case
Approved Domain Architectures
Business, Data, Application, and Technology architectures reviewed and approved by stakeholders (IT, Research, Governance).
Gap Analysis Completed
All areas where current HEI capabilities fall short identified and documented.
Work Packages Defined
Projects and initiatives designed to close each gap — with dependencies, costs, and priorities.
Traceability Established
Each decision traces back to stakeholder needs and business goals from Phase A.
Ready for Next Phase (E)
Foundation set to move into Opportunities & Solutions — identifying solution building blocks, transition architectures, and implementation sequencing.
Summary — Meaning of Step 7 for the HEI Case
Step Purpose
To consolidate and validate all architecture domain outputs before transitioning to implementation planning.
Applied to HEI
Produces an integrated “Digital Innovation Architecture” blueprint for the university — covering people, process, data, applications, and technology.
Value
Ensures alignment between vision, architecture, and practical execution — making the digital transformation realistic, traceable, and cost-justified.
2: Unified Enterprise Architecture Strategy
GlobalFin is a leading financial institution headquartered in London, with a sprawling presence in over 50 countries. Established in the early 2000s, the bank has grown both organically and through strategic acquisitions. Over the years, it has diversified its services, offering everything from retail banking and wealth management to sophisticated investment banking solutions. The enterprise architecture team at GlobalFin is central to ensuring that the bank's myriad of systems communicate effectively. They work in tandem with the IT, operations, and individual department heads. A key process in their operations is the real-time processing of transactions, which requires seamless integration across various platforms. However, due to the bank's rapid growth, decentralized decision-making in the past, and the integration of acquired entities with their own IT systems, different departments have adopted different technologies and standards. This patchwork of systems, while functional, often feels like a jigsaw puzzle that doesn't quite fit together, leading to inefficiencies and challenges at multiple levels. The lack of standardization has led to:
1. Inefficiencies in data processing due to varied data formats.
2. Increased operational costs because of the need for multiple system expertise.
3. Integration challenges when rolling out bank-wide initiatives or updates.
4. Potential security vulnerabilities due to inconsistent security protocols across departments.
**Which of the following approaches would best address the lack of standardization at GlobalFin?**
**Conduct a thorough audit in the Architecture Vision** to pinpoint the areas with the most significant standardization issues. Based on this audit, in the Architecture Development phase, design a targeted approach to address the most pressing challenges first. In Implementation Governance, monitor the implementation closely, ensuring that the solutions are effective and provide a foundation for broader standardization in the future.
**Initiate with an Architecture Vision** to outline the strategic importance of IT standardization across the organization. Engage with department heads to understand the unique needs and challenges of each department. In the Architecture Development phase, design a unified IT blueprint that promotes standardization while accommodating department-specific requirements. During Implementation Governance, oversee the transition to the new standardized systems, ensuring alignment with the vision and minimizing disruptions.
**Begin with a series of workshops during the Architecture Vision** to understand the depth and breadth of the standardization issue. Based on feedback, in the Architecture Development phase, design a framework that balances standardization with flexibility. During Implementation Governance, implement this framework, ensuring that each department aligns with the broader standardization goals while retaining some autonomy.
**In the Architecture Vision**, gather insights from a cross-section of employees, not just department heads, to understand the ground-level challenges caused by the lack of standardization. With this broader perspective, move to the Architecture Development phase to design solutions that cater to both top-level and ground-level needs. During Implementation Governance, roll out these solutions in a phased manner, ensuring that the transition is smooth and meets the diverse needs of the organization.
See all questionsBackSkip question
3: Develop a Comprehensive Risk and Security Architecture:
You are the Lead Architect at a global pharmaceutical company, XedMedCo. The company has research labs in 15 countries and distributes its products worldwide. It operates under four main divisions, each focusing on a different therapeutic area. Each division has historically functioned autonomously, with distinct research methodologies and minimal shared data. However, they all report financial and HR metrics to the central corporate office.
A recent proposal from an external consultancy suggests a restructuring to promote the sharing of research data across divisions. This would necessitate the creation of unified research data systems and patient trial databases.
XedMedCo has a well-established Enterprise Architecture practice, grounded in the TOGAF Standard. The CIO sponsors the Enterprise Architecture initiative. A Statement of Architecture Work has been greenlit, and the Enterprise Architecture team has secured the consensus of primary stakeholders to devise a Target Architecture to validate the proposed benefits. Several domain architectures have been ratified, revealing a set of gaps.
During the latest executive meeting, which included representatives from all divisions, concerns were voiced about the potential risks and security implications of this cross-divisional data sharing initiative.
**Question**
Given the Scenario 2, you are tasked with suggesting a strategy to address the raised apprehensions. Based on the TOGAF Standard, which of the following would be the most appropriate recommendation?
4: Agile Transformation and DevOps Integration
WaveTech, headquartered in San Francisco, is a pioneer in the world of smart home devices. Over the past decade, the company has introduced a range of products that have transformed everyday living, from smart thermostats to voice-activated lighting systems. With a mission to make homes smarter and lives more convenient, WaveTech has consistently been at the forefront of technological innovation. The enterprise architecture team at WaveTech, in collaboration with product development, marketing, and IT departments, has been instrumental in translating innovative ideas into market-ready products.
However, in the fast-paced world of tech, staying ahead of the curve is a relentless challenge. As competitors introduce new products at breakneck speed, WaveTech has found itself grappling with increasingly longer product development cycles. A deep dive into the issue revealed that while the ideas and innovations were aplenty, cumbersome IT processes often acted as bottlenecks, delaying product launches and impacting the company's competitive edge. The delayed time-to-market has led to:
1. Lost revenue opportunities as competitors get a head start.
2. Increased development costs due to prolonged product testing and iteration cycles.
3. Eroding brand perception among consumers expecting timely innovations.
4. Internal frustrations as teams feel their efforts are not translating into market success.
**Which of the following strategies would best address WaveTech's time-to-market challenges?**
5: Develop a Unified Patient Engagement Architecture
You are a lead architect working with the Enterprise Architecture (EA) team at the multinational healthcare technology firm, HealthTech Inc. Your personal responsibility within the EA team is the patient engagement platform. The ongoing roadmap for the patient engagement platform is focused on incremental efficiency gains with healthcare providers and providing localized health monitoring services with changes for language, different healthcare regulations, and integrated telemedicine support.
As part of the ongoing Digital Transformation, two of the product lines have now released digital health services and virtual consultations surrounding traditional healthcare services. Both product lines have faced difficulty managing subscriptions and follow-up consultations in the patient engagement platform.
The Product Manager is responsible for a new health service that will be offered directly to patients. It has been proposed that this be supported by a stand-alone patient engagement system that supports direct engagement with patients. The Product Manager is concerned about the long-term architecture, especially given that in the future, physical and digital health services will share the same patient interaction and support channels.
Question Text
You have been asked how to address the concerns raised by the Product Manager?
Which of the following is the best answer?
6: Evolving the Role of Enterprise Architecture in Digital Transformation for eCommerce
Your role is a senior architect working within the Enterprise Architecture (EA) team. Your area of responsibility is the eCommerce website.
Scenario
To date, the EA team has been focused on supporting the firm's IT Portfolio (Architecture to support Portfolio). The EA team has established a strong track record in developing robust architecture frameworks for various departments, including marketing, logistics, inventory management, and customer service platforms. These frameworks ensure seamless operations and integration across the firm's digital infrastructure. The team's efforts have been instrumental in enhancing operational efficiency and enabling data-driven decision-making.
Despite these successes, the EA team has not been involved in defining strategies for the Digital Transformation initiative. Recently, there has been an increasing number of requests from the product development teams and the user experience (UX) team for architecture support. These requests highlight a need for integrating advanced analytics, personalization features, and improved scalability to better serve the growing online customer base. However, the EA team has been referring these requests to external consultants due to a perceived lack of internal expertise in these specific areas.
Question
You have been asked by the EA team leader to recommend how the EA team could alter its role to support the Digital Transformation activity, specifically focusing on enhancing the eCommerce website's architecture to improve customer engagement and digital marketing capabilities.
Choose the right answer
7: IT Standardization Strategy for Digital Transformation
Your role is that of an Enterprise Architect for a global retail chain, ShopGlobal. Over the past two decades, ShopGlobal has expanded its presence across continents through mergers with regional retail chains. This expansion strategy has led to a patchwork of different IT systems, inconsistent data handling, and a myriad of custom integrations.
ShopGlobal's Enterprise Architecture team has embraced the TOGAF Standard for its practice, with the CFO as the sponsor of the Enterprise Architecture program. The company maintains a vast IT department, consistently juggling over 150 projects related to infrastructure and services.
Recent market analysis has shown a surge in e-commerce, with many customers preferring online shopping experiences. Competing retail chains have capitalized on this trend, offering seamless online shopping experiences, faster delivery options, and personalized customer interactions.
The CFO has initiated a Digital Transformation project to revamp ShopGlobal's online presence. The objective is to offer a unified online shopping experience across all regions. As part of this initiative, there's a need to standardize the underlying IT infrastructure and services to support this digital shift, keeping in mind the ever-evolving tech landscape.
You are now leading the IT standardization segment of this project. An Architecture Vision has been greenlit, allowing the development of a Target Architecture. Approved domain architectures and identified gaps have received stakeholder endorsement. The Enterprise Architecture team has outlined the necessary work to implement these changes.
**Question**
Refer to the Scenario.
You are tasked with proposing the next steps. Based on the TOGAF Standard, which of the following is the best answer?
You propose a phased implementation approach. Begin with the domain architectures that have the most significant impact on customer experience. As these are rolled out, iteratively refine ongoing projects to align with the new architectures. For requirements from Phases B through D not covered by current projects, initiate pilot projects to test and refine solutions. Ensure that all projects adhere to a standardized set of service interfaces for consistency. The outcomes of these pilot projects will inform the broader Implementation and Migration Plan.
You advocate for a risk-first approach. Identify the changes with the highest potential risks and address them first. Organize these changes into work packages, ensuring that each package has a clear risk mitigation strategy. Engage stakeholders to prioritize these packages based on business impact. Develop a series of Transition Architectures that focus on de-risking the most critical parts of the transformation. The risk assessment, mitigation strategies, and Transition Architectures will be detailed in the Architecture Roadmap
You recommend that the Enterprise Architecture team collaborates with domain architects to review the ongoing projects and their alignment with the new vision. Each domain architect should identify potential synergies between existing projects and the new requirements. The collective insights from all domains should then be synthesized into the Implementation and Migration Plan. The sequence of deliverables and their interdependencies will be outlined in the Architecture Roadmap.
You suggest a collaborative workshop approach. Organize workshops with stakeholders from each domain to brainstorm the implementation of domain architectures. These workshops will ensure that the practical challenges and nuances of each domain are considered. The insights from these workshops will lead to a detailed list of work activities, which will be integrated into an IT portfolio plan. This collaborative approach will culminate in a Target Architecture that is both visionary and grounded in practical realities.
See all questionsBackSkip question
8: Optimizing IT Infrastructure Costs in a Mature Digital Enterprise
SolarXpro Industries, headquartered in Berlin, is a renowned player in the renewable energy sector. Established in the early 2000s, the company has been at the forefront of solar technology innovations, providing solutions to both residential and commercial clients. Their mission, "Illuminating a Greener Tomorrow," reflects their commitment to sustainable energy solutions for a brighter future.
The company's organizational structure is vast, with departments ranging from R&D and production to sales and customer support. The Chief Information Officer (CIO) of SolarXpro holds a unique position, bridging the gap between the technical and business sides of the company. Reporting directly to the CEO, the CIO is responsible for ensuring that the company's IT infrastructure not only supports its current operations but also aligns with its vision for the future.
The enterprise architecture team, under the CIO's leadership, has been instrumental in implementing and maintaining the company's IT systems. They have overseen the digital transformation of key processes such as supply chain management, customer relationship management, and data analytics for performance monitoring. While the team is mature, with a blend of experienced architects and fresh talents, they are currently facing challenges in managing the rising costs associated with the IT infrastructure.
SolarXpro Industries is grappling with the financial strain of its IT infrastructure. The challenges include:
1. High costs associated with frequent software updates and licensing.
2. Expensive maintenance of legacy systems that are integral to some key processes.
3. Rising expenses in hardware procurement and replacements.
4. Increased spending on cybersecurity measures due to the evolving threat landscape.
**Question:**
Given the context and problematic, which approach should SolarXpro Industries' enterprise architecture team adopt to address the escalating and unsustainable IT costs?
Last updated