Phase C: Information Systems Architectures

Develop the Data and Application Architectures that enable the Business Architecture and the Vision.

About this phase

Phase C develops the Information Systems Architectures — the Data Architecture and the Application Architecture. It describes how the enterprise's information systems will enable the Business Architecture and the Architecture Vision.

The Data Architecture describes the structure of the enterprise's major types and sources of data: the logical and physical data assets and data management resources. The Application Architecture describes the individual applications (as logical groupings of capability), their interactions, and their relationships to the core business processes.

Data and Application Architecture may be developed in either order or in parallel — the standard does not mandate a sequence. Both follow the same nine-step pattern as Phase B, applied to their own domain.

Objectives

Develop the Target Information Systems (Data and Application) Architectures, describing how the enterprise's Information Systems Architecture will enable the Business Architecture and the Architecture Vision, while addressing the Statement of Architecture Work and stakeholder concerns.
Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures.

Steps in this phase

0/9 · 0%

1.Select reference models, viewpoints, and tools (Data & Application)Choose data and application reference models, viewpoints (e.g., entity–relationship, application communication, data lifecycle), and modeling tools relevant to stakeholder concerns.
2.Develop the Baseline Data and Application Architecture descriptionsDescribe the existing data landscape (entities, sources, quality) and application portfolio to the extent needed to support gap analysis.
3.Develop the Target Data and Application Architecture descriptionsDefine target data entities, authoritative sources, and data management; define the target application portfolio, application services, and their interactions.
4.Perform gap analysisIdentify gaps between Baseline and Target for both Data and Application Architectures.
5.Define candidate roadmap componentsDerive candidate work items (e.g., new applications, data migration, decommissioning) as input to Phases E and F.
6.Resolve impacts across the Architecture LandscapeAssess implications for and from other architectures — e.g., shared data services used by other segments.
7.Conduct formal stakeholder reviewVerify that the Data and Application Architectures address stakeholder concerns and the Statement of Architecture Work.
8.Finalize the Information Systems ArchitecturesSelect standards, fully document building blocks and interfaces, and cross-check against requirements.
9.Create/update the Architecture Definition DocumentDocument the Data and Application Architectures (baseline, target, gaps, views) in the Architecture Definition Document.

Key inputs

Request for Architecture Work and Statement of Architecture Work
Architecture Vision and Capability Assessment
Data and application principles (if existing)
Organizational Model for Enterprise Architecture and Tailored Architecture Framework
Architecture Repository — reusable building blocks, reference models (e.g., III-RM), organization-specific standards
Draft Architecture Definition Document, including the Business Architecture from Phase B
Draft Architecture Requirements Specification, including gap analysis results from Phase B
Business Architecture components of an Architecture Roadmap

Key outputs

Refined and updated Architecture Vision phase deliverables where applicable
Draft Architecture Definition Document containing Baseline and Target Data and Application Architectures (v1.0)
Draft Architecture Requirements Specification, including gap analysis results and relevant technical requirements
Data and Application Architecture components of an Architecture Roadmap

Worked example — Meridian Retail Group

Generated sample documents for a fictional company, showing what this phase consumes and produces. They are illustrative study aids, not templates from the standard.

Example inputs

PFrom Preliminary Phase

AFrom Phase A: Architecture Vision

BFrom Phase B: Business Architecture

RMFrom ADM Architecture Requirements Management

Prepared for this phase

example inputDeliverablefrom PreliminaryThe document from the sponsoring organization that triggers an ADM cycle — the key handoff from the Preliminary Phase into Phase A.

Request for Architecture Work

Sponsoring organization: Meridian Retail Group — Office of the COO Date: 2 April 2026 Reference: RAW-2026-001 Addressed to: Architecture Board (submitted via the Lead Architect)

Organization sponsors

Chief Operating Officer (business sponsor); Chief Information Officer (executive sponsor for architecture).

Mission statement

Deliver the "One Meridian" unified customer experience: any customer, recognized in any channel, served from a single view of orders, inventory, and preferences.

Business goals and changes

Increase repeat-purchase rate from 31% to 40% within 24 months
Enable buy-online-pickup-in-store (BOPIS) in all 240 stores
Consolidate 4 customer databases into a governed single customer view
Reduce integration spend by 20%

Strategic plans

Responds to the One Meridian strategy (FY26–FY28) and Board Directive 26-04. Goals map to drivers DRV-01 to DRV-04 in the Driver/Goal/Objective catalog.

Time limits

Architecture definition (Target Architecture and roadmap) approved before the 1 Nov 2026 peak trading freeze
First Transition Architecture in production before the FY27 peak freeze

Changes in the business environment

Competitors now offer click-and-collect as standard; digital revenue at 26% and rising; POS v9 reaches end of life in 2027.

Organizational constraints

Peak trading freeze: no production change 1 Nov – 15 Jan
Franchise stores operate their own POS until contract renewal (FY27)

Financial constraints

Indicative program envelope of $18M over 2 years, subject to Investment Committee approval per tranche.

External and business constraints

GDPR and PCI-DSS compliance mandatory
3PL logistics contract fixes EDI message formats until 2027

Current business system description

Channel-based operating model: Digital Commerce, Store Operations, and Customer Care each run their own customer processes and service standards.

Current systems description

4 customer databases, 3 order management systems, in-store POS (v9, EOL 2027), monolithic e-commerce platform, nightly-batch warehouse integration.

Developing organization and resources available

Meridian EA team (Lead Architect plus 4 domain architects), working under the Tailored Architecture Framework v1.0 and Architecture Principles v1.0. Business subject-matter experts released for up to 2 days per week during Phases B–D.

Success criteria

An approved Target Architecture and Implementation and Migration Plan for the One Meridian program, with the first Transition Architecture delivered before the FY27 peak trading freeze.

Submitted by: COO, 2 April 2026 · Accepted for Phase A: Architecture Board, 9 April 2026

Example outputs

example outputDeliverableTarget data entities with authoritative sources, and a data entity × application matrix showing where each entity is mastered.

Architecture Definition Document — Data Architecture (draft v0.3, excerpt)

Section owner: R. Mehta (Data Architect) Status: Draft v0.3 for Architecture Board review, 6 Aug 2026

1. Scope and viewpoints

Covers the customer, consent, order, inventory and loyalty data used by the One Meridian capabilities. Viewpoints selected in step 1: Conceptual Data diagram, Data Entity/Data Component catalog, Application/Data matrix, Data Lifecycle diagram and Data Migration diagram.

2. Baseline summary

Customer data in four stores: 5.0M records, about 3.9M distinct people, 22% duplicates; email is the only common match key.
Consent captured differently per system, with no provable lineage.
Order data split across three systems with no common order ID.
Store stock uploaded nightly, about 85% accurate, invisible online.
37 BatchSync jobs copy data between systems with 24–48h lag.

Target data entity catalog (extract)

Data entity	Definition	Authoritative source (target)	Steward
Customer	A person with a relationship to Meridian (identified or consented-guest)	Customer Profile Service	Customer Data Steward
Consent	A customer's privacy and marketing permissions	Customer Profile Service	Data Protection Officer
Erasure Request	A data subject's request to erase personal data, with its propagation status	Customer Profile Service	Data Protection Officer
Order	A request to purchase, in any channel, through its lifecycle	Order Hub	Order Mgmt Product Owner
Return	A request to return items from any order, in any channel	Order Hub	Order Mgmt Product Owner
Inventory Position	Sellable quantity of an item at a location	Inventory Service	Supply Chain Ops
Loyalty Account	Points balance and tier for a customer	LoyaltyOne (retained SaaS)	Loyalty Manager
Product	A sellable item and its descriptive content	ProductHub PIM (retained)	Merchandising Ops

3. Master data management approach

Customer: central hub. Channels create and update customers only through the Customer Profile Service API. A cross-reference keeps the legacy keys (web account ID, POS customer number, loyalty card number, CareDesk contact ID) until the legacy stores are retired.
Order: Order Hub is the single system of record; channels hold only a transient basket until checkout.
Inventory Position: derived by the Inventory Service from stock movement events sent by stores and WMS.
Loyalty Account: LoyaltyOne stays the system of record. The Customer Profile Service shows the points balance in its composite profile; the loyalty tier is not in canonical model v1.0.
Events: only the authoritative source publishes events about its entity (order-lifecycle, inventory-changed, consent-changed, erasure-requested).

Data entity × application matrix (M = master, R = read, U = update)

Entity \ Application	Customer Profile Svc	Order Hub	Inventory Svc	WebShop (new front end)	StorePOS (next-gen)	CareDesk
Customer	M	R	—	R/U	R	R
Consent	M	—	—	R/U	R/U	R
Order	R	M	R	R/U	R/U	R
Inventory Position	—	R	M	R	R/U	—
Loyalty Account	R	R	—	R	R	R

The full create/read/update/delete view is in the Application/Data matrix.

4. Classification, security and quality

Entity	Classification	Key controls	Quality target
Customer	Personal, confidential	Encryption at rest, role-based access, consent check before marketing use	Residual duplicates < 2% (REQ-D-01)
Consent	Personal, regulatory	Append-only history with source and timestamp	100% of records with lineage (REQ-D-02)
Order	Confidential	Card data never stored; payment tokens only	Every order carries the enterprise customer ID or a guest marker
Inventory Position	Internal	Write access for Inventory Service only	Store stock accuracy ≥ 98% in BOPIS stores (REQ-D-05)

Data migration requirement (feeds Architecture Requirements Specification)

REQ-D-01: The four baseline customer stores shall be deduplicated and merged into the Customer Profile Service with a survivorship ruleset approved by the Data Governance Council; residual duplicate rate < 2%.
REQ-D-02: Consent records must be migrated with provable lineage (GDPR).
REQ-D-03 (added 22 Jul 2026 through RIA-2026-09): erasure requests shall propagate to every consumer of profile data within 30 days, with an audit trail.

5. Open issues

Survivorship ruleset draft v0.3 is awaiting Data Governance Council approval at its September 2026 meeting. Customer migration is gated on it.
Depth of order-history migration (24 months proposed) to be confirmed with Customer Care against the returns policy.

Study notes

Produced in: Step 3: Develop the Target Data and Application Architecture descriptions · Step 8: Finalize the Information Systems Architectures · Step 9: Create/update the Architecture Definition Document

This is a section of the Architecture Definition Document, a deliverable. The catalog and matrix inside it are artifacts that also live separately in the Architecture Repository.
Naming one authoritative source and one steward per entity applies Principle 2 directly. Phase G later checks against it ('Order entity mastered in Order Hub only').
The MDM approach section records design decisions, not products. Whether the Customer Profile Service is a bought CDP is decided in Phase E.
Leaving loyalty tier out of the canonical model is a deliberate scope decision. It later surfaces as compliance finding F-01 and Change Request CR-014 in Phase G.
REQ-D-03 arrived through Requirements Management while Phase C was in progress. This shows that the central process can change an in-flight phase.

Study tips & key concepts

Phase C = Data Architecture + Application Architecture. They may be developed in either order or in parallel.
Data Architecture concerns include: data management (master data, migration), data governance (structure, storage, integration standards), and data migration/quality when applications are replaced.
In the Application Architecture, applications are logical groupings of capability that manage data and support the business — stable 'building blocks', not a technology choice or physical product selection (that comes in Phase D and beyond).
Useful catalogs/matrices to recognize: Data Entity/Data Component catalog, Data Entity–Business Function matrix, Application/Data (CRUD-style) matrix, Application Communication diagram, Application Portfolio catalog.
Interoperability requirements surface strongly here; conflicts between candidate solutions are reconciled later in Phase E.