⏱ 21 min read
There is a tired debate in enterprise architecture circles that probably should have been put to bed years ago: TOGAF versus Agile.
In the real world, that argument is usually a distraction. The issue is rarely TOGAF itself. It is rarely Agile either. What usually fails is the operating model wrapped around them. I have seen organizations turn TOGAF into a stage-gate bureaucracy, and I have seen others use “Agile” as a convenient excuse for architecture amnesia. Neither produces good outcomes. Both create expensive messes, just at different speeds. TOGAF training
My view is fairly simple: ADM still works in a scaled Agile enterprise, but only when you stop treating it like a document production line and start using it as a decision system. That distinction matters in any large enterprise. In telecom, in my experience, it matters even more, because very few meaningful decisions stay contained within one system, one team, or even one technology stack. A product launch cuts across BSS, OSS, channels, networks, identity, customer data, regulatory controls, vendor platforms, operational resilience, and usually some awkward legacy estate that nobody wanted to touch this quarter.
So this is not another article trying to prove that TOGAF maps neatly to Scrum or SAFe or PI planning. That framing is a little too tidy to be useful. The more interesting question is where ADM needs to be reinterpreted when delivery happens through product teams, ARTs, platform teams, and portfolio governance, all moving at different speeds and usually responding to different incentives.
That is where the real work sits.
Telecom exposes weak architecture faster than most industries
Scaled Agile tends to expose architectural weakness quickly in telecom because the enterprise is already structurally tangled before transformation even begins.
You have legacy BSS stacks that were never designed for product agility. Separate product catalogs. CRM variants. Billing engines carrying decades of tariff logic that nobody wants to rewrite. OSS landscapes organized around network domains rather than customer journeys. Mediation platforms that still matter more than people like to admit. Inventory systems everyone depends on and very few fully trust. Channel inconsistency across retail, digital, partner, and contact center. Then add resilience obligations, privacy controls, lawful intercept, data retention, and the broader operational risk expectations that come with running critical national infrastructure.
Agile transformation lands in that environment and often hits a wall. Teams may get faster at delivering features, but the enterprise does not automatically get better at evolving capabilities in a coherent way. Release trains can improve local flow. They do not magically eliminate hidden dependencies across product, order, activation, billing, assurance, and customer communication. If nobody is actively making cross-domain architecture decisions, architecture becomes reactive. And when architecture becomes reactive in telecom, delivery speed becomes a bit of an illusion. The real delay simply reappears later as fallout, exception handling, operational workarounds, and launch defects.
A simple example makes that real.
Imagine a telecom operator launching a converged 5G + fiber consumer offer in six months. Commercially, that sounds obvious enough. Architecturally, it is messy. The mobile business has one product catalog and one fulfillment path. Fixed broadband has another. CRM screens vary by channel. Order decomposition is inconsistent. Billing treatment for discounts and bundles differs. Service activation spans both network orchestration and field operations. The customer app needs a coherent view of the offer, the order, the activation status, and support journeys.
This is exactly the kind of initiative where scaled Agile reveals whether architecture is actually helping delivery or just standing nearby and commenting on it.
First question: what is ADM actually for in an Agile enterprise?
This is the first decision leaders need to make, and a surprising number skip it.
If you treat ADM as a linear sequence with formal handoffs, it will clash badly with an enterprise where teams plan every two weeks, ARTs work in quarterly increments, platforms evolve continuously, and investment decisions move on a portfolio cadence. That is not because ADM is broken. It is because the interpretation is off.
In a scaled Agile environment, ADM works better as a recurring architecture decision cycle.
I usually see three viable interpretations.
First, ADM as portfolio architecture cadence.
Here, architecture supports investment framing, transformation themes, target outcomes, and major transition choices. It runs at a slower speed. Annual or semiannual, with quarterly refreshes. Think capability heatmaps, strategic roadmaps, modernization sequencing, and cross-domain priorities.
Second, ADM as domain architecture governance model.
This is where product, customer, order, billing, identity, inventory, or observability domains make rolling decisions about boundaries, patterns, standards, and exceptions. This is not annual work. It is ongoing, often monthly and sometimes on demand.
Third, ADM as value-stream or product architecture operating rhythm.
This sits closest to delivery. It shapes epics, supports PI planning, guides team decisions, and turns target-state intent into transition architectures that teams can actually build.
In telecom, you usually need all three. Just not with the same scope, the same participants, or the same artifacts.
One of the worst patterns I have seen is trying to run one giant enterprise-wide ADM cycle while release trains sprint every two weeks. It creates theater. Teams carry on regardless, and architecture becomes a parallel universe full of pristine diagrams and very little credibility.
Five failure patterns when people “combine” TOGAF and Agile badly
Let me be blunt. Enterprises often say they have blended TOGAF and Agile when what they have really done is preserve bureaucracy and relabel it. ArchiMate in TOGAF
1. Turning Solution Intent into a dumping ground
In SAFe-oriented organizations especially, Solution Intent can become the graveyard of architecture documentation. Hundreds of slides. Target-state diagrams nobody updates. Standards pasted in from old repositories. Teams stop reading it because there is no signal, only volume.
Useful architecture evidence is lighter and more deliberate: decision records, context diagrams, dependency maps, interface contracts, risk notes, transition-state definitions, and a short list of guardrails. If a team cannot find the relevant architecture constraint in five minutes, the repository has already failed.
2. Assuming every sprint needs architecture sign-off
This creates shadow waterfall.
I have seen architecture teams insist on reviewing every feature design, every API change, every schema update. The result is usually predictable: queues, workarounds, and teams making decisions off the books. Architecture then complains about lack of compliance, but the operating model created that behavior in the first place.
Review the high-blast-radius decisions centrally. Leave local design choices to teams.
3. Doing architecture runway without business architecture
This one is common and, from what I have seen, surprisingly expensive. Teams build cloud foundations, Kafka clusters, IAM services, API gateways, CI/CD pipelines, observability stacks. All useful in principle. But if those enablers are not tied to business capability evolution, they become elegant infrastructure in search of a reason to exist.
In telecom, business architecture is not optional. If order fallout in provisioning is your commercial bottleneck, architecture priority should probably start there rather than with abstract platform modernization goals.
4. Treating standards as immutable during modernization
This sounds disciplined. It is often naive.
Suppose the target enterprise standard is event-driven APIs with OAuth2, consistent schema governance, and near-real-time observability. Fine. But what if your mediation platform and some network-facing OSS tools cannot support those patterns without major vendor intervention? Forcing the standard literally can stall delivery and create brittle wrappers.
Standards need intent and pragmatism. Not all heterogeneity is failure. Some of it is simply transitional reality.
5. Separating network architecture from digital and business architecture
This is especially damaging in telecom. Customer journeys depend on provisioning, activation, assurance, and inventory realities. A beautiful digital channel design that ignores service activation constraints is not customer-centric. It is fantasy.
These failure patterns show up when ADM is applied literally rather than operationally.
A better way: ADM phases at different tempos
The most practical reinterpretation I know is simple: the ADM phases still matter, but they do not run at one speed or in one neat sequence.
Tempo matters more than textbook purity.
Some architecture work should happen annually or semiannually, especially where portfolio direction, principles, and strategic capability evolution are concerned. Some should happen quarterly around planning cycles. Some should happen continuously inside delivery.
That gives you a more realistic framing:
- Preliminary + Architecture Vision become strategy, operating model, and guardrails.
- Business, Data, Application, Technology Architecture become rolling domain decisions.
- Opportunities & Solutions / Migration Planning shape backlogs, roadmaps, and transition states.
- Implementation Governance becomes embedded governance through delivery, not a checkpoint at the end.
- Architecture Change Management becomes feedback from production, incidents, regulation, market shifts, M&A, and vendor change.
In other words, the phases survive. The choreography changes.
Here is the rough shape of it.
That loop is much closer to how real enterprises work than the classic linear picture ever was.
How ADM actually shows up in a scaled Agile telecom model
The classic TOGAF descriptions still help as reference points, but teams need outputs they can actually use. Not theoretical completeness.
The goal is not to reproduce the ADM mechanically. The goal is to make it usable.
Start with demand, not diagrams
Architects should enter the Agile planning cycle earlier than many do, but not carrying 80-page future-state packs.
The right entry points are usually portfolio prioritization, epic framing, value-stream problem definition, and dependency discovery.
Take another telecom example. Product management proposes a new enterprise SD-WAN offer. Before teams commit, someone needs to ask a few uncomfortable but useful questions:
- Can the current product catalog support configurable enterprise bundles?
- Is order decomposition reusable, or does every variant become custom workflow logic?
- Does service assurance telemetry support SLA reporting, or will account teams end up with manual reporting?
- Are partner APIs already available for provisioning and status exchange?
- Can IAM support enterprise admin hierarchies, delegated access, and audit requirements?
- If events are published through Kafka, which domain owns service lifecycle events and what is the contract?
Those are architecture questions, but they are also commercial qualification questions. Answer them early and you avoid committing teams to an initiative that looked attractive on the roadmap but was structurally undercooked.
I have found architecture adds the most value before commitment and during trade-off decisions, not after teams have already promised delivery dates.
How the ADM phases really change in scaled Agile
Preliminary: define decision rights before you scale anything
This is boring work, which is exactly why people skip it. Then they pay for it later.
Who decides what? Enterprise architects, domain architects, solution architects, product architects, platform architects, security, network specialists, data governance, risk. If decision rights are fuzzy, scaled Agile simply accelerates confusion. Sparx EA training
Telecom in particular needs explicit cross-domain ownership for product, order, inventory, and customer data. If mobile and fixed each believe they own the product model, you do not have a federated architecture. You have political latency.
The governance forums matter too. Good working forums are small, regular, and tied to live initiatives. The bad ones are presentation theaters with 20 attendees and no decision authority.
Architecture Vision: make it testable
Architecture visions are often too polished and too vague. “Enable omnichannel convergence through modular architecture” sounds sophisticated and means almost nothing operationally.
A better version is a hypothesis: A unified product model will reduce launch effort for converged offers by 30% over the next three quarters. Now you can test it. You can measure launch effort, reuse, order fallout, and channel consistency.
That shift sounds minor. It changes behavior. Teams engage more seriously when the architecture vision has measurable intent.
Business Architecture: still the most neglected phase
A lot of Agile transformations quietly underinvest here. They are strong on teams, ceremonies, and technical platforms. Weak on business capability analysis and operating pain.
In telecom, business architecture often points to the real priority faster than technology strategy does. If provisioning fallout is driving support calls, missed activation dates, compensation costs, and churn, then that should shape architectural investment. Not some generic “move to microservices” ambition.
Capability maps, value streams, failure points, operational KPIs, and regulatory constraints are what connect architecture to actual outcomes.
Information Systems Architectures: where domain boundaries get real
This is where nice theory meets recurring conflict.
Typical telecom decision areas include product catalog ownership, customer master boundaries, billing event models, inventory synchronization, event ownership, API patterns, and coexistence between event-driven and batch integration.
The useful rule here is straightforward: prioritize decisions that remove recurring team collisions.
If three ARTs repeatedly argue over who owns customer communication preferences, or if every product launch exposes the same mismatch between CRM, catalog, and order orchestration, that is where architecture should focus. Not on producing a universal application landscape diagram that nobody will use.
Technology Architecture: runway with consequences
Cloud, platform engineering, observability, IAM, CI/CD, security patterns, integration tooling. All important. But in telecom they collide with constraints quickly: latency-sensitive network interactions, sovereignty rules, vendor appliances, legacy mainframe billing, private connectivity, and operational resilience expectations.
I am strongly in favor of platform standardization where it genuinely helps. But I have also seen architecture teams oversell total standardization in environments where heterogeneity is structural. Some network-adjacent workloads should not be treated the same as digital channel workloads. Some appliances will never behave like cloud-native services, no matter how many reference patterns you publish.
The architecture job is to create enough consistency to reduce friction, not to pretend every constraint can be abstracted away.
Opportunities, Migration, Governance, Change: close the distance to delivery
This is where TOGAF becomes genuinely useful in Agile, if you let it.
Opportunities and Solutions should not produce one giant conceptual future. They should break large change into increments that teams can sequence. Migration Planning should line up with PI planning, funding windows, vendor dependencies, and regulatory deadlines. Governance should happen through decisions, exceptions, and evidence. Change Management should absorb production feedback continuously.
Production incidents, by the way, are architecture inputs. Not just operations problems. If repeated incidents expose weak retry patterns, poor observability, IAM token propagation issues, or fragile OSS integration, that is architecture feedback.
The running case: a converged 5G + fiber launch
Let’s walk the telecom example through this lens.
The operator wants to launch a bundled 5G + fiber consumer offer in six months. Existing estate: separate mobile and fixed product catalogs, fragmented order capture, different fulfillment stacks, a partially modernized API layer, Kafka used in some domains but not consistently, and IAM split between legacy channel identity and a newer customer identity service.
Architecture Vision
The first useful move is not drawing the target architecture. It is defining the launch objective and the non-negotiables.
For example:
- Offer must be available in digital and contact center channels at launch
- Single customer order status view required
- No manual rekeying between channels and fulfillment
- Discount handling must reconcile across billing domains
- Service activation status must be visible in the customer app
- Launch cannot materially increase order fallout
That already shapes architecture in a meaningful way.
Business Architecture
Then identify customer journey and operational breakpoints. Where will this launch fail in reality? Offer selection? Eligibility? Address validation? Bundle pricing? Order decomposition? Activation sequencing? Installation appointment handling? First-bill accuracy? Support visibility?
In one operator I worked with, the biggest issue was not catalog design. It was fallout between appointment handling and service activation, which then broke customer communication and generated avoidable support demand. Business architecture surfaced the operational breakpoint before the technical teams spent time optimizing the wrong layer.
Application and data decisions
Now the uncomfortable decisions start.
Do you federate the mobile and fixed catalogs and assemble the bundle dynamically? Or create a temporary bundle model in an orchestration layer? Do you create a unified order object now, or maintain separate domain orders with correlation? Does the customer app call a new aggregation API, or do you wait for backend harmonization?
There is no universally correct answer. There is only a trade-off.
A federated approach may be cleaner in the long term but slower to deliver. A temporary bundle model may get the offer out in time but creates debt. Sometimes the best decision is a consciously temporary compromise with a retirement date. That is not architectural weakness. That is architecture with a spine.
Technology decisions
Now come the platform consequences. Do you mediate existing APIs through the gateway or expose some legacy services directly? What events need to be published into Kafka for order and activation tracking? How will observability work across mobile and fixed fulfillment chains? Does IAM support a coherent customer session across the channels involved? Are there identity implications for linked household accounts?
These are not side details. They determine whether the launch can actually be operated.
Migration Planning
Finally, sequence the launch. Full national launch across all channels on day one? Probably risky. Better options might be digital-first, or selected segments first, or phased channels while field operations processes stabilize.
This is where transition architecture matters most.
That picture is usually more valuable to teams than a perfect end-state slide.
Transition architectures are the real bridge
This is the hard-earned lesson.
Target architectures are useful, but on their own they are too abstract for scaled Agile teams. Teams do not deliver “future state.” They deliver increments under constraints. A transition architecture is a bounded, time-aware design state that people can actually build toward.
In telecom, this is often the real bridge between TOGAF and Agile.
Examples:
- Moving from dual order capture to unified orchestration in stages
- Event-enabling billing before replacing billing
- Introducing an API façade over legacy OSS before deeper domain modernization
- Consolidating IAM gradually while preserving existing customer login paths
- Standardizing observability and tracing for cross-domain journeys before broader application refactoring
Every major epic should trace to a transition architecture, not just to a strategic aspiration. If it does not, there is a good chance the initiative is under-architected.
Governance without becoming the department of “no”
Classic review boards fail in scaled Agile for predictable reasons: too slow, too broad, too detached from delivery pressure.
Better governance is lighter and sharper:
- architecture guardrails
- pre-approved patterns
- a lightweight exception process
- recurring design clinics
- decision records linked to epics and features
- office hours during PI planning and implementation
In telecom, the things worth central review are the high-blast-radius issues: customer data movement, security model changes, network impact, resilience patterns, regulatory exposure, major platform dependencies. What should stay with teams? Internal component choices, local design optimizations, implementation detail within guardrails.
I once saw a three-week architecture review cycle delay a partner onboarding API long enough to miss a launch window. The irony was painful: governance designed to reduce risk created commercial risk directly.
The healthier pattern is standing architecture support embedded in delivery. Not architecture disappearing, but architecture being available when decisions are live.
How architects should work with Agile roles
This part is less about framework and more about behavior.
With product management, architects should help shape options before commitment. Product leaders do not need more lectures about standards. They need clarity on dependency risk, reuse possibilities, operational consequences, and where short-term scope choices create long-term friction.
With release train engineers or delivery leads, the relationship should focus on dependency visibility, sequencing, and issue escalation. Good architects make delivery planning more realistic.
With solution and system architects, the challenge is alignment without hierarchy games. In healthy environments, enterprise and domain architects set intent and guardrails; solution architects and teams drive design within those constraints.
Platform teams matter more than many enterprise architects admit. Cloud landing zones, Kafka platforms, IAM services, API gateways, observability tooling, secrets management, and CI/CD standards shape architecture outcomes every day. If platform teams are disconnected from ADM-driven decisions, the model collapses quickly. Sparx EA guide
And operations or SRE should be in the conversation earlier. Telecom still suffers from too much design divorced from operational reality. Resilience, alerting, tracing, rollback, supportability, and failure mode design are architecture concerns.
One telecom-specific pattern works especially well: joint planning between business, IT, and network architecture for customer-facing propositions. Not because cross-functional collaboration is fashionable, but because the proposition literally depends on all three.
Metrics that tell the truth
If you want to know whether ADM is helping Agile delivery or suffocating it, do not count standards published or architecture reviews completed. Those are vanity metrics.
Look at operational friction:
- reduction in cross-team dependency churn
- architecture decision lead time
- reuse of platform capabilities
- fewer production incidents caused by design inconsistency
- faster product launch for cross-domain offers
- lower order fallout and provisioning failure rates
Telecom-specific examples are even better:
- percentage of offers launched using a common product model
- time to onboard a new partner channel
- proportion of activation flows using standardized events
- reduction in manual exception handling across order and fulfillment
- customer support calls caused by activation visibility gaps
One caution though. Architecture effectiveness often shows up first in friction reduction, not revenue impact. That is fine. In practice, less friction is usually the earliest reliable signal that the architecture function is actually helping.
When TOGAF is too heavy, and when Agile is too shallow
There are cases where TOGAF-heavy behavior is harmful. Volatile market opportunities. Local product enhancements. Fast experimentation in digital channels. You do not need enterprise-grade ADM ceremony to test a new self-service flow or a small pricing variation.
But there are also areas where Agile-first behavior becomes dangerous: customer data fragmentation, network and service inventory decisions, resilience and compliance architecture, strategic platform replacement, identity architecture, cross-domain event contracts.
A practical rule I trust is this: the broader the blast radius, the more explicit the ADM discipline should be.
Not because discipline is automatically virtuous. Because broad blast radius makes mistakes expensive.
A practical 90-day playbook
If you want to introduce this approach, do not launch a grand architecture method transformation. That usually burns energy before it proves value.
Start with one value stream or ART where business urgency and structural complexity intersect.
Week 1–2
Map the current decision forums. Not the official ones. The real ones. Where are architecture decisions already being made informally? By whom? Which decisions are repeatedly escalated? Where do delivery teams get blocked?
Week 3–4
Select one initiative with visible cross-domain pain. A converged offer, partner onboarding, customer identity rationalization, order fallout reduction. Define a lightweight ADM-based cadence around it: vision, business pain points, domain decisions, transition architecture, dependency map, exception process.
Month 2
Create one transition architecture and one dependency map for that initiative. Introduce architecture decision records. Set a few guardrails. Establish a lightweight exception process. Pull in platform teams early, especially if cloud, Kafka, API gateway, IAM, or observability dependencies exist.
Month 3
Embed architects in planning and review cycles. Retire redundant document templates. Track two or three operational metrics. Keep the evidence visible. If decision lead time drops and delivery churn reduces, the model will gain credibility quickly.
What to resist: trying to standardize the whole enterprise architecture method before anyone has seen practical value. Sparx EA maturity assessment
In my experience, architecture credibility is rebuilt initiative by initiative, not by policy memo.
Closing argument
ADM still matters. I would argue it matters a great deal. But only if it moves at the speed of decisions.
That is the real test.
Used well, TOGAF gives enterprises a way to structure cross-domain thinking, transition choices, governance, and change. Used badly, it preserves ceremony and delays action. Agile has the same dual nature. Used well, it accelerates learning and delivery. Used badly, it fragments decision-making and hides systemic risk until production reminds everyone that the architecture still exists, whether they named it or not.
Telecom does not have the luxury of pretending architecture can disappear into team autonomy. The products, operations, and infrastructure are too intertwined. A converged offer is never just a feature. A partner API is never just an interface. A product catalog decision is never just a local model choice. The blast radius is real.
So the goal is not “Agile architecture.” It is not “modern TOGAF” either.
The goal is simpler, and harder: make better cross-domain decisions early enough that delivery teams can move faster with fewer expensive surprises.
If ADM helps you do that, keep it.
If your implementation does not, change the implementation — not the conclusion that architecture still matters.
Frequently Asked Questions
What is TOGAF used for?
TOGAF provides a structured approach to developing, governing, and managing enterprise architecture. Its ADM guides architects through phases from vision through business, information systems, and technology architecture to migration planning and governance.
What is the difference between TOGAF and ArchiMate?
TOGAF is a process framework defining how to develop and govern architecture. ArchiMate is a modelling language defining how to represent architecture. They work together: TOGAF provides the method, ArchiMate provides the notation.
Is TOGAF certification worth it?
Yes — TOGAF Foundation and Practitioner are widely recognised, especially in consulting, financial services, and government. Combined with ArchiMate and Sparx EA skills, it significantly strengthens an enterprise architect's profile.