Architect-Methodologist: TOGAF and Change Management

Architect-Methodologist: Bridging the Gap Between Strategy and Code with TOGAF, Change Management, and Process Automation

Corporate architecture often remains a collection of PowerPoint slides—not because it’s poorly designed, but because there’s no managed, measurable, role-based, and automated bridge between its design and implementation. This gap results in ArchiMate target diagrams having no impact on development teams’ decisions, principles being violated by default, and technical debt growing linearly with each release. The solution isn’t a new methodology; it’s the synthesis of three components: engineering object management (TOGAF ADM Phase H), behavioral alignment of meanings (Organizational Change Management), and their operational fixation through automation in CI/CD, Jira, and repositories. An architect-methodologist isn’t a role in the org chart—it’s a function that unifies these layers.

Why Architecture ‘Floats’: Diagnosing the Gap Between Discovery and Delivery

In a typical IT process, the enterprise architect (EA) defines the target architecture, principles, and roadmap—but doesn’t participate in decision-making at the task level. The solution architect (SolA) designs a solution for a specific task, focusing on deadlines and the team’s current competencies, but without direct feedback from strategic artifacts. As a result, the implemented system aligns with neither model: neither the strategic nor the tactical one.

This isn’t a people problem—it’s a systemic governance defect. It shows up as a lack of clear answers to key questions:

• How does the architectural backlog translate into tasks in Jira and get validated in the pipeline?
• Who decides, and based on what criteria, whether to deviate from architectural principles?
• How do you measure how closely the actual architecture matches the target—not once a year, but with every PR?
• Where are responsibilities documented for each architectural artifact (e.g., ADR, integration description, encryption choice)?
• How do you ensure that a change in one service doesn’t violate security or data principles in another?

Without formalized interaction processes between EA, SolA, and DevOps teams, architecture becomes a metaphor rather than a tool.

TOGAF Phase H as the Foundation for Object-Based Architecture Management

The final phase of TOGAF ADM—Phase H (Architecture Change Management)—isn’t just “documentation support”; it’s a full-fledged engineering cycle for managing architectural objects. It defines exactly how artifacts change, who’s involved, which changes require approval, and which can be automatically reflected in the repository.

Key elements of Phase H in practical application:

• Management objects: architectural principles, technology selection standards (e.g., “PostgreSQL 15+ only for OLTP”), integration schemas (OpenAPI, AsyncAPI), ADR documents, data domain descriptions (in DAMA-DMBOK terms).
• Classification processes: distinguishing between simplification (streamlining the existing architecture), incremental (gradual introduction of a new component), and re-architecting (complete layer replacement). Each type has its own approval path—from automatic CI checks to Architecture Board meetings.
• Measurement metrics: percentage of tasks with a completed ADR, proportion of PRs automatically checked against OpenAPI specifications, number of rejected requests to use unapproved technologies, level of architectural debt according to SonarQube + custom rules.

Phase H provides the language, structure, and coordinates. But it doesn’t solve the question: why would a developer fill out an ADR if it’s not built into their workflow?

Change Management as Working with the Human Factor

Organizational Change Management (OCM) here isn’t HR training; it’s a technical discipline for managing participants’ perception, motivation, and behavior. Its goal is to make compliance with architectural rules a natural consequence of work, rather than an extra burden.

This is achieved through three levels:

• Communication in the language of value: instead of “you need to fill out an ADR”—“an ADR lets you spot integration conflicts early and avoid three days of debugging in production.”
• Training in the context of the task: embedded checklists in Jira templates, interactive tutorials in GitLab Wiki when creating a new service, examples of ADRs in the repository with comments like “why this choice was made.”
• Engagement through responsibility: explicitly assigning the “Architect” role in the review workflow, automatically adding it to the assignee list when a task moves to “Design Review,” generating reports on each role’s activity in architectural decisions.

OCM doesn’t replace TOGAF—it makes it applicable. Without it, architectural rules remain recommendations. With it, they become part of operational reality.

Automation as the Nexus Between Objects and Meanings

Automation isn’t just convenience; it’s the only way to make architectural constraints irreversible and measurable. The key principle: if a rule can’t be automatically checked in CI/CD or Jira, it doesn’t work.

Examples of implementation:

# Check for ADR before starting the pipeline
if [ ! -f "docs/architecture/adr-$(echo $CI_COMMIT_TAG | cut -d'-' -f2).md" ]; then
  echo "ERROR: Missing ADR for tag $CI_COMMIT_TAG"
  exit 1
fi

# Jira workflow: a task doesn’t move to ‘Ready for Dev’ until fields are filled:
# - ‘Architecture Decision Record ID’
# - ‘Data Domain Owner’
# - ‘Security Review Status’ = ‘Approved’

# Automatic OpenAPI v3.1 validation: compliance with internal versioning standards
# and mandatory securitySchemes
import openapi_spec_validator
from openapi_spec_validator import validate_spec
spec = load_spec('openapi.yaml')
assert spec['info']['version'].startswith('v2.'), "API version must be v2.x"
assert 'securitySchemes' in spec.get('components', {}), "Missing securitySchemes"

Such automation removes cognitive load, creates a single source of truth, and fosters a culture of accountability. Developers don’t “break the rule”—they simply can’t break it without explicitly disabling the check and explaining why.

What Matters

• The gap between Discovery and Delivery is a systemic problem, not a lack of competence: it arises from the absence of formalized interaction processes between EA, SolA, and DevOps.
• TOGAF Phase H provides an engineering framework for managing architectural objects: principles, standards, artifacts, and metrics.
• Organizational Change Management ensures that people adopt these objects through value-based communication, context-specific training, and role-based engagement.
• Automation in CI/CD, Jira, and repositories isn’t optional—it’s a mandatory element of IT governance: only this way can we guarantee rule compliance in daily operations.
• The architect-methodologist is a function, not a position: they master both the object model (TOGAF, ArchiMate) and behavioral practices (OCM), and know how to connect them through technical implementation.

IT governance starts not with setting up a committee, but with implementing a single automated rule—for example, checking ADRs in CI. The rest is scaling that practice: adding more checks, expanding roles, integrating quality and security metrics. The key is not leaving architecture as a presentation—it needs to be woven into code, pipelines, and workflows. Only then does it stop being slides and start governing.

— Editorial Team