LAF setup

4. LAF setup

4.1 Best practices

4.1.1 Common language

A critical success factor for LAF implementation is establishing a shared vocabulary across business leaders, developers, and architects. Clear common language enables productive architectural discussions across non-technical and technical stakeholders.

This vocabulary should remain concise, grounded in plain definitions of Applications, Capabilities, and domain targets.

Domain-Driven Design (DDD) concepts are strongly recommended as a foundation for establishing a ubiquitous domain language.

4.1.2 Division

Large enterprises operate complex business models with diverse product and service lines. In such environments, Reference Architecture should be segmented into domain-specific reference architectures mapped along value streams or organizational units.

4.1.3 Architecture Log

Organizational turnover and evolving business models require a persistent decision history. Maintaining an architectural knowledge base ensures continuity and strategic alignment over time.

The Architecture Log acts as a decision repository tracking key events, such as:

  • procurement decisions for new technologies, Applications, or Components;
  • approved exception to the Reference Architecture or Standard;
  • publications of new Reference Architecture versions or Standards; and
  • decommissioning approvals for Applications and Components.

4.1.4 Continuous Improvement Sessions

Architects should hold bi-weekly or monthly continuous improvement sessions lasting 1.5 to 2 hours. Retrospective methodologies widely adopted in Agile frameworks should be adapted for these sessions. Architects also participate in standard SDLC retrospectives, bringing key engineering insights back to the architectural continuous improvement meetings. Example outcomes include updating component evaluation or refining SV document templates.

4.1.5 Fast Tracks

Not every initiative requires a full Solution Vision. Minor updates confined to a single Application that do not alter core capabilities should follow a fast-track approval process.

4.2 Anti-Patterns

4.2.1 Rigid Target Architecture

A common pitfall in LAF adoption is misinterpreting Reference Architecture as a rigid, multi-year transformation master plan complete with fixed schedules and budget estimates. Such rigid plans struggle in dynamic market conditions and are frequently abandoned at the first delivery obstacle, jeopardizing overall governance. LAF advocates for incremental progress toward an adaptable reference architecture that evolves with business conditions.

4.2.2 Deep design 

Architects who are not developers of that Application and do not work directly on implementation should not design the implementation of functionality in a given Application. Teams of programmers are responsible for the technical design. The teams agree on specific functionalities with business. Architects should build the basis for implementing functionality in the form of API guidelines, integration methods, and major technological changes. The most efficient model for implementing architecture is the participation of architects in the life of development teams. This participation depends on the type of project and its stage. At the beginning of the project, we recommend the Architects should closely collaborate with the development team. In the later stages, the Architect should support the team as needed.

4.2.3 Architects out of SDLC

When architects operate in isolation from development pipelines and business units, they lose visibility into system states and real-world delivery constraints. Consequently, application teams implement localized solutions without broader context, prioritizing short-term fixes over long-term stability. Architects must remain embedded in the SDLC to guide sustainable technical strategy.

4.2.4  Architecture as a bottleneck

Excessive documentation standards and bureaucratic approval processes turn architecture into an operational bottleneck, leading teams to bypass governance. Repositories and artifacts should adhere to lean data principles, capturing only essential details required by stakeholders.

4.2.5 Architecture blind to AI

If Reference Architecture and Standards exist only as documents intended for people, while development teams rely on AI to generate code, the architecture effectively stops being applied – because an AI agent does not consult a wiki or a document intended only for human consumption while generating code. Warning signs of this anti-pattern should be observed in Metrics.

4.3 Tools

LAF principles are tool-agnostic and can be managed using basic spreadsheets. However, automating workflows and centralizing repository storage improves analytical capabilities. Recommended tooling includes:

  • a centralized repository database supporting multi-user concurrent access especially AI agents
  • an architecture portal hosting standards, logs, and reference architectures;
  • automated survey tools for capturing end-user feedback;
  • automated integrations with static analysis tools and issue tracking systems; and
  • automated metric aggregation platforms.