The two IT-focused artefact types in the Rules and Structures columns of the Alignment Matrix — IT Standards and IT Landscapes — are the technical infrastructure that makes everything else in an architecture practice coherent.
They are also, in many organisations, either absent or present but not used. Understanding why requires understanding what they are actually for.
IT Standards: defining the technical playing field
IT Standards answer: given the full range of available technologies and approaches, which ones does this organisation adopt as its norm? The most important type is the Technology Reference Model — a structured classification of every significant technology in the ecosystem, mapped against one of five lifecycle statuses:
Strategic
Actively invest and adopt. This is the direction the organisation is heading. New projects should use these technologies.
Current
Continue using and maintain, but don’t actively expand. Existing systems are fine; new projects should prefer Strategic alternatives.
Emerging
Evaluate and pilot. Not yet approved for production use, but under active assessment.
Retiring
Plan to replace. Approved for existing uses but not new ones. Systems using this technology have a remediation obligation.
Prohibited
Do not use. Regulatory, security, or strategic incompatibility makes this technology off-limits entirely.
A Technology Reference Model with these five statuses turns hundreds of individual technology decisions into a coherent framework. An architect reviewing a proposed IT Design no longer evaluates each technology choice from scratch — they check it against the Reference Model and either confirm compliance or surface a deviation.
Guidelines accompany the Reference Model. A Reference Model says which technologies; Guidelines say how to use them. Security Guidelines define approved authentication patterns. Integration Guidelines define approved messaging formats and API styles. Data Guidelines define how shared data entities should be modelled.
The over-constraint failure mode: Standards so rigid that project teams cannot comply without unacceptable delivery cost don’t reduce deviation — they just make the deviation undisclosed. If every project is requesting exemptions, or worse, simply ignoring the Standards, the Standards are miscalibrated. The right level of constraint is the one where competent project teams can comply with reasonable effort, and genuine deviations are identifiable exceptions rather than standard practice.
IT Landscapes: documenting reality
IT Landscapes answer: what does the IT estate actually look like right now? Three types:
Landscape Diagrams
Visual maps of the IT landscape at a defined scope and granularity. For strategic planning, a high-level diagram showing major application clusters and their relationships. For initiative planning, a more detailed view of the relevant domain.
Application Inventories
The structured data underlying the diagrams — a list of every application with its owner, technologies, business capabilities served, hosting environment, and strategic status. The factual basis for Technology Alignment analysis.
Enterprise System Portfolios
Bridge IT Landscapes and Business Visions by mapping the IT estate against the Business Capability Model, showing which systems support which capabilities, identifying capability gaps and redundancy.
The maintenance discipline for IT Landscapes is straightforward but requires deliberate commitment: update them. Every time a project delivers, every time a system is decommissioned, every time a technology changes. Landscapes that are updated quarterly at best become historical artefacts that nobody trusts. An architecture team that has stopped trusting its own Landscape documentation has lost the factual basis for every other planning decision it makes.