The business decision
Imagine a training provider cancelling a course. A learner wants an acceptable alternative, but the booking and course teams each expect the other to arrange it. The immediate architectural question is who owns the resolution and what the teams need to know. New software is one possible response; a clearer responsibility and a shared record may be enough for the first change.
Business architecture connects what an organisation wants to achieve with what it must be able to do, how people work and the information they need. Use it to make a business choice, such as changing a service, organising a team or deciding which part of an operation to improve first.
Connected views
Business architecture brings several aspects of A Simple Architectural Framework (ASAF) together. Process examines the activities and handovers; Structure examines the organisation and authority behind them. Both develop the business choices described here.
| View | Question in the training example |
|---|---|
| Purpose and outcome | What would count as an acceptable resolution for the learner? |
| Capability | What must the provider be able to do? Here, resolve a cancelled booking. |
| Value stream | Through which stages does the learner receive that value: understand the options, agree a resolution, receive confirmation? |
| Process | Which activities and handovers provide it? Who contacts the learner and arranges the replacement? |
| Organisation (Structure) | Who owns the case, accepts exceptions and supports the people doing the work? |
| Information and rules | What must be recorded, what does it mean and which decisions require the learner’s agreement? |
| Change | What can improve now, what depends on other work and what finding would change the plan? |
These are working distinctions. A capability describes an ability; a process describes how work happens. A value stream follows value reaching a stakeholder. They give different views of the same service. Record their relationships where those relationships affect a decision or handover.
The information-and-decisions diagram below shows one way to connect them. Its arrows describe relationships, rather than a required order of work.
Methodology configuration
ASAF provides a starting structure to tailor to your methodology or framework. It separates the subjects being considered, the work used to examine them and the level of design detail: conceptual, logical or physical.
Map the terminology and steps here to those you use. For example, your method may describe the people using a service as actors rather than users. Relate the roles by what they do and the information they need. Map our cycles to your own activities, stages and reviews in the same way.
This mapping gives a basis for explaining relationships and trade-offs in your terminology. The Methodology configuration section introduces tailoring; further worked mappings will follow.
Compare the contributions of established approaches, then map the cycles and decisions in your own method.
From business choices to delivery
For the training provider, the first change could assign one case owner and record the learner’s agreement. A later increment could improve system support. Accepted purpose and rules should persist between increments unless a finding gives a reason to reconsider them.
Business architecture includes the relevant people, process and information relationships. More detailed organisation, data, software and technology views can develop those decisions further. Solution architecture brings the relevant views together for the particular change.
The information and data section develops the definitions, records and ownership behind these decisions.
The purpose view, customers, suppliers and channels develop the wider business relationships. Security connects possible harm to the safeguards needed across those relationships.
Speed and quality
Judge the method by time to a useful, accepted decision, effort spent waiting or reviewing, rework and the usefulness of handovers. Judge the resulting service by whether people can develop, operate, support and change it. Useful longevity needs a dated history of use and change; a new example cannot prove it.
Set a baseline where possible and name what remains unknown. Use later observations to judge whether the method and its records helped. The assessment guide brings those questions together.
Follow the worked cancellation example and try the three editable records. Use one record if it answers the question. Keep more detail when someone needs it to make a decision, carry out the work or accept a later change.