What Is Architecture? Seeing Beyond the Components
From buildings to enterprise systems, discover the common principles that connect the different disciplines of architecture.
Several years ago, while attending a TOGAF training class, an instructor shared an example of architecture that stayed rooted in my mind. It changed how I visualized architecture.
Pointing to the trainees in the room, the instructor traced their geographical location, starting with the country, state, and county, down to the place, building, and room in which we were sitting. Along this trace, different elements were connected to one another. That, to me, was the essence of the example.
The word architecture sounds wonderful, with its familiar association with buildings that house people or host activities. Yet, by itself, the word does not intuitively convey what it encompasses. Consider another term, data model. The two words together offer an immediate clue to its purpose: a model of data. Architecture, on the other hand, needs a little more thought to grasp in its broader sense.
Perhaps that is why it helps to turn to established definitions of architecture.
The ISO/IEC/IEEE 42010:2022 standard addresses architecture descriptions across software, systems, enterprises, and other entities. It considers an entity’s fundamental elements, the relationships among them and with their environment, their structure and behavior, and the principles governing their design and evolution. The TOGAF Standard also provides a framework for thinking about architecture in terms of components, their interrelationships, and the principles guiding their design and evolution.
What stands out across these perspectives is that architecture is about more than the individual things that make up a whole. It concerns how those things are organized, how they relate to one another, and the principles that shape the whole over time.
In a simplified, conceptual diagram, we can represent this as boxes and lines. The boxes represent the things that matter; the lines represent the relationships and interactions between them. Annotations help us understand what the boxes represent and what the connecting lines signify.
This is a simple way to visualize architecture. But is it enough to understand what architecture really entails? To explore that, let us return to the realm from which the word draws its most familiar association: buildings.
Architecture: The Whole Is More Than Its Appearance
When we look at a building, its architecture is often perceived through its visible form: the shape, the façade, the materials, and the visual appeal. But these are only the most apparent aspects of architecture. What lies beneath and within the visible structure is equally important, and the two are closely related.
A building must accommodate its intended use, the movement of people, structural stability, electrical systems, plumbing, ventilation, fire protection, and safe access and exit paths. These are not independent considerations that can simply be added after the building’s appearance has been decided. They influence one another. The placement of walls and columns affects usable space; the arrangement of rooms influences movement; and the choice of materials and structural design affects both appearance and function.
Architecture, therefore, concerns the whole building and the relationships among its parts. The visible form is one expression of that whole, shaped by functional needs, structural considerations, practical constraints, and the purpose the building is intended to serve.
Consider how this thinking extends beyond the practical requirements of a building. Architecture can also express ideas and beliefs through the relationships deliberately embodied in its design. Two remarkable examples, from different parts of the world, illustrate this in their own ways.
Chidambaram Nataraja Temple: Architecture and Cosmic Meaning
Located in Chidambaram, Tamil Nadu, India, the Nataraja Temple is an important Hindu temple associated with Shiva in his form as Nataraja, the Lord of the Dance. The temple’s significance extends beyond its physical structure to its religious and philosophical associations, including the relationship between the human being, the cosmos, and the divine.
One traditional interpretation concerns the golden roof over the Kanaka Sabha, or Golden Hall. Temple-related accounts describe 21,600 gold plates, associated with the number of breaths a person is traditionally understood to take in a day, and 72,000 nails, associated with the subtle channels known as nadis in yogic traditions. These numbers and their meanings are traditional interpretations, not independently verified scientific claims.
These associations are more than descriptions of physical components. Within the tradition, they express a relationship between the human being and a larger cosmic order, giving architectural details a meaning beyond their material function.
Viewed through the lens of architecture, the significance lies in how the physical structure and its symbolic associations come together to serve a larger religious purpose. The roof is not merely a covering; within this interpretation, its details participate in the meaning of the sacred space itself.
Sagrada Família: Architecture as an Expression of Faith
On another continent, in Barcelona, Spain, the Basilica of the Sagrada Família offers a different but equally fascinating illustration of architecture carrying meaning through its overall composition.
Designed by Antoni Gaudí, the basilica is renowned for its distinctive forms, intricate detailing, and integration of structural and religious ideas. Its tower arrangement is particularly revealing. The design comprises 18 towers dedicated to Jesus Christ, the Virgin Mary, the four Evangelists, and the twelve apostles.
The hierarchy is intentional: the tower dedicated to Jesus Christ occupies the highest position, while the other towers reflect their respective places in the religious narrative. The arrangement makes the building’s religious symbolism part of its physical form rather than leaving it solely to paintings, sculptures, or written explanations.
The interior offers another perspective. Columns branch as they rise, evoking the forms of trees and supporting the vaults above. This is not simply a decorative choice; the geometry is integral to how the interior space is structured and experienced.
Here, too, the architecture brings together several dimensions: structure, spatial experience, visual expression, and religious meaning. The relationships among the elements matter as much as the individual elements themselves.
These two structures differ greatly in their histories, traditions, and architectural expressions. Yet both offer a useful lesson: architecture can encompass practical requirements, physical form, and deeper meaning within a coherent whole. To understand it, we must look beyond what is immediately visible and consider why the elements are arranged as they are, how they relate to one another, and what the resulting whole is intended to express.
Architecture: Making the Most of Constraints
Continuing with building architecture, I recall an architect explaining that the art and craft of architecture become particularly evident when faced with constraints, such as limited space. The challenge is not merely to fit everything within the available space, but to make the space serve its intended purpose effectively. An architect may create a sense of openness and spaciousness even when the actual dimensions are constrained. This calls for thoughtful choices about the arrangement of spaces, the placement of elements, and how people will experience and use the building.
The same principle applies in the information technology realm. Architecture must accommodate constraints involving resources, cost, schedule, capacity, and the capabilities of existing systems, among others. These constraints influence the choices available to the architect. A decision that optimizes one aspect may have consequences for another. The challenge is to make choices that collectively serve the intended purpose, rather than optimize individual elements in isolation.
Ultimately, the objective is to deliver business value. Architectural decisions influence how solutions are designed, developed, integrated, operated, and evolved over time.
The value of architecture lies not in the diagrams it produces, but in how effectively it helps translate business objectives into solutions that work within the prevailing constraints.
This brings us to the different types of architecture encountered in IT. Each addresses a particular set of concerns, operating at a different level of scope or focusing on a different aspect of the overall solution. Although their responsibilities may overlap, they share the underlying idea of organizing elements and their relationships to serve a purpose.
The Different Perspectives of IT Architecture
Enterprise Architecture
Enterprise architecture takes the broadest organizational perspective. It establishes the principles, policies, standards, and architectural direction that help align business capabilities, processes, information, applications, and technology with enterprise objectives. It also provides a basis for guiding investment decisions and managing the evolution of enterprise assets over time.
A Note on the Diagrams
The diagrams in this article deliberately use a boxes-and-lines approach. This is a conscious choice to highlight the central idea that architecture involves identifying meaningful elements, understanding their relationships, and organizing them to serve a purpose.
In practice, architects use different notations, modeling languages, conventions, and levels of detail, shaped by the discipline, the audience, the purpose of the model, and the organization’s established practices. The diagrams presented here are illustrative representations created to explain the underlying concepts, not prescriptive examples of architectural notation or modeling standards. They should not be taken as recommendations for how architecture diagrams must be drawn or as substitutes for the conventions appropriate to a particular discipline or organization.
Consider a retail bank seeking to improve its digital customer experience while maintaining the reliability of its existing operations. The challenge is not confined to an individual application or technology platform. It spans business capabilities, customer journeys, operational processes, information, applications, and the technology that supports them.
The diagram below illustrates an enterprise-wide view of these elements and the relationships between them. Its purpose is to show how business objectives connect to capabilities and how those capabilities are supported by processes, information, applications, and technology.
Notice that the diagram is not simply a collection of organizational components. The relationships help explain how different parts of the enterprise contribute to a common business outcome. A change in one area may have implications for several others. This broader perspective is what distinguishes enterprise architecture from the architecture of an individual system.
Get Seshu Thota’s stories in your inbox
Join Medium for free to get updates from this writer.
Portfolio Architecture
Portfolio architecture focuses on a collection of related assets, typically associated with a business domain or line of business. It considers how those assets should evolve as business priorities change, including the creation of new capabilities, modernization of existing assets, consolidation of overlapping functionality, and eventual retirement. These decisions are made within the broader direction and constraints established by enterprise architecture.
Solution Architecture
Solution architecture addresses a particular business problem or need by establishing how the proposed solution’s components fit together. It considers the relevant applications, data, integrations, technologies, and other elements required to meet the intended objectives. A solution may span several existing systems, introduce new components, or combine both.
System Architecture
System architecture, in contrast, focuses on the structure and behavior of a particular system, including its constituent elements, interfaces, interactions, and how they collectively satisfy the system’s requirements. A solution involving several systems may have an overarching solution architecture, while each affected system has its own system architecture.
The two perspectives are related but differ in scope: solution architecture coordinates the elements needed to achieve a business outcome, while system architecture addresses the design of the system as a whole.
Now consider a more focused problem within the same retail bank: processing a customer payment. Unlike the enterprise-wide view, system architecture concentrates on the structure and behavior of a particular system, including its components, interfaces, dependencies, and interactions with external systems.
The following diagram illustrates a payment-processing system, showing how requests move through the relevant components, how external services participate, and how the system interacts with the bank’s ledger and payment infrastructure.
The value of this view lies in making responsibilities and interactions visible. Individual components may appear straightforward in isolation, but the overall behavior depends on how they collaborate, exchange information, and respond to one another. The architecture must account for these interactions, not merely identify the components involved.
Information Architecture
Information architecture focuses on the meaning, organization, flow, and use of information across the business. It considers where information originates, how it is accessed and transformed, where it is consumed, and how its integrity, consistency, and trustworthiness are maintained. Information lineage — understanding where information comes from and how it changes along the way — is important to establishing that trust.
A logical data model can be a foundational artifact in this space: it defines business-relevant entities, their attributes, and the relationships among them, independently of the specific technology used to implement them.
A retail bank handles information about customers, accounts, products, transactions, and many other business concepts. That information is created and maintained across different systems, yet it must retain consistent meaning as it moves between business processes, applications, analytical platforms, and reporting functions.
The diagram below illustrates an information architecture perspective. It emphasizes business concepts, authoritative sources, information flows, transformations, consumers, and the relationships that support consistent interpretation and use of information.
The important point is that information architecture is concerned with more than where data is stored. It considers what information means, how concepts relate to one another, where information originates, how it changes as it moves, and how it can be trusted and used. These considerations provide a foundation for the data structures and technologies used to implement and manage that information.
Data Architecture
Data architecture brings the implementation perspective into focus, addressing how data is structured, stored, managed, integrated, and made available through data platforms and services. A physical data model describes how logical structures are realized in a particular technology, such as database tables, columns, keys, indexes, and other implementation-specific details. Data architecture extends beyond the physical model to encompass the platforms, flows, integration mechanisms, and capabilities needed to support the data lifecycle.
The two disciplines are closely related. The logical model helps establish what information needs to be represented and how its concepts relate; the physical model describes how those structures are implemented. Together, they help preserve alignment between the meaning of information and the technology that manages it. The precise boundary between information architecture and data architecture varies across organizations and frameworks, but the distinction in emphasis remains useful.
Information Security Architecture
Information security architecture considers how security requirements and controls are incorporated into the architecture of an enterprise, solution, or system. It addresses concerns such as identity and access, protection of information, threat exposure, and compliance with applicable policies and standards. Security is not an isolated layer to be added at the end; it influences architectural decisions throughout the lifecycle.
Security cannot be treated as an isolated component added after a system has been designed. In a retail bank, customers, employees, applications, external partners, and operational teams interact with sensitive information and business services under different levels of trust.
The following diagram illustrates an information security architecture perspective. It brings together identities, access policies, trust boundaries, enforcement points, protected assets, monitoring, and audit capabilities to show how security considerations extend across the environment.
The relationships are central to understanding the security architecture. An identity must be authenticated, access must be authorized, policies must be enforced at appropriate points, and relevant activity must be monitored and recorded. These controls work together across system boundaries and data flows. Security architecture therefore cuts across the other architectural perspectives rather than occupying a separate, self-contained layer.
There are other architectural disciplines, including technology infrastructure architecture, network architecture, and deployment architecture. Each addresses its own concerns, yet none operates entirely in isolation. The decisions made within one discipline can influence the others, and the resulting architecture must work as a coherent whole.
Looking across these disciplines, we can see that the elements being organized may be very different, and the scope of architecture may range from an individual system to an entire enterprise. Yet, the underlying thinking remains common: understanding the elements that matter, how they relate to one another, and how they must be organized to serve a purpose within given constraints.
Enterprise architecture, for example, considers the broader organization and its capabilities, while system architecture focuses on the components and interactions within a particular system. Information architecture concerns the meaning and use of information, while data architecture addresses how data is structured, managed, and made available. Each discipline brings a distinct perspective, but none can be understood entirely in isolation from the relationships that influence the whole.
The familiar boxes and lines are one way to make these relationships visible. Their real value lies not in the diagram itself, but in helping us understand the structure, dependencies, interactions, and choices that shape the outcome.
Seeing Architecture Everywhere
This way of thinking is not limited to buildings or the information technology world. We can recognize it in other industries as well, including power generation and process industries.
Consider the layout of equipment, packages, and products across a facility. Their placement is influenced by how they connect, how materials or energy flow between them, how people access and maintain them, and the operational requirements they must satisfy. The layout is not simply a collection of objects placed on a site; it reflects relationships and decisions that shape how the facility functions as a whole.
The same perspective applies to something as sophisticated as chip design, where numerous components and interconnections must work together within constraints involving space, power, performance, and heat. The individual components matter, but understanding how they are organized and interact is essential to understanding the design as a whole.
Across these different realms, the elements change, the constraints differ, and the purposes vary. Yet the underlying way of thinking remains recognizable: look beyond the individual components to understand their organization, their relationships, and the purpose they collectively serve.
The next time you encounter a building, an enterprise, an IT system, an industrial facility, or even a chip, try looking for the architecture behind it. Ask yourself what the important elements are, how they relate to one another, and what larger purpose those relationships serve.
Perhaps the seemingly abstract concept of architecture becomes a little less mysterious when we learn to see the bigger picture — and begin with the simple language of boxes and lines.
References
- ISO/IEC/IEEE 42010:2022 — supports the discussion of architecture descriptions and the distinction between an entity’s architecture and its description.
- Sagrada Família — The Temple’s Towers — supports the explanation of the 18 towers and their religious significance.
- Chidambaram Nataraja Temple — Cuddalore District — documents the traditional account of the golden plates and nails and their symbolic associations. Present these as temple-related traditional interpretations, not independently verified scientific facts.
