SimpleModeling Development Process with Essence Framework

ASAMI, Tomoharu Created: 2026-04-20

The previous article described the SimpleModeling development process in the AI era as an executable structure centered on BoK (Body of Knowledge), Cozy, CNCF (Cloud Native Component Framework), and SKILL.

This article redefines that development process using the Essence Framework. The goal is to clarify SimpleModeling not merely as a procedure, but as a Development Process composed from a Kernel and selected Practices.

Background

SimpleModeling is a development process based on the Unified Process and structured for the AI era. A development process is a framework that defines the activities, roles, work products, and way of progressing software development.

This article defines that development process using the Essence Framework.

Defining it with the Essence Framework makes the development process easier to handle as a set of composable parts. By organizing it around a Kernel and Practices, the necessary elements can be selected and combined according to purpose and context.

This organization also provides a foundation for process modeling oriented toward SKILLization. By making the relationships among Activities, Work Products, Roles, and Automation explicit, the process becomes easier to describe not only as a method for humans to read, but also as a structure that AI agents can interpret and assist.

Essence as the Foundation

The Essence Framework defines the essential concepts common to software engineering as a Kernel, and provides a way to compose Methods by combining Practices on top of it.

SimpleModeling uses the Essence concepts as follows.

Concept Role in SimpleModeling

Kernel

The common foundation for all Method Views.

Alpha

Things that evolve and are assessed during development, such as Opportunity, Stakeholders, and Requirements.

Practice

A selectable unit used to compose a Method.

Activity

An abstract work unit contained in a Practice.

Work Product

An artifact created or updated by Activities.

Competency

The capability required to perform Activities.

In SimpleModeling, a Practice is the unit of Method composition, an Activity is the unit of execution, and a SKILL is a concrete procedure that assists or automates an Activity.

Development Process and Method

In SimpleModeling, a development method is defined as a combination of selected Practices on top of the Essence Kernel.

Development Method Development Method Development Method Kernel selected Practices uses combines

A Development Process adds process flow, work products, roles, AI agents, automation, and lifecycle to this development method.

Development Process Development Process Development Process Development Method Process Flow View Work Product View Role and Agent View Automation View Lifecycle View includes

SimpleModeling Practice Groups

Practice Group is a classification concept introduced by SimpleModeling. It is not a standard Essence element.

A Practice Group is a toolbox for selecting Practices. A Method is not composed from Practice Groups directly; it is composed by selecting Practices.

At this stage, the following Practice Groups are assumed.

Practice Group Purpose

Essence Practice Group

Holds Practices derived from the Essence references.

Solo Development Practice Group

Holds Practices suitable for solo development.

SimpleModeling Practice Group

Holds tool-independent SimpleModeling Practices.

SimpleModeling with Cozy Practice Group

Holds SimpleModeling Practices based on the Cozy product family and CNCF.

A Practice Group is a classification, not an ownership relation. A Practice may be referenced from multiple classification viewpoints when needed.

Baseline Method View

As the baseline for the standard SimpleModeling Development Process using Cozy and CNCF, the following Method View is defined.

SimpleModeling with Cozy Development Method View SimpleModeling with Cozy Development Method View SimpleModeling with Cozy Development Method View Kernel selected Practices uses combines

The candidate selected Practices are as follows.

This Method View treats AI-assisted solo development as the standard operating mode. Therefore, it selects Scrum Solo Practice rather than Scrum Lite.

For requirements description, Use Case Lite Practice is used as the baseline. User Story Lite Practice is treated as an alternative Practice.

Process Flow View

The Process Flow View arranges Activities from selected Practices into a concrete development flow.

As a draft, the minimum iteration cycle can be defined as follows.

  1. Prepare the development environment.

  2. Clarify the business context and goals.

  3. Describe requirements using Use Case Lite.

  4. Decompose use cases into slices.

  5. Specify acceptance conditions using BDD.

  6. Define the domain model and component structure.

  7. Generate code, tests, and documentation.

  8. Validate through the CI/CD pipeline.

  9. Improve from the viewpoints of operation, observation, and security.

This flow is not a fixed waterfall sequence. Activities iterate and update work products as development progresses.

Practice, Activity, and SKILL

SimpleModeling introduces SKILL to connect Essence Practices and Activities to AI-era execution units.

Practice to SKILL Mapping Practice to SKILL Mapping Practice Activity SKILL

A Practice is an abstract unit used to compose a Method. An Activity is work performed within a Practice. A SKILL is a concrete procedure used by a human or AI agent to perform an Activity.

Not every Activity can be fully represented as a SKILL. Activities involving judgment, dialogue, and decision-making remain human-led, with AI assistance.

Work Products

The Work Product View defines artifacts created or updated by Activities.

Representative Work Products include the following.

  • Vision and business context

  • Use Case Lite descriptions

  • Use Case slices

  • BDD scenarios

  • BoK documents

  • Cozy domain models

  • Component models

  • Generated source code

  • CNCF execution components

  • Test cases and test reports

  • CI/CD pipeline definitions

  • Release notes

  • Operation and security notes

These artifacts should not be mere documents. They must have a structure that AI agents can read, update, and use as input for subsequent Activities. Components executed on CNCF are also treated as part of this work product structure.

Role and Agent View

In AI-era SimpleModeling, roles are not assigned only to humans. AI agents are also treated as actors that execute or assist Activities.

As a draft, the following roles can be defined.

Role Responsibility

Product Owner

Decides goals, value, and priorities.

Solo Developer

Handles design, implementation, validation, and operation across the process.

Modeling Agent

Assists in creating requirements, BoK, and domain models.

Generation Agent

Generates code, tests, and documentation from models.

Review Agent

Assists with consistency, quality, and security review.

Automation View

The Automation View defines which Activities are assisted or automated by SKILLs and tools.

Initially, manually performed Practices and SKILL-assisted Practices are used together.

Automation targets can be expanded gradually as follows.

  1. Checklist and review assistance.

  2. Generation of models, tests, and documentation.

  3. Execution of CI/CD and quality gates.

  4. Operational observation and improvement suggestions.

Lifecycle View

The Lifecycle View defines how the Development Process progresses over time.

SimpleModeling refers to the Unified Process phase structure while treating it as a lightweight lifecycle suitable for AI-assisted iterative development.

Phase Focus

Inception

Clarify goals, stakeholders, and primary use cases.

Elaboration

Establish architecture, domain model, and major risks.

Construction

Generate, validate, and integrate functionality by slices.

Transition

Release, operate, observe, and improve.

Open Issues

This article is a draft template. The following points will be refined later.

  • The exact scope of Practices derived from Essence references.

  • The boundary between Use Case Lite Practice and CML Use-Case Modeling Practice.

  • Conditions for extracting BoK Practice as a tool-independent Practice.

  • A checkable file structure for Practice, Activity, and SKILL mappings.

  • How to derive purpose-specific Development Processes.

Conclusion

By defining the SimpleModeling Development Process with the Essence Framework, the development process can be composed as a set of Practices and connected to an executable structure through Activities and SKILLs. By positioning CNCF as the execution foundation, generated components can be connected to a running system.

With this structure, SimpleModeling can evolve as a Development Process that integrates AI-assisted solo development, model-driven development, and continuous generation, validation, and operation.

References

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.

Kernel

The foundational subset of Essence containing the minimal concepts necessary to define and reason about any software engineering endeavor. It includes Alphas, Activity Spaces, and Competencies.

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.

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).

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.

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.

Competency

A human capability required to perform certain Activities effectively. Competencies define skills, experience, and knowledge levels associated with roles.

Development Method

A development method is a conceptual framework composed of models and model transformations that define the structure and semantics of software systems. Examples include object-oriented design, domain-driven design (DDD), and model-driven development (MDD). A development method provides the structural foundation that defines what is to be built and how it should be represented.

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.

BDD (Behavior-Driven Development)

Behavior Driven Development (BDD) is a development approach that focuses on specifying system behavior through scenarios written in a shared language.

observation

Observation is the recorded form of phenomena that are judged worthy of being noted and stored. Observations serve as the foundation for logging, monitoring, auditing, and troubleshooting.

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.

validation

Validation is the activity of confirming that a system or product fulfills its intended use and stakeholder requirements.

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.