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:
- Strategy Layer: High-level business goals and quantified KPIs.
- Business Architecture: Business capabilities and operational processes.
- Application Architecture: Applications, services, and core platforms.
- Technology Architecture: Cloud platforms, infrastructure nodes, and migration targets.
- Auto-Updating Views: Experience how query-driven views automatically update in real time when you add new applications to your hosting infrastructure.
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/
│ ├── capabilities.ea # [NEW] Business Architecture: Core capabilities
│ └── actors.ea # [NEW] Business Architecture: Actors & processes
├── 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:
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"
attr 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
current_value 3.8
unit "minutes"
trend "Down"
}
kpi_onboarding_time influences goal_double_customers "Faster registration drives higher conversion rates"
}
3. Define the Business Layer (business/capabilities.ea & business/actors.ea)
In the Business layer, we define two complementary models:
- Capabilities: High-level business abilities that the organization possesses or requires.
- Actors & Processes: The human or organizational roles and the sequence of activities that execute those capabilities.
First, create business/capabilities.ea. Here we define the initial digital onboarding capability that enables our strategic transformation goal:
layer "Business Architecture" {
capability cap_digital_onboarding "Digital Onboarding & KYC" {
description "Self-service customer registration, ID verification, and KYC"
number "2.1"
maturity "Managed"
score {
business_value 9.6
tech_fit 9.2
}
relationships {
this influences goal_double_customers "Enables rapid customer acquisition at scale"
}
}
}
Next, create business/actors.ea. Here we define the operational onboarding process that realizes the capability and triggers the mobile application:
layer "Business Architecture" {
process proc_onboarding "Digital Onboarding Process" {
description "End-to-end user journey for verifying identity and provisioning accounts"
automation_level "Automated"
relationships {
this realizes cap_digital_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:
environment env_aws_prod "AWS Production Environment" {
description "Primary cloud environment running containerized microservices in us-east-1"
provider "AWS"
region "us-east-1"
env_type "Production"
is_production true
infrastructure inf_aws_eks "EKS Kubernetes Cluster" {
description "Multi-AZ managed Kubernetes compute cluster running banking APIs"
provider "AWS"
time "Invest"
cost {
amount 180000
unit year
}
security {
confidentiality "High"
integrity "High"
availability "Critical"
}
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"
provider "IBM"
region "us-east-1"
env_type "Production"
is_production true
infrastructure inf_ibm_z16 "IBM z16 Mainframe" {
description "IBM z16 mainframe hosting core banking ledger and batch processing"
provider "IBM"
time "Eliminate"
cost {
amount 650000
unit year
}
security {
confidentiality "High"
integrity "Critical"
availability "Critical"
}
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:
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.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.
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_digital_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
Multi-layer architecture projection showing end-to-end lineage from strategic goals down to Kubernetes infrastructure
Hosting matrix view showing hosting relationships between environments and applications
Key Features Promoted in this View:
- Cross-Layer Traceability: Traces end-to-end lineage across all four architectural tiers:
goal_double_customers→cap_digital_onboarding→proc_onboarding→app_mobile_banking→inf_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. The Auto-Update Feature in Action: Add a New Application on AWS
In traditional drawing tools (Visio, Lucidchart, draw.io), modifying an architecture requires manual toil: dragging shapes onto canvases, drawing connector lines, and manually finding every related diagram to keep them in sync. As an enterprise grows to dozens or hundreds of views, diagrams inevitably fall behind reality, a problem known as diagram drift.
In Scapius, views are live declarative queries over the architecture graph. Because our technology_footprint view was declared using:
include where layer == "Technology Architecture"
include_verb hosts
exclude env_on_prem_mainframe
Any new application hosted on our included infrastructure will be discovered and rendered automatically, without changing the view definition in main.ea.
Let's test this by introducing a second microservice to NeoBank: app_auth_api "Customer Authentication API".
1. Add the Application to customer_onboarding.ea
Open application/customer_onboarding.ea and append the new app_auth_api microservice under system_core_banking:
app app_auth_api "Customer Authentication API" {
description "Stateless token verification and OAuth2 customer authentication service"
owner "Identity & Access Management"
tier "Tier-1"
internet_facing true
status "Active"
time "Tolerate"
cost {
amount 150000
unit year
}
score {
business_value 8.8
tech_fit 7.5
}
security {
confidentiality "Critical"
integrity "Critical"
availability "Critical"
}
lifecycle {
phase Run start "2021-06-01"
}
}
2. Host the Application on AWS EKS
Next, update technology/environments.ea so that the managed EKS Kubernetes cluster hosts the new authentication service alongside the mobile app:
infrastructure inf_aws_eks "EKS Kubernetes Cluster" {
description "Multi-AZ managed Kubernetes compute cluster running banking APIs"
provider "AWS"
time "Invest"
cost {
amount 180000
unit year
}
security {
confidentiality "High"
integrity "High"
availability "Critical"
}
relationships {
this hosts app_mobile_banking "Hosts mobile backend gateway and APIs"
this hosts app_auth_api "Hosts authentication microservice pods"
}
}
We did not modify main.ea. We did not edit the technology_footprint view definition. We did not draw any diagram boxes or connector arrows.
8. Visual Projection: The Auto-Updated Technology Footprint
Because technology_footprint contains include_verb hosts, the Scapius compiler traverses the newly declared relationship on inf_aws_eks, resolves app_auth_api, and automatically recalculates the diagram layout.
In the Scapius Web Workspace and VS Code extension, saving these files triggers real-time incremental recompilation: the visual canvas hot-reloads and updates automatically without a manual page refresh:
Updated Technology Footprint view: Customer Authentication API automatically appears on AWS EKS without modifying the view query
Core Architecture as Code Principles:
- Single Source of Truth: Declare the entity and its relationships once in its domain fragment; all referencing views across the entire repository update immediately.
- Zero Diagram Drift: Diagrams never fall out of sync with code because they are generated dynamically from the compiled AST.
- Dynamic Query Expansion: Views authored with declarative selectors (
include where ...,include_verb ...) automatically adapt as teams add new microservices and infrastructure.
9. Validate the Expanded Workspace
Run the validator across the entire workspace to verify the updated model and relationships:
scapius validate ./neobank
Validation Successful! Workspace 'Neo Bank Enterprise Architecture' is valid.
Next Steps
With your multi-layer model established and the auto-update workflow verified, proceed to Tutorial 3: Capability Mapping to decompose NeoBank's 9-domain business capability hierarchy and apply TIME portfolio scoring.