Software Planning 101: Part 3/7

The Levels of Abstraction for a Software Solution

To make decisions for the software dimensions, almost never the requirements alone provide enough information. The context around a decision needs to be understood. To capture the context we introduce abstraction levels.

Solution Abstraction Levels

An abstraction is used to focus on a specific aspect of the solution. A solution needs to be considered end-to-end. Therefore we introduce six abstraction levels.

Abstraction 1: Business Product

The value of the product to the business and the consumer are defined in this abstraction.

• What is the purpose of the company?
• What does the company try to achieve by creating this product?
• How does the product fit in the existing and future product portfolio?
• How does the product differentiate from other competitive products?
• What problem does it address of the consumers of the product?

This is often expressed through Vision, Mission, Objectives and Goals, competitor analysis, and more.

We try to understand: how the product is helping the business being successful.

Abstraction 2: Functional Product

In this abstraction the functional aspect of the product is defined.

• Who are the users?
• What features does the product have?
• What functionality is provided by the product?
• What information is used (consumed or produced) by the product?
• How do the users consume the product?

Documents that capture this are: Product Requirements Documents, Use Cases, User Stories, and more.

We need to understand the functionality that the product is delivering to the users.

Abstraction 3: Conceptual Architecture

This abstraction defines how the functionality of the product is accomplished. If well defined, and it should, this architecture can be used to manually mimic the required software, and thus understand what should happen by the software.

• What problems are we tackling and what is the approach?
• What are the concepts are involved?
• What (external) actors interact with the concepts?
• How do the concepts interact to accomplish a specific functionality?

This will be captured in Conceptual Architecture Documents. Conceptual architecture talks only about concepts and does not include any technical information.

This conceptual solution defines the what of the requested software solution.

Abstraction 4: Logical Architecture

This abstraction focusses on the high-level aspects of the software dimensions. The goal of doing logical architecture is to minimize the effort for future changes to the system.

• What entities do we need to model the concepts of the conceptual architecture?
• What components are needed to achieve the interactions of the conceptual architecture?
• What responsibility has what component?
• What is the high-level interface of a component?
• What are the dependencies of the components?
• How do all the components interact together to achieve a specific system functionality?
• How are the entities transformed into different data formats and models through the system?

All this is captured in the Logical Architecture Document of a system, written by a system architect. It only talks about logical data models/entities and components and does not include any specific technology decisions.

The logical solution focusses on the where of the requested software solution.

Abstraction 5: Technical Design

This abstraction level looks at a specific component of a system and how we can use what technology to implement the component. The goal is to minimize the effort and risk to implement a component.

• What technologies (programming languages, databases, etc...) are used?
• What configurations are needed?
• What is being logged?
• What exceptions can be raised?
• What classes/files need to be created?
• What code/statements need to go in what file?
• What data types, encodings, and transformations are needed?

The information is captured in a Technical Design Document, written by a software designer. It translates the non-technical description of the logical architecture into technology dependent implementation.

The technical design focusses on the how of the requested software solution.

Abstraction 6: Physical Operation

This abstraction level focusses on the exact behavior of the software in a production environment.

• What files are read/written?
• What network connections are set up?
• What mutexes are used?
• How much disk space is consumed by the application?
• How much CPU load is consumed by an application?

This layer is often not explicitly documented, but we name this layer, as maintaining and bug fixing first need to focus on this abstraction to understand what is going on. After they understand the behavior another abstraction level can be used to figure out what is going wrong where in code (if applicable).

Conclusion

Using the different abstraction levels helps to understand the requirements and the context of a product. To make a software plan for a product the solution abstraction levels can be leveraged. As defined earlier, software planning itself is only a step in the SDLC and thus does not cover all abstractions. A software solution plan defines the Architecture and Design: abstractions 3 - 5.