Skip to main content

Tutorial 2: Modeling Multi-Layer Architecture

In Tutorial 1, you set up NeoBank's multi-file root workspace and modeled customer onboarding in the Application layer.

In enterprise architecture, systems do not exist in isolation. Real architectures link strategic objectives to business processes, applications, and hosting infrastructure.

In this tutorial, you will expand NeoBank by organizing models across four architectural layers:

  1. Strategy Layer: High-level business goals and quantified KPIs.
  2. Business Architecture: Business capabilities and operational processes.
  3. Application Architecture: Applications, services, and core platforms.
  4. Technology Architecture: Cloud platforms, infrastructure nodes, and migration targets.

1. Expanding the NeoBank Workspace Layout

We will add three new domain fragments across the architectural layers:

neobank/
├── main.ea
├── strategy/
│ └── goals_kpis.ea # [NEW] Strategy Layer: Transformation goals & KPIs
├── business/
│ └── actors_processes.ea # [NEW] Business Architecture: Processes & capabilities
├── application/
│ └── customer_onboarding.ea # Application Architecture (from Tutorial 1)
└── technology/
└── environments.ea # [NEW] Technology Architecture: AWS cloud & mainframe

2. Define the Strategy Layer (strategy/goals_kpis.ea)

Create strategy/goals_kpis.ea. Here we capture NeoBank's executive transformation goal to double active customers and reduce onboarding friction:

neobank/strategy/goals_kpis.ea
layer "Strategy Layer" {

goal goal_double_customers "Double Active Customer Base" {
description "Expand active customer accounts to 4M by end-of-year 2028 through frictionless mobile onboarding and digital lending"
priority "Critical"
target_date "2028-12-31"
}

kpi kpi_onboarding_time "Customer Onboarding Time" {
description "Average elapsed minutes from app download to approved account opening"
target_value 5.0
unit "minutes"
trend "Down"
criticality "High"

relationships {
this influences goal_double_customers "Faster registration drives higher conversion rates"
}
}
}

3. Define the Business Layer (business/actors_processes.ea)

Create business/actors_processes.ea. Here we define the business capability and the operational onboarding process that realizes our strategic goal:

neobank/business/actors_processes.ea
layer "Business Architecture" {

capability cap_onboarding "Digital Customer Onboarding" {
description "Customer identity verification, fraud screening, and account setup capability"
time "Invest"
criticality "Critical"

relationships {
this influences goal_double_customers "Enables rapid customer acquisition at scale"
}
}

process proc_onboarding "Digital Onboarding Process" {
description "End-to-end user journey for verifying identity and provisioning accounts"
channel "Mobile App"

relationships {
this realizes cap_onboarding "Executes the customer onboarding capability"
this triggers app_mobile_banking "Customer initiates registration on mobile"
}
}
}

4. Define the Technology Layer (technology/environments.ea)

Create technology/environments.ea. NeoBank operates a dual hosting model: a modern AWS cloud production environment and a legacy mainframe datacenter undergoing migration:

neobank/technology/environments.ea
layer "Technology Architecture" {

environment env_aws_prod "AWS Production Environment" {
description "Primary cloud environment running containerized microservices in us-east-1"
provider "AWS"
region "us-east-1"

infrastructure inf_aws_eks "EKS Kubernetes Cluster" {
description "Multi-AZ managed Kubernetes compute cluster running banking APIs"
technology "Kubernetes"
is_production true

relationships {
this hosts app_mobile_banking "Hosts mobile backend gateway and APIs"
}
}
}

environment env_on_prem_mainframe "On-Premises Mainframe Datacenter" {
description "Legacy IBM z16 mainframe datacenter hosting core banking ledger"
status "Active"

relationships {
this hosts system_core_banking "Hosts legacy transactional ledger system"
this migrates_to env_aws_prod "Planned migration to AWS cloud core by 2027"
}
}
}

5. Add Cross-Layer Views to main.ea

Now update views { ... } in main.ea to project cross-layer traceability and hosting infrastructure:

  1. cross_layer_lineage: Directly projects the end-to-end vertical trace from our executive growth goal down through capabilities, processes, applications, and physical Kubernetes hosting.
  2. technology_footprint: Demonstrates layer queries (where layer == ...) and verb-based filters (include_verb hosts) to automatically pull all hosting infrastructure and deployed applications without manually enumerating every node.
neobank/main.ea (excerpt)
views {
// ... previous customer_onboarding_context view ...

landscape cross_layer_lineage "Strategic Cross-Layer Lineage" {
description "End-to-end traceability from executive growth goals down to operational processes, apps, and Kubernetes infrastructure."
tags ["Strategy", "Traceability", "Multi-Layer", "Lineage"]

include goal_double_customers
include cap_onboarding
include proc_onboarding
include app_mobile_banking
include inf_aws_eks

auto_layout TopToBottom
}

landscape technology_footprint "Current Technology Footprint" {
description "Live hosting footprint showing AWS cloud and mainframe environments with deployed applications."
tags ["Technology Architecture", "Infrastructure", "Cloud", "Traceability"]

include where layer == "Technology Architecture"
include_verb hosts
exclude env_on_prem_mainframe

auto_layout LeftToRight
}
}

6. Visual Projection: Cross-Layer Lineage & Hosting Footprint

default view visual diagramdefault view visual diagram

Multi-layer architecture projection showing end-to-end lineage from strategic goals down to Kubernetes infrastructure

Key Features Promoted in this View:

  • Cross-Layer Traceability: Traces end-to-end lineage across all four architectural tiers: goal_double_customerscap_onboardingproc_onboardingapp_mobile_bankinginf_aws_eks.
  • Predicate Filtering (include where layer == ...): Dynamically aggregates all entities belonging to a specific architectural layer without hardcoding individual identifiers.
  • Relationship Verb Matching (include_verb hosts): Automatically expands the view to include connected systems and apps that are hosted on the included environments.

7. Validate the Expanded Workspace

Run the validator across the entire workspace:

scapius validate ./neobank
Validation Successful! Workspace 'Neo Bank Enterprise Architecture' is valid.

Next Steps

With your multi-layer model established, proceed to Tutorial 3: Capability Mapping to decompose NeoBank's 9-domain business capability hierarchy and apply TIME portfolio scoring.