SimpleModeling Development Process in the AI Era

The Problem of Traditional Processes

Traditional development processes define phases such as requirements, design, implementation, and testing, but they assume human interpretation and execution.

As a result, processes exist as documents or guidelines, while actual execution is delegated to code and individual decisions.

As a result, processes exist but are not executed, or they diverge from actual implementation.

In the AI era, development processes themselves are expected to be executed by AI or at least driven with AI assistance.

With this shift, processes that rely on human interpretation become insufficient, and must instead be defined in a form that AI can understand and execute.

Essence as a Conceptual Foundation

In SimpleModeling, the Essence Framework is adopted as the foundation for explicitly defining development processes.

The Essence Framework provides a theoretical structure for describing software development processes using a common conceptual model.

Essence consists of the following elements:

These elements enable development processes to be defined as structures independent of specific methodologies.

In SimpleModeling, this Essence structure is used to organize concrete methodologies such as UP (Unified Process) and CBD (Component-Based Development), integrating them into a coherent process model.

However, Essence itself is a framework for describing processes, and it is not directly executable.

Therefore, an additional mechanism is required to determine how the defined processes are executed.

UP and CBD in the AI Era

The reinterpretation of UP (Unified Process) in the AI era is discussed in 📄 Reinterpreting the Unified Process in the AI Era. Here we focus only on the essentials.

UP provides a process backbone that advances development in executable slices through iteration and use-case-driven development.

CBD structures systems as components, ensuring quality through boundaries and structure.

In SimpleModeling, this structure is described using CML (Conceptual Modeling Language) and transformed by Cozy into programs that run on CNCF.

Furthermore, this CBD structure is realized on the execution platform by CNCF (Cloud-Native Component Framework), ensuring that component boundaries are consistently preserved at runtime.

This integrates UP-based process, CBD-based structure, CML-based modeling, Cozy-based generation, and CNCF-based execution into an executable development process.

From Description to Execution

Traditional development processes have been described as specifications or models, but they were not directly executable. Execution was delegated to programs, creating a clear gap between process and implementation.

SimpleModeling redefines this relationship by treating development processes as executable structures. In this view, processes are not merely descriptions, but targets of execution.

Through this transformation, the scope of execution—traditionally limited to programs—is expanded. First, components defined by CBD can be executed directly on CNCF, which extends conventional approaches.

In the AI era, use cases themselves become executable units. Applications operate not only at the component level, but also at the level of use cases.

Finally, the development process itself becomes an executable target. As a result, systems, use cases, and development processes are all treated as unified executable entities.

Core Architecture of SimpleModeling

SimpleModeling adopts an architecture that integrates BoK, Cozy, CNCF, and SKILL to make described processes and models executable.

Their roles are as follows:

BoK: describes knowledge and requirements as a literate model
Cozy: transforms BoK into CML and generates executable programs
CNCF: executes generated components as a running system
SKILL: defines and controls the execution of development processes

This architecture connects description (BoK), generation (Cozy), execution (CNCF), and process (SKILL) into a unified structure.

Through this, the transformation from description to execution described in the previous section is realized as a concrete system.

Use Case Execution Model

In SimpleModeling, a use case is not just a requirement description, but an executable unit. This represents a new domain made possible by the emergence of generative AI.

In traditional development, use cases were only inputs to design and implementation, and were never directly executable. In this model, leveraging AI’s interpretive capability, use cases themselves directly express system behavior and become executable targets.

As a result, the application operates not only as a collection of components, but also as a collection of use cases.

This structure concretizes the “expansion of execution scope” described earlier, positioning use cases alongside components as executable targets.

A use case defines system behavior through its internal operations and state transitions, and is treated as a coherent unit at runtime.

SKILL: Process Execution Mechanism

As shown in the previous sections, use cases are treated as executable units in SimpleModeling. Going one step further, SKILL is a mechanism that makes the development process itself executable, which is also a new domain enabled by AI.

SKILL provides this execution mechanism, transforming use cases into executable forms and controlling their execution.

Specifically, use cases are interpreted by SKILL and transformed into a set of executable operations (Actions) within the system.

These operations are executed on CNCF, realizing the behavior described in the use case as a running system.

Furthermore, SKILL handles not only the execution of use cases but also the execution of the development process itself. This unifies the execution of use cases and development processes under the same mechanism.

Through this structure, processes, use cases, and systems are unified as consistently executable targets in SimpleModeling. This represents an AI-era execution model that did not exist in traditional software development.

Conclusion

This article presented the SimpleModeling development process as a reconstruction of software development in the AI era.

While traditional development processes existed as descriptions and execution was delegated to programs, SimpleModeling treats the process itself as an executable structure.

Through this transformation, the scope of execution expands from components to use cases, and further to development processes. In particular, the execution of use cases and development processes represents a new domain enabled by generative AI.

Through the integration of BoK, Cozy, CNCF, and SKILL, description, generation, execution, and process are connected into a unified structure.

This is not merely a methodology, but an execution model directly operable by AI, and may become a foundational structure for future software development.

References

In Site

📄 Reinterpreting the Unified Process in the AI Era

Glossary

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.
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.
Way of Working: A defined set of practices and conventions that a team uses to organize and perform its work. It evolves as the team learns and adapts.
Development Process: A development process is the entire set of activities involved in building, deploying, and maintaining software systems. It encompasses planning, modeling, implementation, testing, and delivery as a systematic flow of development activities.
Alpha: A key progress dimension in Essence representing an essential element of software engineering (e.g., Opportunity, Stakeholders, Requirements, Software System, Team, Work, Way of Working). Each Alpha evolves through well-defined states.
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.
Work Product: A tangible result or artifact produced by activities to provide evidence of an Alpha’s state. Examples include documents, models, code, or other verifiable outputs.
Competency: A human capability required to perform certain Activities effectively. Competencies define skills, experience, and knowledge levels associated with roles.
Practice: A reusable method fragment that defines how certain aspects of software engineering should be addressed. Practices can be combined to form methods.
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).
CBD (Component-Based Development): Component-Based Development (CBD) is a software development approach in which systems are constructed and reused through components that define clear responsibilities, contracts, and interfaces. Components are designed to be independent and replaceable, enabling loosely coupled architectures that improve maintainability and reusability. In the logical model, a component serves as an abstract structural unit defining functionality and contracts; in the physical model, it corresponds to implementation and deployment units.
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.
CML (Cozy Modeling Language): CML is a literate modeling language for describing Cozy models. It is designed as a domain-specific language (DSL) that forms the core of analysis modeling in SimpleModeling. CML allows model elements and their relationships to be described in a narrative style close to natural language, ensuring strong compatibility with AI support and automated generation. Literate models written in CML function as intermediate representations that can be transformed into design models, program code, or technical documentation.
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.