⏱ 7 min read
Recommended Reading
Executive summary
Platform architectures are governed products. ArchiMate can model platform capabilities and services and relate them to consuming domains and business capabilities, while capability maps support executive-friendly views that can be heatmapped for investment. ArchiMate training
- Capability modeling: platform capabilities and services
- Consumption mapping: domains and value streams
- Governance: guardrails, exceptions, roadmaps
- ArchiMate framing.
- Capability map viewpoint.
The three-pillar platform model
Platform architecture organizes shared capabilities that domain teams consume to build and run their applications. ArchiMate models this effectively by separating platform services (what the platform provides), domain applications (who consumes the platform), and developer experience (how teams interact with the platform). ArchiMate tutorial for enterprise architects
Platform services are modeled as Technology Services or Application Services depending on their nature. Identity and access management (IAM), messaging infrastructure (Kafka, MQ), storage services (object storage, databases), compute platforms (Kubernetes, serverless), and observability (metrics, logging, tracing) are all platform services. Tag each with Service_Type (IaaS / PaaS / Shared Service), SLA_Tier, Cost_Model (per-request / per-resource / flat), and Owner_Team.
Domain applications consume platform services via Serving relationships. Each domain team's Application Components are assigned to Technology Nodes provided by the platform. The ArchiMate model shows exactly which domain applications depend on which platform services — when the platform team plans a Kubernetes upgrade, the model reveals every application that will be affected.
Developer experience is the set of tools and processes through which domain teams interact with the platform. Self-service portals for resource provisioning, CI/CD pipelines for deployment, templates and scaffolding for new service creation, and documentation hubs for platform capabilities. Model these as Application Services that serve the "Developer" Business Role.
Platform evolution roadmap
Model the platform roadmap using ArchiMate Migration views. Each Plateau represents a stable platform state (e.g., "Platform v2: Kubernetes 1.29, Kafka 3.7, PostgreSQL 16"). Gaps represent the upgrades and migrations needed. Work Packages represent the platform team's projects. This gives domain teams visibility into upcoming platform changes and preparation time for compatibility. ArchiMate layers explained
Platform team topology in ArchiMate
Platform architectures follow the Team Topologies model: a platform team provides shared capabilities, and stream-aligned teams build domain-specific services on top of the platform. ArchiMate models this division clearly by mapping team responsibilities to architecture elements. ArchiMate relationship types
Platform team elements: Model shared services (IAM, messaging, storage, compute, observability) as Technology Services or Application Services at the platform boundary. Each service has a well-defined interface — the API that stream-aligned teams consume. Tag each platform service with Service_Type (IaaS / PaaS / Shared Service), SLA (availability, latency, throughput), Cost_Model (per-request, per-resource, included), and Deprecation_Date (if applicable). The platform team owns these elements and is responsible for their lifecycle.
Stream-aligned team elements: Model domain services as Application Components that consume platform services via Serving relationships. Each domain team owns its Application Components, Data Objects, and API contracts. The ArchiMate model makes the dependency direction explicit: domain services depend on platform services (downward dependency), but platform services never depend on domain services (no upward dependency). If an upward dependency appears in the model, it signals a platform abstraction leak that must be corrected.
Platform-as-product mindset: Model the developer experience layer as Application Services serving the "Developer" Business Role: self-service portal, CI/CD pipeline templates, infrastructure-as-code modules, and documentation. These are first-class architecture elements with the same governance as production services. A broken developer portal is as impactful as a broken production service — it blocks every team that depends on it.
Modeling platform evolution without breaking consumers
Platform changes ripple across every team that consumes platform services. ArchiMate Migration views show platform evolution as a sequence of Plateaus, each representing a stable platform state. When the platform team plans to upgrade Kubernetes from 1.28 to 1.30, the migration view shows: which platform services are affected, which domain applications depend on those services, and what compatibility testing each team must complete before the upgrade. ArchiMate modeling best practices
Tag each platform service with Current_Version and Target_Version. Build a "Platform Upgrade Impact" view that highlights all consuming Application Components. Send this view to stream-aligned teams 8 weeks before the upgrade, giving them time to test compatibility. This turns platform upgrades from surprise disruptions into planned, coordinated changes — the kind of proactive governance that ArchiMate enables at its best.
Platform capability assessment
Not every platform service needs the same maturity. Conduct a capability assessment to prioritize platform investment.
Model each platform capability as a Business Function (the logical capability) realized by Technology Services (the implementation). Tag each with Maturity (Initial / Managed / Defined / Optimized), Consumer_Count (how many teams use it), Reliability (uptime SLA achieved), and Developer_Satisfaction (survey score).
Build a Platform Capability Heatmap view: capabilities with high consumer count and low maturity are top priorities for investment. Capabilities with low consumer count and high maturity may be over-invested. The heatmap drives the platform team's quarterly planning: invest where demand is high and quality is low, and consider deprecating capabilities that nobody uses.
Model the platform's build-vs-buy decisions as Architecture Decision Records in the repository. For each platform capability, document: build internally (full control, high cost), adopt open source (moderate control, moderate cost), or use managed service (low control, variable cost). These decisions are revisited annually as the market evolves and the team's capabilities change.
Inner source and platform contribution models
Mature platform organizations adopt an inner source model where stream-aligned teams contribute back to the platform. Model the contribution flow in ArchiMate: a stream-aligned team's Application Component has a Realization relationship to a platform Technology Service, indicating that the team contributed code or configuration to the platform capability. Tag contributions with Contributor_Team, Contribution_Type (feature / bugfix / documentation), and Review_Status. This makes platform contributions visible to leadership and incentivizes teams to improve shared capabilities rather than building workarounds.
The platform team acts as the maintainer — they review, merge, and release contributions. The architecture board reviews significant platform changes for cross-team impact. This model scales better than a centralized platform team that builds everything: stream-aligned teams have the domain knowledge to build features they need, and the platform team provides quality control and architectural coherence.
If you'd like hands-on training tailored to your team (Sparx Enterprise Architect, ArchiMate, TOGAF, BPMN, SysML, Apache Kafka, or the Archi tool), you can reach us via our contact page.
Frequently Asked Questions
What is enterprise architecture?
Enterprise architecture is a discipline that aligns an organisation's strategy, business operations, information systems, and technology infrastructure. It provides a structured framework for understanding how an enterprise works today, where it needs to go, and how to manage the transition.
How is ArchiMate used in enterprise architecture practice?
ArchiMate is used as the standard modeling language in enterprise architecture practice. It enables architects to create consistent, layered models covering business capabilities, application services, data flows, and technology infrastructure — all traceable from strategic goals to implementation.
What tools are used for enterprise architecture modeling?
Common enterprise architecture modeling tools include Sparx Enterprise Architect (Sparx EA), Archi, BiZZdesign Enterprise Studio, LeanIX, and Orbus iServer. Sparx EA is widely used for its ArchiMate, UML, BPMN and SysML support combined with powerful automation and scripting capabilities.