--- title: "01 — What Software Architecture Actually Is" uid: what-is-architecture tags: ["software-architecture", "enterprise", "roadmap:software-architect", "responsibilities", "fundamentals"] excerpt: "Architecture is the set of decisions in a system that are expensive to change later — one job: make the hard-to-reverse decisions deliberately, not by accident." date: 2026-08-13T03:27:43+0000 source: https://www.aveshina.my.id/en/blog/what-is-architecture --- "Architecture" was a term I waved at whenever a system felt "big," and it explained nothing. Writing it down forced a single sentence to the front: **architecture is the set of decisions in a system that are expensive to change later** [1]. Everything else — patterns, diagrams, frameworks — is downstream of that. Once I treated architecture as "the costly-to-reverse layer," the rest of the roadmap stopped feeling like a grab bag and started feeling like a discipline with one job: make the hard-to-change decisions deliberately, not by accident. The framing that landed is a separation between _what_ architecture is and _who_ does it. Architecture is a property of the system; an architect is the person accountable for that property [2]. The confusion I had for years came from mashing the two together and thinking "architecture" meant "the things the architect draws." It doesn't. It means the structure and the guiding principles — how the system is divided into components, how they interact, and the qualities (performance, scalability, maintainability) that structure is supposed to deliver [1]. The architect's job is to own those decisions, not to own the picture of them. ## The three levels, and why they're separate The model that untangled the roadmap for me was the three nested levels of scope [3][4][5]. Each level answers a different question, talks to a different audience, and is wrong to collapse into the others: ```figure ``` - **Application architecture** is the internals of _one_ system — its modules, layers, and the patterns used to organize code [3]. Decisions here are things like "MVC or layered," "where does data access live," "how is the UI separated." They affect how easy the app is to test, extend, and maintain. This is the level I worked at for years without knowing it had a name. - **Solution architecture** is several applications working together to satisfy one business need [4]. It sits _between_ application and enterprise, dealing with integration points, data flow between systems, and the technology choices that span them. A solution architect's audience is the project stakeholders — they care that the combined systems hit both technical and business goals. - **Enterprise architecture** is the outermost ring — technology strategy across a whole company, abstract and high-level, communicated across the organization [5]. It gets detailed out by solution and application architects. The enterprise architect isn't choosing your database; they're choosing the _category_ of databases the company will standardize on. The reason the separation matters is that the decisions, the audiences, and the failure modes are different at each level. An application-level mistake is a refactor. A solution-level mistake is a rewrite of how systems talk. An enterprise-level mistake is a multi-year realignment. Conflating them is how teams end up with an enterprise architect drawing application diagrams nobody implements, or an application developer making enterprise-wide standardization calls in one repo. ## What an architect actually does With the levels clear, the day-to-day responsibilities read as a single coherent job, not a list [2][6]: - **Define structure and choose technologies** — decide how the system is divided and what it's built on. - **Set technical standards and review code** for architectural consistency — the part that keeps one team's choices from silently breaking another's. - **Assess risk and plan for scalability** — look ahead at what the system will be asked to do, not just what it does today. - **Mentor developers** on the standards and the reasoning behind them. - **Communicate decisions to stakeholders** and balance competing demands — cost, time, quality [2]. The throughline is that the architect is a **bridge** between business goals and engineering reality [6]. A decision that's technically elegant but can't be explained to a stakeholder, or a business goal that's never translated into a technical direction, both fail in the same way: nothing gets built correctly. The communication half isn't a soft skill bolted on — it's load-bearing. ## The hard-to-change test The filter I keep coming back to is the one in the opening sentence: would reversing this decision be expensive? If yes, it's an architectural decision and it deserves to be made deliberately, documented, and reviewed. If no — if it's a one-line change or a library swap — it's an implementation detail, and treating it as architecture is how teams accumulate ceremony over things that don't matter. Architecture is the small, costly-to-reverse core of a system, not everything in it. ## How I use this Before I reach for a pattern or a tool, I name the level: am I making an application, solution, or enterprise call? And then I run the hard-to-change test on the decision itself. Most "architectural" debates collapse once I notice the decision is actually cheap to reverse — that one belongs to whoever is writing the code, not to a design doc. The few that aren't are the ones worth writing up. ## References [1] IEEE Computer Society, "What is Software Architecture in Software Engineering?," computer.org. [Online]. Available: [https://www.computer.org/resources/software-architecture](https://www.computer.org/resources/software-architecture) [2] Red Hat, "12 Skills a Software Architect Needs," Red Hat Architect. [Online]. Available: [https://www.redhat.com/architect/what-is-software-architect](https://www.redhat.com/architect/what-is-software-architect) [3] CodeSee, "Application Architecture," CodeSee Learning Center. [Online]. Available: [https://www.codesee.io/learning-center/application-architecture](https://www.codesee.io/learning-center/application-architecture) [4] LeanIX, "Solution Architecture," LeanIX Wiki. [Online]. Available: [https://www.leanix.net/en/wiki/it-architecture/solution-architecture](https://www.leanix.net/en/wiki/it-architecture/solution-architecture) [5] H. Wei, "Enterprise Software Architecture," Medium. [Online]. Available: [https://medium.com/@hsienwei/enterprise-software-architecture-957288829daa](https://medium.com/@hsienwei/enterprise-software-architecture-957288829daa) [6] "Software Architect," Wikipedia. [Online]. Available: [https://en.wikipedia.org/wiki/Software_architect](https://en.wikipedia.org/wiki/Software_architect) ```quiz Q: The simplest definition of software architecture is… - the set of decisions in a system that are expensive to change later - every UML diagram the team produces - whatever the most senior developer happens to draw correct: 0 explain: Architecture is the costly-to-reverse core — structure, interactions, and guiding principles. Everything easily changed is implementation, not architecture. Q: You're designing how several internal applications exchange data to fulfill one business need. Which level is this? - Application architecture - Solution architecture - Enterprise architecture correct: 1 explain: Multiple systems plus integration points solving one business need is the solution level. Application is one system's internals; enterprise is org-wide strategy. Q: Who is the primary audience for enterprise-level architecture decisions? - The developers writing code in a single repo - The project stakeholders for one feature - Leadership across the organization correct: 2 explain: Enterprise architecture aligns technology strategy across a whole company, so its audience is org-wide leadership, not one project or repo. Q: An architect's communication responsibilities are best described as… - a nice-to-have soft skill, secondary to technical depth - load-bearing — translating business goals into technical direction and back again correct: 1 explain: The architect is a bridge between business and engineering. Decisions that can't be explained to stakeholders fail to be adopted, so communication is core to the role. Q: A team is debating whether to call a one-line library swap an "architectural decision." The right test is… - does it appear in a diagram? - would reversing it be expensive? correct: 1 explain: The hard-to-change test separates architecture from implementation. A cheap-to-reverse choice is an implementation detail, regardless of how it's drawn. ```