From Business Processes to Software Product

In the previous chapters, we described how a single business process is modeled and executed. In this chapter, we step back and look at the bigger picture: how business processes, use cases, and logic layers come together to form a software product.

From Business Processes to Software

Software products are created to support real business activity. Paper forms are replaced with screens, manual actions are automated, and decisions are made consistently according to rules.

Each physical business process must therefore have a digital representation. In software, that representation is a program or application.

A software program is a digital representation of a business process.

A software product is usually composed of many such programs. For example, a dental clinic information system may include:

• A web application for patients
• A desktop application for receptionists
• Applications for doctors, pharmacies, and administrators

Together, these programs form a single software product.

Software Product as a Set of Use Cases

We already know that a business process consists of sub-processes, and that a use case is a practical unit of such a sub-process.

This allows us to restate the definition:

A software product is a set of programmed use cases.

The diagram below illustrates this idea.

Each use case is isolated and can be developed independently. It does not need to know about other use cases to perform its work.

Some use cases are specific to one product. Others are generic and can be reused across multiple products, such as person registration or authentication.

Application Use Case

Independent use cases alone are not enough to represent a complete software product. Something must control the overall flow from the start of a business process to its end.

This role is performed by a special use case called the application use case.

The application use case:

• Starts and ends the business process
• Controls transitions between use cases
• Applies business rules to guide the overall flow

Functional and Non-Functional Architecture

The set of use cases represents the functional architecture of a software product. It defines what the product does from a business perspective.

To work reliably, functional architecture relies on non-functional architecture. This includes components responsible for:

• Error handling
• Logging and monitoring
• Security and communication
• Infrastructure services

Software Product Logic

From the Business Process Activities chapter, we learned that different types of logic participate when a business process transition is executed.

These logic types form logical layers within a software product:

Each layer has a distinct responsibility and can be developed independently. Together, they implement the functional architecture of the product.

Summary

In this chapter, we looked at a software product not as a technical artifact, but as a structured realization of business processes.

We saw that a software product is composed of multiple use cases, each implementing a business sub-process. These use cases can be developed independently and reused across different products.

An application use case coordinates individual use cases and controls the overall flow of a business process from start to end.

Inside each use case, execution is organized into logical layers with clear responsibilities:

• State logic selects the handler for the current business process state.
• Business logic decides which state comes next.
• Data processing logic prepares decision-ready information.
• Data access logic performs CRUD operations on data stores.

Together, these layers form the functional architecture of the software product, while non-functional architecture provides the technical foundation that supports them.

With this structure, a software product becomes a clear, maintainable, and extensible implementation of real business activity.

Table of Content Introduction into Business Process Previous: Transition Execution Pipeline