Architecture-Centric in SimpleModeling

ASAMI, Tomoharu Created: 2026-05-11

This article explains how SimpleModeling reinterprets the Unified Process (UP) principle of Architecture-Centric development for the AI era. Architecture is no longer treated merely as a design artifact, but as a framework that stabilizes modeling, implementation, execution, knowledge management, and operation across the development lifecycle.

AI-Era Reinterpretation

In an architecture-centric process, architecture is not merely a design artifact. Requirements, analysis models, design models, deployment structures, and operational structures are interpreted and refined through architectural viewpoints.

This becomes increasingly important in the AI era because generative AI systems behave more reliably when structures, contexts, responsibilities, and viewpoints are explicitly defined.

Architecture is also refined iteratively throughout development. Each iteration incrementally refines conceptual models, implementation structures, execution environments, and operational knowledge under a coherent architectural framework.

SimpleModeling Reference Profile

The SimpleModeling Reference Profile (SMRP) defines multiple architectures that support development.

The Standard Profile of SimpleModeling adopts all architectures defined in the Reference Profile. In practice, users can customize, replace, or extend individual architectures according to the requirements of their projects.

The following sections describe representative architectures used in SimpleModeling.

  • 4+1 View Model

  • 3-Tier Reference Architecture

  • Execution Architecture

  • Literate Architecture

  • Knowledge Architecture

  • Process Architecture

4+1 View Model

SimpleModeling inherits the 4+1 View Model proposed by Philippe Kruchten for the Unified Process, interpreting it as a multi-view modeling framework that connects human-readable narratives (SmartDox) and structured design models (Cozy). Each view corresponds to a distinct concern of the system.

View Focus Typical Model

Use-Case View

User goals, scenarios

UseCase, Scenario

Logical View

Domain concepts, relationships

Entity, Value, Rule

Process View

Behavior, concurrency, workflow

StateMachine, Activity

Development View

Components, modules, interfaces

Component, Interface

Physical View

Deployment and runtime topology

Deployment, Node

The โ€œ+1โ€ Use-Case View serves as the entry point that connects user intentions to system architecture. Together, these views form a consistent architectural baseline.

Related articles are listed below.

3-Tier Reference Architecture

In the SimpleModeling Reference Profile, the architectural baseline is structured around three subsystemsโ€”Presentation, Application, and Domainโ€”representing a modernized interpretation of the classic 3-tier architecture. This structure provides a stable foundation for modeling, code generation, and deployment.

Subsystem Responsibility Main Model

Presentation

UI, API, and user interaction

View, Controller, APIComponent

Application

Use-case coordination, process control

Service, UseCase, Workflow

Domain

Business logic and core knowledge

Entity, Value, Rule, DomainEvent

This layered structure aligns with the Logical, Development, and Physical Views of the 4+1 model, making the entire system architecture more analyzable, evolvable, and automatable.

Related articles are listed below.

Execution Architecture

SimpleModeling defines execution architectures that stabilize runtime behavior, execution boundaries, and operational structures.

  • CNCF (Cloud Native Component Framework) Runtime Architecture: standardizes lifecycle, services, selectors, and execution contexts.

  • CQRS + Job Architecture: stabilizes synchronous and asynchronous execution boundaries.

  • Form API / Static Form App Architecture: standardizes UI execution and transition structures.

Related articles are listed below.

Literate Architecture

SimpleModeling extends the architecture-centric concept into a literate architecture: each architectural decision, model, and viewpoint is documented in human-readable SmartDox form and linked to Cozy source models. This makes architecture both executable and explainable.

Related articles are listed below.

Knowledge Architecture

SimpleModeling defines knowledge architectures that stabilize the structure, representation, and circulation of knowledge.

  • Literate Model / SmartDox Architecture: organizes knowledge into semi-structured documents.

  • Vocabulary / Glossary / BoK (Body of Knowledge) Architecture: stabilizes terminology and semantic spaces.

Related articles are listed below.

Process Architecture

SimpleModeling defines process architectures that stabilize development activities and artifact flows.

  • Process / Activity / Skill Architecture: defines development order, responsibilities, and artifact flows.

Related articles are listed below.

Architectural Mechanisms

SimpleModeling also defines architectural mechanisms that stabilize, constrain, and support architectures. These mechanisms are not architectures themselves, but foundational structures that make architecture-centric development practical and stable.

  • Type System: constrains structures and data relationships.

  • Executable Specification: constrains behavior through laws and executable rules.

  • DSL (Domain Specific Language) / Grammar: constrains modeling and description spaces.

  • Vocabulary / Glossary: stabilizes terminology and semantic consistency.

Articles related to architectural mechanisms are listed below.

Harness Engineering

From the perspective of Harness Engineering, the architectures and architectural mechanisms defined in the SimpleModeling Reference Profile can be interpreted collectively as a development harness system. By structuring execution, knowledge, and process boundaries through architecture, development becomes more stable and reproducible.

This becomes increasingly important in the AI era because generative AI systems behave more reliably when development environments are explicitly structured.

SUMMARY

In SimpleModeling, architecture-centric development means aligning models, execution structures, knowledge structures, and processes under a coherent architectural framework. The SimpleModeling Reference Profile provides a reusable architectural baseline that connects conceptual understanding and executable systems.

References

In Site

Glossary

UP (Unified Process)

A process model based on UML, characterized by iterative, use-caseโ€“driven, and architecture-centric development. It has derivatives such as the Rational Unified Process (RUP) and provides a foundation for practicing Component-Based Development (CBD).

SimpleModeling Reference Profile (SMRP)

This is the reference profile of SimpleModeling. To concretely illustrate Literate Model-Driven Development with SimpleModeling, a reference profile is defined.

Execution Architecture

A technical and runtime foundation supporting the development system, separating model and execution layers.

Activity

A concrete action or task performed within an Activity Space to move an Alpha to a more advanced state, typically producing or refining Work Products.

Component

A software construct that encapsulates well-defined responsibilities, contracts, and dependencies as a reusable and replaceable unit. In the logical model, it serves as an abstract structural unit; in the physical model, it corresponds to an implementation or deployment unit.

Cloud Native Component Framework (CNCF)

Cloud Native Component Framework (CNCF) is a framework for executing cloud application components using a single, consistent execution model. Centered on the structure of Component, Service, and Operation, it enables the same Operation to be reused across different execution forms such as command, server (REST / OpenAPI), client, and script. By centralizing quality attributes required for cloud applicationsโ€”such as logging, error handling, configuration, and deploymentโ€”within the framework, components can focus on implementing domain logic. CNCF is designed as an execution foundation for literate model-driven development and AI-assisted development, separating what is executed from how it is invoked.

literate model

A Literate Model is a โ€œreadable modelโ€ that integrates model structure with natural-language narrative (structured documentation). It extends the idea of literate programming into the modeling domain, unifying structure (model) and narrative (structured text) into a single intelligible artifact interpretable by both humans and AI. The concept of โ€œLiterate Modelingโ€ has been explored previously by some researchers and developers, mostly as an approach to improve documentation or code comprehension. However, those attempts did not establish a systematic modeling methodology that integrates models, narrative, and AI assistance as a unified framework. The Literate Model is a modeling concept newly systematized and proposed by SimpleModeling for the AI era. Building upon the ideas of literate modeling, it redefines them as an intelligent modeling foundation that enables AI-collaborative knowledge circulation and model generation. It is not merely a modeling technique but a framework that embeds human reasoning and design intent as narrative within the model, enabling AI to analyze and reconstruct them to assist in design and generation.

BoK (Body of Knowledge)

At SimpleModeling, the core knowledge system for contextual sharing is called the BoK (Body of Knowledge). The goal of building a BoK is to enable knowledge sharing, education, AI support, automation, and decision-making assistance.

DSL (Domain Specific Language)

A DSL (Domain-Specific Language) is a language designed for a particular domain, enabling direct and concise expression of the domainโ€™s concepts and structures. Compared to general-purpose programming languages (GPLs), DSLs offer a higher level of abstraction tailored for domain-specific problem solving and automation.