Key Considerations for Drawing Overall and Application Architecture Diagrams

When designing software or solution diagrams, overall and application architecture drawings must address several critical aspects.

Overall Architecture Diagram – Common in smart‑city or enterprise IT solutions, these diagrams depict the entire industry or company’s IT landscape, typically showing major systems such as CRM or ERP as large blocks.

The core of an overall architecture is its layered approach: an IaaS infrastructure layer at the bottom, a PaaS platform services layer in the middle, and an application layer on top. In modern micro‑service environments, the application layer may be split into a middle‑office (or “mid‑platform”) layer and a portal layer.

The PaaS layer includes technology platforms, data platforms, integration platforms, and middleware pools, as well as traditional 4A and workflow platforms. Specific components should be planned according 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 (e.g., sales, R&D, manufacturing, customer service, finance) or by value chain, and the diagram often includes technical standards and security governance.

SOA‑Based Application Layer – When a service layer is included, key business and technical services are shown, feeding into a shared service platform that applications consume. In micro‑service architectures, the middle‑office provides API services that upper‑level applications assemble.

Although a high‑level overall diagram may omit an explicit service layer, a detailed application architecture should illustrate services, shared platforms, and the resulting applications.

Single Application Architecture Diagram – Even a single application may consist of multiple subsystems (e.g., finance sharing includes expense, budgeting, cash, e‑voucher, archive). These are layered with a foundational platform layer (4A, workflow engine, technical capabilities) beneath the business subsystems, topped by a portal for integration.

The same layering concept applies: technology platform → middle‑office (service) layer → applications → portal.

Single Business System Diagram – Decide whether to depict an application architecture (focus on business modules and functions) or a technical architecture (focus on data, logic, presentation layers or SOA components). Application diagrams emphasize business domains, while technical diagrams highlight component stacks.

Key Takeaways

Layering is the fundamental guiding principle (platform + application, or platform + service + application).

Vertical domain classification (e.g., technical platform, data platform) is the second critical point.

Distinguish between application architecture and technical architecture, as their concerns differ.

Separate business systems from BI/analytics layers; a single diagram rarely captures both clearly.

Architecture diagrams are static; avoid embedding process flows or interaction details.