What Is Architecture Really? Business, Application, and Data Views

Defining Architecture

In software engineering, the term architecture is often debated, with different books and authors offering varying definitions. The article emphasizes that a clear, shared definition is essential for effective communication. Architecture is defined as the combination of elements , structure , and connections that together form a system’s skeleton.

Core Concepts

System : A group of related components that work together to achieve capabilities beyond any single component. Key attributes include association (components must be related), rules (governed interactions), and capability (emergent abilities).

Subsystem : A system that is part of a larger system, sharing the same core concepts.

Module : A logical decomposition of a system for the purpose of separating concerns. Modules can range from entire subsystems to individual functions.

Component : A physical unit such as a service, database, network element, or container. Components are reusable and interchangeable.

Framework vs. Architecture

A framework provides a set of conventions and basic functionalities (e.g., MVC, Spring MVC) that developers can extend. An architecture describes the overall structure and relationships among components. The article stresses that "framework is a specification, architecture is the structure."

Classification (TOGAF 9)

TOGAF classifies architecture into four types:

Business Architecture : Business strategy, governance, organization, and core processes.

Data Architecture : Logical and physical data assets and management resources.

Application Architecture : Deployment of individual applications and their interactions.

Technology Architecture : Underlying hardware, middleware, networks, and standards required to support the other layers.

The article further refines these into six practical categories: business, application, data, technical, code, and deployment architectures.

Architecture Evolution

Monolithic Architecture : Suitable for simple, single‑team projects. Typical three‑tier layout (frontend, business logic, database). Non‑functional improvements include caching, clustering, read/write separation, CDN, and distributed storage. However, as codebase grows, monoliths become hard to maintain, suffer from high coupling, and impede scalability.

Distributed (Service‑Oriented) Architecture : Decomposes the system into independent services, reducing coupling, clarifying responsibilities, and improving scalability. Benefits include easier deployment, better fault isolation, and reusable services. Drawbacks involve increased operational complexity, network latency, and the need for robust monitoring.

Microservice Architecture : Extends distributed architecture with lightweight, independently deployable services, feature toggles, and rapid iteration. Advantages are faster development, independent scaling, and technology heterogeneity. Challenges include higher operational overhead, distributed transaction management, and interface versioning.

15 Universal Architecture Design Principles

Redundancy : Ensure at least one backup instance for critical services.

Backward Compatibility : Design for versioned roll‑backs.

Feature Toggles : Ability to disable any feature via configuration (e.g., Apollo).

Monitoring‑by‑Design : Embed observability from the start to detect availability issues, support self‑diagnosis, and understand system interactions.

Use Mature Technology : Adopt proven, low‑risk technologies for core components; experiment with new tech only in low‑impact areas.

Fault Isolation : Apply the "no‑share" and "no‑cross‑zone" principles to prevent cascading failures.

Horizontal Scaling : Design for X‑axis (add servers), Y‑axis (shard databases), and Z‑axis (split functionality).

Commodity Hardware : Prefer inexpensive, standardized hardware to achieve cost‑effective scaling.

Small Build : Keep build size low to ensure investment yields value.

Small Release : Reduce failure risk by limiting change scope per deployment.

Fast Iteration : Enable rapid market feedback loops and improve time‑to‑market.

Stateless Design : Avoid stateful services where possible to simplify scaling and load balancing.

Future‑Proofing : Plan for "Now", "Now+1", and "Now+2" versions to guide evolution.

Automation : Replace manual steps with automated pipelines to reduce human error.

Proactive Testing : Incorporate testing early to catch regressions before they reach production.

Common Architectural Pitfalls

Over‑engineering without concrete business value.

Missing critical non‑functional requirements (e.g., performance, reliability).

Designing for an imagined future instead of current needs.

Making premature key decisions.

Being a mere conduit for customer requests without technical scrutiny.

Lack of foresight in system testing and measurability.

Attempting to achieve a perfect design before starting development.

Misconceptions Highlighted

The article lists six common misconceptions: believing only architects should care about architecture, thinking the architect’s job ends after the blueprint, assuming perfect design is required before coding, over‑designing for an uncertain future, blindly copying large‑company solutions, and chasing technology for its own sake.

Conclusion

Effective architecture balances systematic thinking, practical constraints, and incremental evolution. By adhering to the presented principles and avoiding the outlined pitfalls, teams can build systems that are maintainable, scalable, and aligned with business goals.