ITEC 4060 - L7: EA TOGAF Phase C: Information System Architecture

TOGAF Phase C (Information System Architecture)

ADM phase that defines the logical application and data architecture that supports the business architecture without committing to specific technology

Information System Architecture (TOGAF)

Logical description of application components and data structures that realize business capabilities and support enterprise use

Phase C bridge role

Connects Phase B business elements to software components before Phase D technology realization decisions

Application Architecture (Phase C)

Subphase focused on defining application components, services, interfaces, and interactions

Data Architecture (Phase C)

Subphase focused on defining logical data structures, data distribution, security, and migration

Legacy application landscape

Existing applications and flows that must be understood and accounted for in baseline and migration planning

Target IS evolution path

Step-by-step migration from current IS to target IS through intermediate architectures

Architecture step definition

Intermediate IS version that specifies how the system is used and how migration from the prior version occurs

Logical view emphasis

Phase C focuses on architecture structure and usage rather than detailed application design

Central Phase C artifact

Application Communication Diagram that positions application components and identifies interfaces and interconnections

Application component

Encapsulated piece of application functionality aligned to an implementation structure and exposed through interfaces

Interface (application)

Defined point of interaction through which components exchange messages or invoke services

Interconnection (application)

Connection between components or applications showing communication or dependency

Hybrid application architecture

Combination of applications and service-based components coexisting in one architecture

SOA (Service-Oriented Architecture)

Architectural style where components cooperate through services accessed over a network while supporting legacy integration

Service (SOA)

Discrete unit of network-accessible functionality representing a business activity outcome and treated as a black box by consumers

Service black box principle

Consumers use the service interface without needing to know internal implementation details

Service composition

Ability for a service to be built from other services to deliver higher-level outcomes

Service consumer

Actor or component that requests or uses a service

Service provider

Component or system that offers a service operation through an interface

Interaction component (SOA stack)

Component that manages dialogue between the IS and external actors such as users or partner systems

Process component (SOA stack)

Component that automates business processes by sequencing tasks, connecting services, and managing events

Function component (SOA stack)

Component that performs business processing, validation, and message adaptation between process and entity components

Entity component (SOA stack)

Component centered on a key business entity and often responsible for database access and entity-related operations

Utility component (SOA stack)

Cross-organizational service such as directories, messaging, or publishing that is relatively independent of core business entities

Public component (SOA stack)

Component providing services accessible from outside the enterprise IS for B2B or partner access

Application Communication Diagram

Diagram showing application components and their connections, including interfaces and communication paths

ReserveTrip process component example

Process component coordinating trip reservation flow by invoking entity and function components

Client entity component example

Entity component managing client-related operations and persistence

Trip entity component example

Entity component managing trip-related operations and persistence

Order entity component example

Entity component managing order-related operations and persistence

Front component (legacy integration)

Component placed in front of existing applications to adapt or expose their functionality to the new architecture

Application Migration diagram

Diagram showing how application components evolve across system versions and which components are replaced or retained

System version (migration)

Architecture snapshot labeled as a distinct system such as V0, V1, or V2 during migration planning

Component retention

Keeping an application component unchanged across system versions in a migration diagram

Component replacement

Swapping an old component with a new one across versions, often indicated with a migrates relationship

Migrates dependency (application)

Relationship indicating that one application component or system instance replaces another during migration

Application and User Location diagram

Diagram placing application component instances inside hardware instances within geographic locations to show deployment distribution

Application component instance

Runtime deployment of an application component in a specific system version or environment

IT hardware instance

Server or hardware node that hosts deployed application component instances

Geographic location (deployment)

Site such as data center, HQ, branch, or cloud region where hardware and applications run

Cloud deployment planning use

Using location diagrams to reason about distributed deployment, scaling, and operational support

Sizing estimation (location diagram)

Estimating bandwidth, storage, and server sizing from distributed usage and deployment structure

License estimation (location diagram)

Estimating the number of user licenses needed for purchased software from user distribution and usage

User support planning

Planning helpdesk and support center placement based on user location and system distribution

System Use Case diagram

Diagram describing how actors/components interact with application services and which components realize those interactions

Consumer-provider validation

Using system use cases to validate that consumers can obtain needed functionality from providers

Communication link (use case)

Link showing an actor participates in or communicates with a use case

Realization link (use case)

Link showing which application component or service realizes a use case

Exceptional case detail (use case)

Optional conditions or exceptions attached to a use case to clarify behavior

Process System Realization diagram

Diagram showing sequence of events across multiple components for executing a business process

Sequencing constraints

Order rules that define how interactions among components must occur during process execution

Synchronization point (real-time and batch)

Coordination point where batch and real-time processing must align before continuing

Interaction traffic reduction goal

Using realization sequencing analysis to reduce unnecessary component interactions and network traffic

Rationalization opportunity (Phase C)

Chance to simplify complex sequences or consolidate components for efficiency

UML sequence diagram alternative

Alternative representation to show time-ordered messages between actors and components

Enterprise Manageability diagram

Diagram showing how applications interact with management-related application and technical components for operations and migration readiness

Manageability focus

Operational management concerns such as monitoring, administration, and managing parallel environments during migration

Overlap and omission detection

Using manageability diagrams to find redundant components, missing capabilities, and unused temporary applications

Parallel environment requirement

Need to run old and new systems concurrently during migration, captured in manageability planning

Migrates dependency (manageability)

Relationship used to indicate replacement of managed components or applications during transformation

Logical Data diagram

Diagram refining conceptual data into a logical model showing persistent data structures exploited by the target IS

Persistent data

Data stored beyond a single process instance and typically maintained in durable storage like databases

Relational database assumption

Logical data models often assume relational persistence and normalization for consistency and reuse

Relational normal forms

Standard schema design principles used to structure relational databases and reduce redundancy and anomalies

Schema reuse consideration

Evaluating whether existing database schemas can be reused or migrated rather than rebuilt

Data Dissemination diagram

Diagram defining how data is distributed and managed across services and application components

Data responsibility assignment

Clearly specifying which component manages or owns each business entity to avoid confusion and replication

Data replication risk

Multiple copies of data across components that can cause inconsistency and unclear accountability

Data distribution sizing insight

Using dissemination mapping to estimate component memory and compute needs based on managed entities

SOA dissemination derivation

In SOA, dissemination often follows naturally from layered components and service boundaries

Hybrid dissemination insight

In hybrid architectures, dissemination can reveal unclear responsibility and unnecessary replication

Data Security diagram

Diagram mapping actors to enterprise data with permissions to ensure integrity and controlled access

Data integrity (security)

Property that stored data is accurate and not improperly altered or corrupted

Access authorization

Control over who can access which data and what operations they can perform

CRUD

Create, Read, Update, Delete access rights used to specify and evaluate data permissions

Partner access risk

Security concern when subcontractors or partners access enterprise data or services

External hosting risk

Security concern when enterprise data is hosted outside enterprise boundaries such as in cloud environments

Data Migration diagram

Diagram showing data transformations between source and target applications or schemas during migration

Data transformation flow

Mapping of how data moves and changes form from one system version to another

Audit support (data migration)

Using migration diagrams to ensure no information is lost and changes are traceable and reviewable

Migrates dependency (data)

Relationship indicating that one data entity or attribute migrates to another in the target system

Entity-level migration

Mapping migration at the level of entire business entities between systems

Attribute-level migration

Mapping migration at the level of individual fields or attributes including type and format conversions

Service Data diagram

Diagram or specification describing data structures carried by services and message exchanges as operation parameters

Service data contract

Definition of the shape of data exchanged in service operations including inputs and outputs

Service extensibility goal

Designing service data structures for reuse and future evolution without constant incompatible variants

Service operation parameter

Data element passed into or returned from a service operation as part of the service contract

Conceptual-to-service data source

Service data derived from conceptual data models and the needs of service exchanges

Phase C deliverables set

Application Migration; App and User Location; System Use Case; Process System Realization; Enterprise Manageability; Logical Data; Data Dissemination; Data Security; Data Migration; Service Data

Application migration planning goal

Plan replacement and introduction of components across versions to reach the target IS

Deployment distribution goal

Plan where applications run and where users are located to support performance, licensing, and operations

Interaction validation goal

Validate consumers and providers and ensure components realize required use cases correctly

Sequence coordination goal

Ensure cross-component execution order and synchronization for complex processes

Operations readiness goal

Ensure monitoring and management capabilities exist during and after migration

Logical data refinement goal

Convert conceptual entities into persistent logical structures used by applications

Data governance goal

Assign data management responsibility and minimize replication to support consistency

Security mapping goal

Map roles and systems to data permissions using CRUD while protecting integrity and authorization

Migration integrity goal

Ensure data moves safely across versions with traceable transformations and no loss

Service evolution goal

Define reusable service data contracts that remain extensible across future changes