⏱ 20 min read
I’ve seen more telecom architecture confusion caused by the wrong relationship line than by the wrong box.
That may sound exaggerated until you’ve been through one of those transformation programs where a diagram quietly hardens into assumption, assumption turns into planning, and planning turns into budget, ownership, and escalation paths. Then, six months later, everyone discovers the model has been telling a story nobody actually meant to tell.
One OSS transformation in particular still comes back to me. We had “Order Management,” “Billing,” and “Provisioning” drawn as though they were permanent constituent parts of a single application construct. Clean picture. Executive-friendly. Completely misleading.
The roadmap that followed assumed a shared lifecycle. Product leaders started speaking as if one team owned the whole stack. Impact analysis for change requests treated those elements like internal modules of one platform instead of separately governed systems with awkward interfaces, different release cadences, and, in one case, an outsourced operational boundary. It wasn’t just diagram sloppiness. It changed decisions.
That is the real issue with ArchiMate composition and collaboration. Not notation purity. Not metamodel trivia. ArchiMate training
Relationship choice changes how people interpret accountability, lifecycle, dependency, and scope of change. A weak model does not simply look untidy; it quietly misdirects investment and design choices.
So here is the practical thesis I use with teams:
Composition answers: what is structurally part of this thing?
Collaboration answers: what works together to perform behavior or deliver an outcome?
Everything else in this article hangs off that distinction.
And I’m going to keep this decision-oriented. There are already enough textbook definitions in circulation.
The first question is not “which ArchiMate relationship do I prefer?”
It’s this:
Am I modeling structure, or am I modeling joint behavior?
If you ask that early, half the confusion disappears.
If the element cannot sensibly exist as a structural part of the whole, composition is probably the wrong move. If the relationship only makes sense because multiple parties interact toward a shared result, collaboration is usually closer to the truth.
Telecom makes this harder than it should be.
You have long-lived platforms sitting next to temporary delivery arrangements. Capabilities like service activation, fault restoration, onboarding, and retention cut across multiple systems and multiple operating teams. Then add vendors, channel partners, wholesale relationships, MVNO dependencies, tower sharing, identity providers, cloud edge platforms, and the usual political ambiguity around “ownership.” Boundaries blur quickly.
So people hedge.
They use composition because the picture looks tidy. Or they use collaboration because it feels noncommittal. Both reactions are understandable. Neither is harmless.
A simple example helps. A Customer Onboarding Squad is usually a collaboration, not a composition. It exists because people and systems coordinate to achieve onboarding outcomes. By contrast, CRM platform modules are a composition concern if you are describing the internal structure of the platform—customer profile, interaction history, offer management, IAM integration, perhaps Kafka-based event publication components.
One warning, because I see this more often than most architects like to admit: naming tricks fool people. Something that sounds collective is not automatically a collaboration. Something drawn under a larger box is not automatically composition. TOGAF training
You still have to decide what kind of truth the model is trying to tell.
Composition in plain English: “part of,” but say it like you mean it
Composition is the architecture version of saying, “this thing is structurally part of that thing.”
Not “touches it.”
Not “depends on it.”
Not “talks to it over APIs.”
Part of it.
In ArchiMate terms, composition is a strong whole-part relationship. In practice, stakeholders read it as intrinsic, relatively stable, and more defining than looser grouping. That matters. The moment you use composition, people infer boundaries.
And honestly, they should.
When you compose elements into a whole, you are telling your audience several things at once:
- there is a meaningful structural boundary
- the whole can be understood by looking at its constituent parts
- responsibility can be decomposed
- impact often rolls upward
- replacement or change in one part may affect the integrity of the whole
That is why composition is so useful in enterprise architecture. It supports real decisions. free Sparx EA maturity assessment
In telecom, classic examples are everywhere:
- a BSS suite composed of customer management, product catalog, order management, billing components
- a network domain architecture composed of access, transport, core, and service control building blocks
- a digital channel application composed of mobile front end, API orchestration layer, session service, and IAM adapter
If I’m doing roadmap planning for a BSS modernization program, composition is often exactly what I need. If I want to show that the billing platform has a rating engine, invoicing module, payment mediation component, and dunning service as structural parts, composition carries that meaning well. It helps with lifecycle planning, ownership, and replacement analysis.
But there are traps.
Composition is not deployment. Just because something runs in the same Kubernetes cluster or cloud landing zone does not make it structurally part of the same architecture element.
Composition is not ownership hierarchy either. A team may own two separate applications that are not composed into one whole. Equally, one platform may contain parts owned by different product teams.
And no, composition is not “these boxes are close together.” I wish that didn’t need saying, but after enough review sessions, I can tell you it absolutely does.
I’ve seen diagrams where a Kafka event backbone, IAM platform, mobile app, and CRM were all nested inside one giant “Digital Experience Platform” box. The visual told a story of structural unity. The actual estate was a federation of products, reused services, and cross-domain dependencies. The resulting impact analysis was hopelessly optimistic.
That’s the danger with composition. Used well, it creates clarity. Used lazily, it manufactures certainty.
Collaboration is where many diagrams become fiction
Collaboration, in practice, is about two or more active structure elements working together. The emphasis is on cooperation to perform behavior, provide a service, or deliver some shared outcome.
That sounds straightforward. It isn’t.
Architects overuse collaboration for three reasons, in my experience.
First, it feels safer than making a hard structural claim. If you’re unsure whether something is “part of” something else, collaboration can seem like the softer option.
Second, teams use it as a substitute for “interacts with.” They know there is some kind of relationship, but they do not want to think through whether it is serving, flow, access, assignment, realization, or simply an interface connection.
Third, it gets abused as a way to show cross-functional delivery without doing the harder work of modeling behavior and responsibility.
Telecom is full of legitimate collaboration scenarios, though. Real ones.
- Order Capture team + Credit Check service + Fulfillment orchestration collaborating to activate a new broadband service
- Retail channel, partner dealer network, and identity verification provider collaborating during SIM registration
- NOC, field operations, and incident automation platform collaborating in major outage restoration
In those cases, the relationship is meaningful because joint action matters. Remove the cooperation and the outcome does not happen.
That is the key distinction: collaboration is not mere connectivity.
If your CRM sends data to Billing through Kafka topics, that does not automatically mean “CRM collaborates with Billing.” Often the more accurate story is flow, serving, access, or realization. Collaboration should usually connect to shared behavior—an interaction, a business process, a service outcome, an operational response pattern.
Here’s my smell test: if you remove the collaboration from the diagram and nothing meaningful is lost, it was probably decorative.
A surprising amount of collaboration in real-world repositories is decorative.
A decision matrix people might actually use
Abstract rules are fine until you’re under time pressure and trying to produce a view for a steering committee by 4 p.m. So here’s the practical version.
Even with this, judgment still matters. There are edge cases. There are politically charged cases too, and in practice those are often harder than the technical ones.
Sometimes a product lead resists composition because it sounds like surrendering autonomy. Sometimes a sourcing team dislikes collaboration because it exposes external dependency more clearly than they would like. An architect has to notice that. Relationship choices are rarely neutral in large organizations.
A real telecom scenario: fiber broadband order-to-activate
Let’s make this concrete.
Imagine a fiber broadband order-to-activate journey with the following elements:
- customer-facing mobile app
- CRM
- product catalog
- order management
- workforce scheduling
- provisioning
- ONT activation service
- field technician team
- partner civil works provider
Now ask two different modeling questions.
First intent: structural decomposition of the order management landscape
If I’m trying to explain the internal architecture of the order management landscape, composition may be exactly right for parts of the picture. For example, order management may be structurally related to orchestration services, order state management, decomposition logic, and event publication components. Product catalog may itself be composed of offer model, technical catalog, and pricing rules structures. A cloud-native order orchestration platform might include Kafka-based event handlers, compensation logic, and policy components.
That is a structural view. Good for roadmap planning, technology replacement, and ownership discussion. ArchiMate in TOGAF
Second intent: collaborative operating model for activation delivery
If instead I’m modeling how broadband activation actually happens operationally, collaboration becomes more useful. The mobile app, CRM, order management, provisioning, workforce scheduling, field technician team, and partner civil works provider are not all structural parts of one thing. They cooperate to deliver an outcome.
The civil works provider especially matters here. I’ve seen programs accidentally model partners as if they were part of the internal platform simply because they were involved in the same end-to-end journey. That creates a dangerous fiction.
It suggests tighter control than exists.
It understates resilience risk.
It confuses audit interpretations.
It leads operations teams to assume escalation rights or change authority that do not actually exist.
That’s not a subtle modeling error. In regulated environments, or anywhere customer outage credits and SLA penalties matter, it gets expensive quickly.
Here’s a simplified way to think about the two views:
That’s a composition-style decomposition if those are real structural parts.
Now the delivery view:
This second picture is not automatically a collaboration model yet, but it points you toward collaboration around the activation outcome rather than pretending all elements are one structural whole.
That distinction is the whole game.
Where composition is the right call in telecom
There are areas where composition is not just acceptable; it is the right semantic commitment.
Platform architecture is the obvious one. BSS and OSS decomposition benefits from strong whole-part modeling when you are examining modernization options, product boundaries, retirement plans, or technical debt concentration. A network management stack composed of fault, performance, configuration, and topology components is a useful statement if that reflects the architecture reality.
Application architecture too. Digital channels, service orchestration, mediation, inventory subsystems, observability platforms—these often need internal decomposition. If your cloud landing zone includes shared logging, IAM, secrets management, network segmentation, and CI/CD guardrails as platform building blocks, composition can support useful planning conversations.
Technology architecture as well. Edge domain architecture, private cloud platform components, observability platform parts, packet core building blocks—composition helps when structural understanding matters.
Business architecture is where people often become more hesitant, and not without reason. Decomposing a business actor, role grouping, or support structure can drift into organizational politics quickly. Still, if you are modeling enduring structure rather than temporary coordination, composition can be valid there too.
Why the hesitation?
Because composition feels like overcommitting. Product teams want looser language. Outsourcing and mergers make “part-of” politically sensitive. In telecom especially, there are many semi-detached assets: managed services, shared network operations, partner-run channels, hyperscaler-dependent platforms.
My advice is blunt: if the decision you’re supporting depends on replacement, ownership, structural integrity, or internal roadmap sequencing, composition earns its place.
If not, be careful.
The subtle traps with collaboration
Collaboration sounds modern. Cross-functional. Agile-friendly. Which is exactly why it gets abused.
One common mistake is using collaboration as shorthand for process flow. “These things are involved in the process, so they collaborate.” Maybe. Maybe not. A sequence of handoffs does not automatically imply collaboration in any useful modeling sense.
Another trap is confusing collaboration with interface exposure. An application exposes APIs to another application. Fine. That might be serving. It might be an interface relationship. It might involve access to data objects. It does not become a collaboration simply because there is network traffic.
And then there is the industry favorite: modeling every integration as collaboration.
I’ve lost count of how many times I’ve seen “CRM collaborates with Billing.” Usually the real relationship is that CRM uses a billing service, or billing publishes events that CRM consumes, or both systems participate in a broader process but do not form a meaningful collaboration object by themselves.
A few bad habits I see in telecom models:
- “Customer activation collaboration” drawn as a neat central bubble with no attached behavior
- partner ecosystems lumped into one collaboration object that says nothing useful
- dealer channel, KYC provider, SIM registration platform, and CRM all shown as one collaboration without any process, interaction, or service anchor
The correction pattern is usually simple:
- replace fake collaboration with flow or serving where appropriate
- anchor real collaboration to a business process, interaction, or service
- name collaborations by outcome, not merely by participants
That last point matters. “SIM Registration Collaboration” is better than “Retail + KYC + Dealer Collaboration,” because the former tells you why the grouping exists.
The mistakes section, because this is where people actually learn
Mistake 1: Treating composition like a container shape
This happens constantly. Someone draws a large box and places smaller boxes inside it. It looks organized, so everyone nods. But no semantic commitment has really been tested.
I’ve seen this in cloud migration diagrams where “Digital Platform” contains CRM, IAM, Kafka, API Gateway, analytics, and mobile backend. That nesting implied structural unity. The estate was actually a collection of products and shared services.
I’ve seen this enough times that I now ask, “Would you still say ‘part of’ out loud for each nested element?” If not, don’t use composition.
Mistake 2: Composing external organizations into your enterprise
Especially common in wholesale telecom, roaming, MVNO, tower-sharing, and managed service arrangements.
An external partner may be essential to service delivery. That does not make them structurally part of your enterprise architecture. If you compose them into your organizational structure or platform structure, you are overstating control and understating contractual boundaries. Sparx EA guide
I’ve sat in operational readiness reviews where that exact mistake later surfaced as confusion in incident escalation.
Mistake 3: Creating collaborations with no behavior
This is the collaboration equivalent of decorative wallpaper.
A collaboration should explain something. If it has no linked interaction, process, service, or coordinated outcome, then what work is it doing in the model? Usually none.
I’ve seen architecture repositories full of “collaboration” elements that were really just placeholders for uncertainty.
Mistake 4: Over-modeling temporary squads as enduring architecture
Agile delivery structures are not automatically target operating model elements.
A launch squad for eSIM onboarding, a war-room for 5G go-live, a tiger team for outage recovery—these may matter operationally, but that does not mean they belong as permanent composed organization structures.
This one is common because transformation programs confuse current mobilization with enduring design.
Mistake 5: Using composition to imply implementation dependency
Tight integration does not mean structural containment.
A provisioning engine may depend heavily on IAM, secrets management, observability tooling, or a Kafka event bus. That does not make those components structural parts of the provisioning application. Dependency is not composition.
I’ve seen roadmaps get distorted because shared platform services were treated as if they belonged inside every consuming application.
Mistake 6: Forgetting the audience
This is the quiet killer.
Executives often read collaboration as partnership. They read composition as ownership or internal accountability. Risk teams read them differently again. Operations teams infer control boundaries. Procurement hears sourcing implications.
So even if a relationship is technically arguable, you still need to think about how it will be interpreted.
That’s not dumbing it down. That’s architecture.
Why this matters downstream
People sometimes dismiss relationship semantics as diagram hygiene. I think that’s dead wrong.
The choice between composition and collaboration affects downstream architecture work in very practical ways.
Capability mapping, for one. If you model capability realization with structural claims where the reality is cross-unit collaboration, you distort maturity assessments and funding conversations.
Application rationalization too. Composed structures are natural candidates for consolidation, modernization, or replacement analysis. Collaborations are not. If you blur the two, rationalization recommendations get strange very quickly.
Transition architecture planning depends heavily on this distinction. Structural decomposition tells you what can be replaced, sequenced, or retired. Collaboration tells you where coordination, handoffs, and shared outcomes need attention during change.
Sourcing decisions are directly affected. So is resilience planning.
A telecom-specific example: if service activation is modeled as a composed internal structure rather than a collaboration across internal and external parties, resilience planning will underestimate external risk. Outage blame, escalation paths, and fallback planning will all be skewed. Contract boundaries become fuzzy. Regulatory interpretations around customer data handling can also get muddled if external identity verification or onboarding partners are visually absorbed into internal structure.
This is exactly why I’m opinionated about it: relationship semantics shape governance whether people admit it or not.
A practical sequence for busy enterprise architects
When time is short, I use a very basic sequence.
Step 1: State the decision the diagram must support.
If you cannot answer that, stop. The relationship choice will be random.
Step 2: Decide whether the audience needs structural truth or coordination truth.
Those are different things.
Step 3: Test permanence.
Is this relationship stable across time, or only relevant in a scenario, process, or operating moment?
Step 4: Test ownership and lifecycle boundaries.
Would the parts reasonably share structural accountability, or are they independently governed?
Step 5: Ask what would break if the relationship changed.
If the whole loses structural integrity, composition may fit. If only an operational outcome changes, collaboration may be better.
Step 6: Only then choose composition, collaboration, or something else.
A quick telecom walkthrough: launching eSIM in the prepaid channel.
What gets composed? Perhaps the digital channel platform, the identity and consent module, notification service, and prepaid order capture components—if you are showing the internal structure of that channel stack. What remains a collaboration? Retail operations, fraud team, CRM, KYC provider, and SIM lifecycle service coordinating to complete activation and compliance checks.
And one more thing, learned the hard way: stop modeling when precision no longer adds value. Not every review board needs a perfect semantic treatment of every edge. But the important edges—the ones that imply ownership, replacement, or external risk—deserve discipline.
Questions I ask myself when I’m unsure
Not a textbook comparison. Just the real internal checklist.
Is this thing inherently part of the whole, or just participating?
Would I expect the whole to be described through these parts?
Is this relationship stable across time, or scenario-specific?
Am I modeling architecture structure or operating coordination?
Would I show an external partner this way?
That last question is surprisingly useful. If the answer is “I would never present them as part of our internal structure in front of legal, procurement, or ops leadership,” then composition is probably a bad choice.
The summary is simple:
- composition is a structural claim
- collaboration is a coordination claim
And no, aggregation is not the rescue option for every uncertainty. Sometimes it is right, but often people reach for it because they want to avoid deciding. That usually means the modeling purpose is still unclear.
Mini case study: a 5G enterprise connectivity service
Consider a telco launching managed private 5G for industrial customers.
Elements involved:
- enterprise sales
- solution design
- RAN domain
- core network slice management
- service assurance
- field engineering
- cloud edge platform
- hyperscaler partner
Now there are two genuinely useful views.
One is a composition view of the service platform building blocks. Maybe the managed private 5G platform is composed of edge control, slice orchestration, policy management, observability, customer portal components, IAM federation, and assurance adapters. If that’s the structural reality, composition is valuable.
The second is a collaboration view of internal teams and partners delivering activation and assurance. Enterprise sales, solution design, field engineering, service assurance, network operations, and the hyperscaler partner collaborate to stand up and run the service.
If you mix these up, three bad things happen quickly:
- the hyperscaler partner appears structurally embedded in your platform
- your internal platform seems more operationally cohesive than it really is
- handoff and responsibility risks disappear from the model
A better ArchiMate diagram makes service design reviews easier. It sharpens sourcing discussions. It improves operational readiness because people can see both the platform decomposition and the delivery coordination model without confusing one for the other.
That is the point of architecture views, after all: not to be comprehensive, but to be useful.
Sometimes the right answer is “neither”
This is an important guardrail.
Not every relationship you’re tempted to draw should be composition or collaboration.
Sometimes serving is the real answer. A mediation service serves billing; it does not collaborate with billing just because it provides normalized event handling.
Sometimes assignment is right. A field technician is assigned to a role or process responsibility, not composed into the process.
Sometimes flow is the truth. An event stream from network probe to assurance platform is flow, not collaboration.
Sometimes access matters more. A customer profile store accessed by CRM and order capture says something different from collaboration.
Sometimes realization is what you need, especially when linking services to application or technology elements.
Forcing every relation into composition or collaboration is usually a sign that the model goal is fuzzy.
That fuzziness spreads.
Final thought: relationships are commitments, not decoration
If you remember nothing else, remember this:
Use composition when you are willing to say, plainly, “this is part of that.”
Use collaboration when you mean, “these parties work together for this outcome.”
In telecom, with its ecosystem sprawl and operational interdependence, the more dangerous mistake is usually overstating structural unity. We like clean boxes. Reality is messier—partners, platforms, managed services, domain boundaries, event-driven integrations, IAM dependencies, cloud control planes, external field operations. If you flatten that into one structural whole, the model becomes comforting and false.
My advice to architects is to take a red pen to old diagrams.
Ask:
- which compositions are really just interactions?
- which collaborations have no meaningful behavior?
- where have we implied ownership or control we do not actually have?
- where have Kafka, API gateways, IAM, or shared cloud services been visually absorbed into places they do not belong?
This is one of those quiet habits that separates useful enterprise architecture from pretty diagrams.
And in my experience, the quiet habits matter most.
Frequently Asked Questions
What is enterprise architecture?
Enterprise architecture aligns strategy, business processes, applications, and technology. Using frameworks like TOGAF and languages like ArchiMate, it provides a structured view of how the enterprise operates and must change.
How does ArchiMate support enterprise architecture?
ArchiMate connects strategy, business operations, applications, and technology in one coherent model. It enables traceability from strategic goals through capabilities and application services to technology infrastructure.
What tools support enterprise architecture modeling?
The main tools are Sparx Enterprise Architect (ArchiMate, UML, BPMN, SysML), Archi (free, ArchiMate-only), and BiZZdesign. Sparx EA is the most feature-rich, supporting concurrent repositories, automation, and Jira integration.