Enterprise Architecture for Enterprise Architects: A Guide

Application landscape design

Application architecture should optimize for clear domain boundaries, low coupling, and predictable change impact.

The best pattern is the one that your teams can operate reliably with your current maturity and constraints.

• Define domain boundaries before choosing monolith vs microservices
• Control API lifecycle with versioning, ownership, and deprecation policy
• Use dependency mapping to prevent cascading failure risk

Written for the practitioner, not the slide deck

If you do the work — mapping capabilities, untangling the application portfolio, planning a target architecture and keeping it governed — most EA content is too abstract to help. This page is about how the practice actually runs, and where a tool helps versus gets in the way.

It is honest about Archilu: claims are limited to features you can verify, and frameworks are treated as references you draw on, not a methodology you must perform before producing anything.

Start from capabilities, not applications

A business capability map is the most durable artifact you own: it describes what the organization does, independent of the systems that happen to support it today. That stability is what lets you compare current state to target, run heatmaps, and have a conversation with the business that survives the next reorganization.

Build it in levels (L1 to L3), assign owners, and you have the backbone everything else hangs on. The capability mapping guide linked below covers levels, ownership and heatmaps in depth.

Connect the application portfolio (APM)

Once capabilities are stable, connect the applications that support them. Application portfolio management lets you see coverage, overlap and gaps, and assess each application on cost, business value, technical health and risk.

A common lens is the TIME model — tolerate, invest, migrate, eliminate — which turns the portfolio into a set of decisions rather than an inventory. That is where rationalization candidates and target-state moves come from.

• Map applications to the capabilities they support
• Assess cost, value, technical health and risk
• Use TIME to drive invest / migrate / eliminate decisions

Make dependencies and impact analysis cheap

Architecture decisions live or die on dependencies: which application calls which, where data flows, what breaks if a system is retired. When that information is in a connected model, an impact analysis is a query you can answer in minutes.

When it lives across spreadsheets, every change request becomes archaeology. A connected repository is what makes dependency and impact work sustainable.

Target architecture and governance

Practitioners do not just document the present; they steer toward a target. That means a current-state baseline, a defined target, a gap analysis and a roadmap of moves — each governed so decisions are recorded and consistent with stated principles.

When decisions, policies and approvals sit alongside the model rather than in a separate document, governance stops being overhead and becomes part of how you work. Archilu keeps the architecture and the governance trail in one place.

Frameworks as references, a connected model as the engine

TOGAF gives method and vocabulary, ArchiMate a modeling language across business, application and technology layers, Zachman a classification ontology. Use them as references that sharpen your thinking — not as a ceremony to complete before delivering value.

The practical advantage of Archilu for an architect is the connected model behind all of this, with EU or on-premise hosting. To see where your own practice stands, the free EA Maturity Assessment scores ten dimensions and returns a prioritized plan in about ten minutes.

Application architecture KPIs

Use KPIs that reveal coupling risk and change friction early.

• Cross-domain dependency count on critical journeys
• API version deprecation compliance
• Change failure rate by architecture pattern
• Cycle time impact of integration dependencies

Common mistakes

Application architecture quality drops when teams choose patterns before clarifying domain boundaries.

• Adopting microservices before domain decomposition
• Scaling API usage without lifecycle governance
• Ignoring runtime dependency risk in design reviews
• Mixing tactical integration fixes with target architecture decisions

Practical checklist

This checklist helps teams avoid architecture churn and delivery risk.

• Map domain boundaries before selecting architecture patterns
• Define API lifecycle ownership and version policy
• Track critical runtime dependencies and failure modes
• Review integration debt in portfolio governance cadence