The information problem
A course has been cancelled. One team records an alternative as “agreed” when it has been offered; another uses the same word only after the learner has accepted it. Both records can be complete and neatly formatted, yet the next person may make the wrong booking.
Information and data architecture connects the meaning people need with the records, rules and representations used to carry it. In this section, information emphasises business meaning and use; data emphasises how that information is represented and handled. The two are considered together.
Business architecture connects information needs to purpose and work. The business example established the learner’s agreement and continuous case ownership. Here we examine what must be recorded to preserve those decisions through a handover or system change.
The useful questions
| Concern | Question for the cancellation case |
|---|---|
| Meaning | Does “agreed” mean offered, accepted by the learner or confirmed by the provider? |
| Identity and relationships | Which booking, learner, alternative and case does the agreement concern? |
| Responsibility | Who approves the definition, maintains it and corrects an individual record? |
| Lifecycle | How is the record created, changed, shared, retained and eventually retired? |
| Quality | What must be correct and current for the next person to act? |
| Origin and history | Which interaction supplied the agreement, and what changed afterwards? |
| Representation | How will the same meaning appear in a form, file, message or database? |
Start with the information needed for a decision. A diagram helps when its relationships explain a rule, expose an ambiguity or show the effect of a change. Definitions and examples should travel with it.
Levels of detail
At the conceptual level, describe the things that matter: a booking, a cancellation case, an owner and an agreement. At the logical level, define their identifiers, relationships, states and rules. At the physical level, show how the chosen forms, files, interfaces or databases realise those rules.
For example, an agreement belongs to a particular alternative. A logical rule requires that link to remain identifiable after a correction. One implementation might use a reference in a shared register; a later one might use linked database records. Both need to preserve the agreed meaning.
These levels provide views of the design at different detail. A discovery in an implemented record can send the team back to clarify a business definition. The cycles page follows that feedback.
Ownership and use
Separate responsibility for meaning from responsibility for each case. The service owner approves what an accepted alternative means. A data steward maintains definitions and resolves recurring quality issues. The case owner records the learner’s decision and follows it through to confirmation. A small team may assign several of these responsibilities to one person.
Identify the authoritative record for each fact and the other places that use it. Agree who may view or change it, what each recipient needs, how corrections reach copies, and when records should be retained or retired. These decisions connect the data view to Structure, Process, Security, Systems and Deployment and operations.
Speed and quality
For the architecture work, observe time to agree a definition, effort spent reconciling records and rework after a change. For the resulting service, observe incorrect bookings, unresolved ownership, correction effort and the ability to recover the reason for an earlier decision.
A useful data design should also be supportable and changeable. Follow what happens when a partner is added or a representation is replaced. Its useful life can only be assessed from a history of use and change.
Data at scale
A service-wide view brings further choices: medallion layers, batch or streaming processing, partitioning and derived results. Data at scale follows bronze, silver and gold through a small reporting example, then introduces MapReduce and the related processing trade-offs.
Security connects permitted use, disclosure and retention to the service’s risks, controls and assurance.
Data governance connects ownership, stewardship, quality, access and lifecycle decisions to the people carrying them out.
Methodology configuration
Your method may use “business object”, “entity” or “information concept” for parts of this description. Relate the terms by their meaning and scope. Definitions may live in a glossary, a model or a team’s existing records. Map definition reviews and delivery checks to the stages or iterations you use.
Methodology configuration introduces this approach to tailoring. Continue with selected approaches, the worked example and editable templates.