Architecture Portal

Systems

Applications, integration, software and business rules.

Adrian Sutherland · Version 1.0 · · © 2005–2026

A request and its result

A member of staff accepts a case transfer, but the response is lost. The screen shows a timeout. The architecture needs to establish whether ownership changed, who can find the result and how a retry avoids a second transfer.

The Systems aspect connects application responsibilities and their interactions to the software that fulfils them. An interface contract defines what may be requested and what acceptance means. Components, rules and storage behaviour must preserve that contract.

From responsibility to behaviour

Question Explore
Which application owns each fact and operation? Integration and responsibilities
How do components implement the contract? Software and business rules
Which descriptions and approaches help? Compare approaches
What changes together, and what reopens a decision? Cycles and decisions
What would the records look like? The case-service example and templates

A logical component may be a module, part of an application or a separately deployed service. Choose its packaging with the relevant constraints. The Technology aspect develops runtime, environment and recovery arrangements.

Business meaning and authority

Business architecture establishes the purpose and capabilities a system is intended to serve. A business rule has an owner and meaning before it has an implementation. Process identifies who owns business policy and describes work, agreement and handover; Information defines the facts on which a rule depends. Some rules are applied by people. Software implementation needs an explicit contract for the rule, permitted state changes and failure behaviour.

Security governs access and permitted actions. A mobile client can retain a proposal while offline; an AI step can propose a summary. Neither establishes accepted case ownership. The responsible service checks the authority and current facts when it accepts a change.

Speed and quality

Observe the time needed to connect a consumer, locate a rule, make an accepted change and recover an unknown result. Include support and coordination effort, defects and the cost of replacing dependencies. The integration and software guides develop these questions at their respective levels of detail.

Methodology configuration

Map applications, services, modules, rules and interface records to the responsibilities they carry in your method. Link the business decision to the exchange, its implementation and the checks that establish acceptance. Use Methodology configuration to relate those records to your own design, delivery and review steps.

About this edition

Refreshed for the September 2026 website update. This edition develops the earlier Architecture Portal and ASAF material; the fictional worked example was added in 2026.

Scope, limitations and next checks

Status and accountability

Read this page with its boundaries visible

Status

In development

Last reviewed

Intended users

  • Architects comparing and adapting their existing approach

Non-goals

  • A mandatory method or a prescribed implementation

Limitations

  • Guidance; the fictional service has not been implemented and its proposed checks remain unrun.

Next evidence sought

  • Review the reader journey and apply the records with a practising architect.