System Gist helps business stakeholders, information architects, and developers describe what a software system must know and do without tying that description to a particular technology or user-interface style.
Definition
System gist is the system description stripped of fashion and modernity. It describes the information a system handles and the business rules that govern how that information can change.
For example, an order-handling system may need to represent customers, orders, order lines, products, and shipment status. A rule might state that a shipped order cannot be cancelled. These concepts and rules are system gist. Whether the system uses a web application, a particular database, or a current visual style is not system gist.
Separate gist, modernity, and fashion
Software contains work with different reasons for existing and different rates of change.
| Area | What it covers | Example in an order-handling system | Main driver of change |
|---|---|---|---|
| System gist | Domain information, business rules, and the actions that create business value. | An order has order lines; an order can be shipped only when payment is confirmed. | Internal and external business-process changes. |
| Modernity | Infrastructure and technical delivery choices, such as database, transport, programming language, physical tiers, and hosting. | Replacing an on-premises database with a cloud-hosted database or moving from a desktop client to a web client. | Changes in software infrastructure and technical requirements. |
| Fashion | Look and feel, including user interface and user experience choices. | Changing colours, spacing, icons, or navigation presentation to match a new design standard. | Design trends and audience expectations. |
A change to a web framework is a modernity change. A new visual design is a fashion change. Neither change should require redefining what an order is or when it may be shipped.
Why maintain system gist separately
When system gist, modernity, and fashion are mixed together, a technology replacement can force a broad rewrite even when the business operation has not changed. Keeping the areas separate lets you evolve each on its own lifecycle.
For example, a warehouse may replace handheld devices and network infrastructure while retaining its definitions of stock item, storage location, pick list, and stock movement. The warehouse rules remain useful even though the delivery technology changes.
System gist is also part of the organization's structural knowledge. A maintained model gives stakeholders and developers a shared, precise language for discussing changes. Instead of asking for âa change to the shipping screen,â they can discuss whether the business permits a shipment to be reversed and what information that reversal requires.
Describe the gist in a model
Use a model to capture the domain language, structure, and rules. UML is the recommended language for describing system gist because it lets you define domain concepts and their relationships in a form that can be maintained and discussed.
In MDriven, the model is the place to invest in the system gist. A model can describe concepts such as Order, OrderLine, and Product; their associations; and the rules that protect their dynamics. The model can then be executed by delivery mechanisms whose modernity can change over time.
Do not treat prose requirements or team memory as the primary record of system gist. Prose documentation cannot be compiled or executed, and team knowledge can create a gap between the people who understand the system and the people who make business decisions.
Model-centric approach
Use this approach when you plan or evolve a domain-specific system:
- Identify the domain information that creates value. For a booking system, this can include
Booking,Guest,Room, andStay. - Define the business rules that govern the information. For example: a room cannot have overlapping confirmed stays.
- Capture the concepts and rules in a UML model using the domain's own language.
- Keep infrastructure choices in the model executor and delivery mechanism. For example, choose the database and deployment environment without changing the booking concepts.
- Change user-interface presentation independently from the domain rules. For example, redesign a booking calendar without changing the rule that prevents overlapping stays.
- Include management in governance of the system gist so that business decisions are made from an explicit, maintained description.
Avoid the meta-system shortcut
A generic meta-system can be universal in the sense that it can be configured to represent many systems. This does not make it the best representation for a specific domain. Folding a domain's gist into generic configuration structures can make the gist harder to read, evolve, and maintain.
For example, a SharePoint list definition can represent information for an approval process. It does not necessarily provide the clearest maintained description of approval concepts, responsibilities, and business rules. Model the approval domain directly instead: ApprovalRequest, Approver, Decision, and the rule that all required approvers must decide before completion.