How to Design Effective Enterprise Architecture Diagrams: Key Layers and Best Practices

Overall Architecture Diagram

When developing software or solution applications, you inevitably need to draw an overall or application architecture diagram. Such diagrams are common in smart‑city solutions and enterprise‑wide IT architecture projects, representing the whole industry or organization rather than a single business system. Large systems like CRM or ERP appear as single blocks.

The core of an overall architecture is its layered structure: the bottom IaaS infrastructure layer, the middle PaaS platform services layer, and the top application layer. In modern micro‑service architectures, the application layer can be further split into a middle‑platform layer and a portal layer.

The PaaS layer includes technology platforms, data platforms, and integration platforms. The technology platform itself comprises application hosting platforms, middleware pools, traditional 4A and workflow platforms, and various technical services. The exact composition should be tailored to project needs.

For IoT projects, additional perception and network layers sit beneath the resource layer.

In the application layer, business systems can be grouped by domain—such as sales, product development, manufacturing, customer service, finance—based on value chains or other criteria.

Overall diagrams also typically show technical standards and security governance frameworks on the sides.

Because it is difficult to separate business applications from BI analysis lines, it is recommended to place a generic "business decision‑analysis" layer at the top of the application tier.

SOA‑Based Expansion of the Application Layer

If a service layer is included, key business and technical services should be depicted, feeding into a service‑exposure or sharing platform. Upper‑level applications then assemble or orchestrate functionality from this service layer, following SOA principles.

In micro‑service contexts, middle‑platform centers expose API services that downstream applications consume.

When drawing a pure overall architecture, a separate service layer is often omitted; however, for detailed application architecture, the service layer, shared services platform, and business services are explicitly shown.

Single Application Architecture Diagram

A single application (e.g., a financial shared service) typically consists of multiple subsystems such as expense reporting, budgeting, cash management, e‑vouchers, and archives. The diagram should still follow a layered approach: a foundational platform layer (including 4A, workflow engine, technical platform capabilities) beneath the business subsystems, with a portal layer on top for unified integration.

Each subsystem can be broken down to highlight its key business modules, while the overall structure follows the platform → middle‑platform → services → applications → portal hierarchy.

Single Business System Architecture Diagram

When diagramming a single business system, decide whether to illustrate an application architecture (focusing on business modules and functions) or a technical architecture (showing data, logic, and presentation layers, or SOA‑based component relationships).

Application architecture emphasizes business modules, data layers, functional layers, and decision‑analysis layers, possibly including key external interfaces. Technical architecture follows standard multi‑tier patterns, highlighting data, logic, and presentation components without detailing business functions.

Key Takeaways for Drawing Architecture Diagrams

Layering is the fundamental guiding principle—either platform + application or platform + service + application.

Vertical domain classification (e.g., separating technology platform, data platform) is the second critical point to avoid a chaotic layout.

Distinguish clearly between application architecture and technical architecture, as they address different concerns.

Within application architecture, differentiate business systems from BI applications; a single diagram rarely captures both clearly.

Architecture diagrams are static representations, so avoid depicting processes or interactions.