Architecture Portal

Connect business goals to what teams build, run and evolve

Architecture Portal is being reactivated as the home of a living architecture programme: a practical method, a logical system blueprint and working material that change when delivery and operation teach us something new.

Keep the purpose intact as the service changes

A service begins with a purpose, but that purpose must survive many changes of form. People agree how the organisation will work. Teams define the information, software and technology. They deliver the service, operate it, support people when it fails and decide whether it remains safe and useful.

Architecture connects those responsibilities. It is not a design stage that finishes when implementation begins. A test result, a support call or a failed recovery can reveal that the original account of the work was wrong. The architecture must be able to change in response.

Run architecture as connected learning loops

The proposed method describes six delivery loops: purpose, domain, blueprint, delivery, operations and assurance. A seventh loop decides what a project has taught the wider portfolio.

Each loop has settings for cadence, batch size, coordination, decision authority, automation and required proof, and the reach of new learning. These are the useful delivery dials. They show why a staged project behaves differently from an evolutionary one, why high-assurance work adds challenge to every increment, and where an agent may act without taking a decision that belongs to a person.

Assign ownership before choosing products

The system blueprint names the logical responsibilities that a complete service repeatedly needs. It asks who owns a business record, who may request a change, who returns a decision, who notices a failure and who can recover the work.

Those answers come before product selection and deployment design. One program may perform several logical roles; several services may share one larger responsibility. The blueprint gives a team something stable to discuss while leaving those implementation choices open.

Build from working components

The wider portfolio already contains working language, execution and editor components. CREXX compiles cREXX, assembles RXAS, links modules and runs bytecode on its virtual machines. DSLSH keeps an editor and parser synchronised. THE CREXX Edition uses that connection in a working editor and offers an experimental browser interface with documented limits.

Other projects explore particular blueprint roles. crexx-rag retains a native executable reference and has accepted cREXX capability slices plus a storage foundation; its target cREXX product remains incomplete. Cognitive Pipelines is a working experimental desktop graph application for artificial intelligence (AI), retrieval, scripts, tools and human-input steps. Open BPM, the new CoreLang common base and every proposed cross-project composition remain to be built.

The current-work page separates these working components from the next proposed slices and links each claim to its project home.

Let each delivery slice improve the programme

The retained domains and earlier architecture, language and interoperability work show continuity. They are source material for a reactivated programme, not a closed archive or a set of current technology recommendations.

Agentic tools can shorten research, implementation, checking and documentation cycles. They work inside the same delivery loops: people set their authority, review consequential decisions and decide what proof is enough. Progress is shown through dated changes, decisions, tests, observed limitations and human approval, not through a promise that automation makes future delivery instant or safe.

Choose a starting point

Use the method, blueprint or working material

/method

Tune the loops that connect intent to operation

Six delivery loops and one wider portfolio-learning loop keep architecture in contact with implementation and operation. Their settings explain how staged, evolutionary, high-assurance and agent-assisted delivery differ in practice.

/blueprint

Own the record, decision, failure and recovery

The system blueprint turns the loop method into named logical responsibilities. It helps a team agree who accepts each request, owns each fact, reports each result and restores the work before products and deployment units are chosen.

/assets

Ask the questions that expose a real decision

Five compact question sets help a team agree the outcome, tune the delivery loops, assign component responsibility, preserve a decision and rehearse failure. Use only the prompts that improve the work.

/examples

See what works now and what remains to connect

Working CREXX, DSLSH and THE components cover language, execution and editor responsibilities. crexx-rag and Cognitive Pipelines contain current software for separate retrieval and desktop-orchestration roles. The new CoreLang language, Open BPM reference component and every cross-project composition remain proposed.

/glossary

Use the programme's terms precisely

These definitions support the method, blueprint and project map. They distinguish logical responsibility from deployment, working software from proposed composition and agent assistance from human authority.

Related work

What the other projects contribute

  • Public Purpose Lab may apply the blueprint in synthetic demonstrations and return lessons from them.
  • Open BPM is the proposed reference work-management component.
  • DomainLang and CoreLang develop the business-language direction.
  • CREXX, DSLSH, THE, crexx-rag and Cognitive Pipelines contain current work at different maturity.