You can use information design to identify the business information a system must manage and express that understanding as a UML model before you focus on processes or user-interface technology.
Start with the information
Information design begins with what the business deals with: the information it receives, creates, changes, keeps, and uses to produce value. This information is part of the system's gistâthe enduring business meaning that should remain understandable even when delivery technology, user interfaces, or other modernity choices change.
When you understand the important information, you can investigate the processes that create or evolve it. Starting with a list of current process steps is less reliable: a process can continue because people are used to it, even when it no longer creates or changes information that matters to the business.
Use the principle follow the information. It serves the same purpose for a software architect as âfollow the moneyâ does for an investigation: trace what has value, where it comes from, who changes it, and what result those changes produce.
For example, a business that sells products may deal with customers, products, orders, and order lines. An order process is meaningful when it creates an order, adds the products requested by a customer, and records the result that the business needs to fulfil and account for the sale. A step that does not create, change, validate, or use information of value needs examination.
Why information comes before process
A process describes work performed at a particular time. It does not, by itself, show whether that work is necessary. The people performing a step may reasonably regard it as important, while people outside the process may lack enough context to evaluate it.
Information gives you a more stable basis for the discussion. For each process step, ask what it does to the business information.
| Question | What you are looking for | Example |
|---|---|---|
| What information exists before this step? | The business facts available at the start. | A customer has selected products but no order has been recorded. |
| What information does the step create or change? | A concrete, valuable change in the model. | The step creates an order and order lines for the selected products. |
| Why does that change matter? | The business value or later work enabled by the change. | Fulfilment can identify what to deliver to the customer. |
| What happens if the step is removed? | Whether another step supplies the same information or whether an essential fact is lost. | If no other step records the order, the business has no information from which to fulfil it. |
A step can also be valuable when it verifies or classifies information rather than creating a new record. For example, checking that an order has the information required before fulfilment changes the state of what the business knows about that order. The important point is that you can explain the step in terms of information and its value.
A practical information-design workflow
Use the following workflow when you begin to model a business area.
- Name the business area. Keep the scope small enough to discuss. For example: ârecording customer orders.â
- List the information the business needs to know. Use business nouns first. In the example, these might include Customer, Product, Order, and OrderLine.
- Describe the relationships between the information. Ask how the facts belong together. An Order belongs to a Customer; an Order contains one or more OrderLines; an OrderLine identifies a Product.
- Identify important changes. Ask what must happen to the information over time. An order may be created, receive lines, and become ready for fulfilment.
- Review each existing or proposed process step. State which information it creates, changes, validates, or uses. Mark steps for further investigation when no valuable information effect can be stated.
- Capture the result in UML. Use a class diagram to make the information classes, their properties, and their relationships visible to business stakeholders and developers.
Do not treat the first list as a final database design. It is a way to discover and discuss the business meaning. Refine names, relationships, and responsibilities as you learn more.
Describe information with UML
Unified Modeling Language (UML) is a standard modeling language for visualizing the design of a system. In MDriven, UML is the core language for defining models.
For information design, begin with a UML class diagram. A class represents a kind of business information, such as Order. An attribute represents a fact held by that class, such as an order date. An association represents a relationship between classes, such as the connection between an Order and its OrderLines.
The order example can be expressed conceptually as follows:
- Customer represents the party placing an order.
- Order represents the recorded sale to be handled.
- OrderLine represents one requested product and its place in an order.
- Product represents what can be requested.
- An Order is associated with one Customer and with its OrderLines; each OrderLine is associated with a Product.
This diagram does more than document names. It exposes questions that must be answered before implementation. For example: Can an Order exist without OrderLines? Can a Product appear on many OrderLines? Which information identifies the customer for an order? Discuss and model those business rules rather than leaving them implicit in process descriptions or code.
Continue with Training:Short introduction to UMLâ class diagram for the class-diagram notation used to express these decisions.
Keep the system gist separate from modernity
Information design captures the business meaning that you want to own and maintain. User-interface style, hosting choices, and other delivery mechanisms can change, but the meaning of Customer, Order, and Product should remain clear in the model.
This separation is central to the model-centric approach described in Training:What is next. The model can hold the system's documentation, know-how, and gist, while a model executor and user interface bring that model to life at the required level of modernity.
MDriven supports modeling, prototyping, and execution around this approach. Use MDriven Designer to work with the model; start by making the business information and its relationships understandable before you expand into detailed behavior and delivery.
Review checklist
Before you move on from an information-design session, confirm that you can answer these questions:
- What information is valuable to this business area?
- Which classes represent that information?
- What facts belong to each class?
- How are the classes related?
- Which changes in information represent meaningful business events?
- For each process step, what valuable information does it create, change, validate, or use?
- Can a stakeholder recognize the business meaning in the UML model without needing to inspect implementation details?