STATE3 Enterprise / Architecture

Enterprise Architecture.

Capabilities, business activities, data, applications, integrations and technology in one model, described in the words your organisation already uses. There is no notation to learn, so the architecture team, a finance manager and a service owner can read the same picture and agree on what it says. We keep it simple on purpose, because architecture only helps when the people making decisions can read it.

Book a discovery call See it through your framework
One application, seen through the architecture lens Payroll Cloud at the centre. Highlighted architecture connections: supports the Pay staff capability, used by the Run payroll business activity, masters the Employee record, integrates with the HR Portal, runs on SQL cluster 02. Dimmed connections from other lenses: licences and contracts (ITFM), one open risk (Risk), an upgrade in review (Request). Pay staffCapability Run payrollBusiness activity EmployeeData · Masters HR PortalIntegration SQL cluster 02Runs on Licences, contractsCost · ITFM 1 open riskRisk Upgrade in reviewRequest Payroll CloudApplication
  • Payroll CloudApplication
  • Pay staffCapability
  • Run payrollBusiness activity
  • EmployeeData it masters
  • HR PortalIntegration
  • SQL cluster 02Runs on
  • Licences, contractsITFM
  • 1 open riskRisk
  • Upgrade in reviewRequest
Architecture view: capability, activity, data, integration and what it runs on Other lenses on the same record Illustrative record
What it answers

Architecture questions, answered from your own records.

"Which capabilities depend on products that leave support next year?"

  • Pay staff runs on a database version leaving extended support in March
  • Collect rates uses the same version on two servers
  • The future workspace shows the planned upgrade

"Which systems can change customer records?"

  • CRM creates and updates them, and is the master
  • Billing updates the address too
  • The CRUD matrix flags two systems updating the same field

"What changes between today and the target state?"

  • 3 applications retired, 1 added
  • 5 integrations move to the new platform
  • Deploy the future workspace once the change is made

Illustrative questions and answers. In STATE3 they come from your own records, and an AI assistant connected over MCP can ask them too.

Your framework

Read STATE3 through ArchiMate, TOGAF or Zachman.

You don't need a framework to use STATE3. If your team works with one, choose it below and select any box to see what STATE3 holds there.

1model behind every view
11record types in dependency analysis
17record types with an impact report
13record types you can import from a spreadsheet
Passive structure Behaviour Active structure Motivation Strategy Business Application Technology Physical Implementation & migration 1Business and technology capabilitiesHierarchies linked to applications and activities Glossary termsOne agreed meaning 2Business activitiesEvents and process flowsRACI for each activity Business unitsRoles, people, owners Data entitiesFields, classificationData map IntegrationsProtocol, frequencyData carried 3ApplicationsComponents, endpointsOwners ArtifactsNot modelled 4DeploymentsWhat runs whereBy environment 5InfrastructureServers, network, cloud 6Locations and sites Future and what-if workspaces · change requests · lifecyclesCompare with the current state, and deploy when the change is made PrinciplesAssessmentsRisks Goals anddriversNot modelled yet 1to6Follow one capability down to the server and the site it runs at ArchiMate full framework, simplified
Held in STATE3 Not held yet

ArchiMate® and TOGAF® are registered trademarks of The Open Group. Zachman Framework™ is a trademark of Zachman International. The diagrams are simplified schematics drawn by STATE3. STATE3 is not certified against these frameworks.

What's included

What you can model.

Business architecture

  • Business and technology capabilities, in a hierarchy as deep as you need
  • Business activities with criticality, and who is responsible, accountable, consulted and informed
  • Process flows: each step between people and systems, how often it runs, how long it takes and what it costs
  • Business units, roles and people, with positions and dates

Data architecture

  • Data entities with fields, data types, security classification and the system that masters them
  • A CRUD matrix of which systems create, read, update or delete each entity
  • A data map of how entities relate
  • A business glossary linked down to the field

Applications and integrations

  • Applications with components, endpoints, vendor, version, criticality and owners
  • Recovery point and time objectives, and whether each is in the disaster recovery plan
  • Integrations with protocol, frequency, criticality and the data they move
  • App Service connections found by the Azure connector

Technology

  • Servers with network details, operating system, capacity, backup and patch groups
  • Deployments: which application runs where, in which environment
  • Cloud resources brought in from Azure on a schedule
  • Locations on a map

Lifecycles and change

  • Lifecycle phases you define, on a timeline for each technology and in its impact assessment
  • Vendor support end dates, and contract dates with lifecycle dashboards
  • Future and what-if workspaces, compared with today and deployed when the change is made
  • Change requests with an impact report before approval

Governance

  • Architecture principles, checked through architecture assessments
  • Assessment findings recorded as risks with an owner and a treatment
  • Workflows with approvers for each step
  • Dependency analysis that finds single points of failure, and overlap analysis over MCP
The model

Define once, plan in workspaces, see the whole.

The Library holds your master list. Workspaces use it to model today, the target state and ideas to test, and consolidation brings them together into one view of the organisation.

How the Library, workspaces and consolidation fit together Step 1: the Library is the master list, browsed and maintained in the Hierarchy Explorer. Step 2: workspaces link to the Library. A future or what-if workspace is cloned from the current one, compared with it, then deployed or merged back; a change request holds the changes in one request. Step 3: several workspaces are combined into one read-only consolidated view, with duplicates removed by their Library entry, rebuilt on a schedule. 1Define once 2Model and plan 3See the whole The LibraryYour master listTechnologies, capabilities,business activities, roles,business units, people Hierarchy ExplorerBrowse the tree and blocksLink, promote, delinkReplace one item with another FutureThe target state What-ifAn idea to test CurrentToday's model Change requestThe changes in one request clone, compare, deploy merge back impact, approval linked items Finance · current ICT · current Property · current combine Consolidated viewThe whole organisationRead-onlyDuplicates removedby Library entryRebuilt on a schedule duplicates matched on the Library entry
  • The Library is your organisation's master list. A workspace item linked to it shows the Library's values, so a correction made once appears wherever that item is used. The Hierarchy Explorer is where you browse and maintain it.
  • Workspaces each hold a model for one purpose: the current state, a future state, a what-if or the changes in one request. Compare a future workspace with the current one, and deploy it once the change is made.
  • Consolidation combines several workspaces into one read-only view of the whole organisation and removes duplicates by their Library entry, so a technology recorded by five departments appears once. It is rebuilt daily, weekly or monthly.
Explore and analyse

Explore the model, plan its lifecycle, find overlaps.

Hierarchy Explorer

Browse capabilities, business activities, business units, technologies, infrastructure and people as a tree and as a block diagram, with link counts and logos on each block. Right-click an item to link it to the Library, promote it, delink it or replace it with another.

Technology lifecycle

Define your lifecycle phases once, then give each technology its dates. A timeline shows past, current and upcoming phases on the technology and in its impact assessment, next to vendor support end dates. Contract lifecycle dashboards drill through to the detail.

Overlap analysis

Ask an AI assistant connected over MCP which technologies support the same business or technology capability, or the same business activity. It answers from the links in your model, so overlaps show up without building a separate report.

What the other lenses add

One graph. Many lenses.

IT Financial Management

What it costs across licences, infrastructure and contracts, and which renewals are due.

IT financial management

Also read from the same model: IT Operations · CIOs and IT leadership

See your own architecture this way.

Book a 30-minute discovery call and we'll walk through it with you.

Book a discovery call