Blog

…or, welcome to your new legacy application.

Rewriting a legacy application requires understanding of the functional requirements. Often the application is a collection of CRUD-based screens. ^[1] Some vendors offer to rewrite your application and give you the equivalent functionality with a new user interface. They may even re-architect your system. But without a clear understanding of system functionality, they give you CRUD in a new guise. Welcome to your new legacy application!

Application modernization requires understanding the current use of the system and the business process context. In other words, you need use cases to describe the intended use of the system, not just the current data-focused view.

Apply these principles to avoid re-creating CRUD:

• Identify user goals.
• Put the system in the context of a business process.
• Separate the use case from the UI design.

User Goals

This blog emphasizes standard software engineering solutions. Use case modeling techniques help you identify user goals. CRUD use cases don’t relate directly to actor goals. They are data- or object-centric and are a conglomeration of actors goals.

Understanding individual actor goals in a legacy application leads to accurate modeling of actors. Good actors help drive out the functional requirements necessary for modernization.

Business Process Context

The business process view is often not seen in the individual legacy screens, which are business object based. Finding all the possible actions performed on a business object will not explain individual user goals or provide the business process context.

CRUD screens are a utility-like view of the system, divorced from the underlying business rationale. Use cases drived from CRUD tend to have names that include the words “maintain,” “manage” or “process.” With a business process context you move beyond CRUD value and format checking to use cases that include constraints, rules and lifecycle issues.

Applicable modeling technques include a clear separation of system and business models. Business process is not the same thing as a use case. A business process describes what happens in the business, which may or may not include IT automation. A use case, by contrast, describes user interaction with the system. Conflating these models leads to substantial confusion.

Use Case vs. UI

Don’t confuse the legacy application interface with use-case specification. That is how CRUD begets CRUD. Giving you a new, equivalent UI with the same, CRUD-like functionality does not constitute modernization. Use case modeling techniques suggests a clear separation between the system behaviour for user goals and the UI features. Functional requirement definition and UI design are not the same thing. Among other issues, including UI details means the use cases will never be finished.

1. ^[1] The "CRUD" acronym stands for the ability to Create, Read, Update and Delete the object. ↩