What is software architecture?

- Let's start by talking about what software architecture is. First, the word architect is a noun. It describes a person. Architects do not architect software any more than a carpenter carpenters buildings. Architects design things. More accurately, they design complete systems. Now, using the building trades as a metaphor for software doesn't usually work very well, but it makes some sense here. Architects don't design every detail of a building. They figure out where the walls go, but they don't figure out how to build a wall. Same goes for software architecture. Software architects design the structure of a complete system. They don't fill in the implementation details. That's programming. Some people look at architecture as if it's just a bunch of components that you plug together to form a system, what I call a LEGO block approach. Architects who think that way spend a lot of time researching and learning how to communicate with those LEGO blocks. Many of them just plug together software LEGO blocks that somebody else has designed. This way of working is highly problematic. Architecture isn't just plugging together pre-built stuff. It's true that you never want to build something that you can buy or get in some other way. All architectures have at least a few components that come from outside, database servers or messaging infrastructure, or some other off-the-shelf solution to a problem that comes up in some corner of the system. That's not the core of the work, though. That LEGO block launch isn't architecture at all. You don't just pick one thing from column A and another from column B. For example, a database is the equivalent of a pre-fab door or a window. You may opt to use that in your building, but an architect does way more than select the doors and windows and then connect them with walls. More to the point, the decision about what windows to use is a pretty minor one. You might even make it, in fact, after the architecture is complete. You don't build your software architecture around your database any more than you design a building around your choice of windows. Architectures describe entire structures, entire systems in software. And those structures and systems have a purpose. A good building architect doesn't just create random rooms with pre-fab components. He or she works with their customers to create a building that suits the way that their customers live. You want a kitchen that helps the owners cook. Counter heights should fit the owners. Appliances need to placed in a way that makes cooking efficient and fun. The sorts of rooms you have, their size, the flow between them, all fit the way the owner lives. And you tailor them to the way the building will be used. Software works the same way. All effective architectures reflect the needs of your customers and of the domain or business that they work in. Computer systems solve real world problems, and the best architectures reflect the structure of that real world. Put another way, a good architect of both buildings and software starts with a customer and works down towards the implementation. You don't build a foundation without thinking about where the walls have to go. Similarly, you should never start with the so-called implementation step, things like the programming language and the database server. You start with the user's problem, and then you figure out the best way to solve that problem. The implementation technology comes last. Aesthetics are important, too. Architects of both sorts use words like clean and elegant to describe their systems. That is, architecture isn't entirely about technical decisions. A lot of it surrounds value judgments that you can't really put into words. It takes years of experience to build that judgment. Unlike building architects, who don't have to work as carpenters, the best software architects have all worked extensively as programmers in order to build that aesthetic sense.