What is Architecture?

So since one of my jobs is to change how we evangelize architecture, I thought it might be good to get some clarity around that term. I doubt there’s a word more varied in definition in this industry than architecture. I often joke is that we call both the person who sets strategic technology direction for the enterprise and the person who decides whether to use a linked list or an array an architect. Maybe it’s not that bad, but “architect” does appear to have a wide range of definitions.

I once moderated a discussion at the Strategic Architect Forum that featured Martin Fowler and this topic came up. Fowler’s definition of architecture was something along the lines of “The activities on a project that you do first because you think they’ll be hard to change”. He suggested that asking someone to show you their architecture was a sure way to find out the parts of the project they thought most important or were most worried about. While that’s interesting, I think it’s harmful to not have a consistent definition of the term across the industry. Everyone knows what a developer does. Nobody knows what an architect does. Well, it seems that way anyway.

Maybe it’s because my degree is in engineering, but much of what we call architecture in the computer industry feels more like engineering than architecture. One of the dictionary definitions of architecture is the “art and science of designing and erecting buildings.” Engineering is defined as “The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.”

IMO, building a system that has a set of functional requirements (track customers, process orders, etc) and non-functional constraints (sub-second response time, support 10,000 concurrent users, use Microsoft Windows platform, etc) is an engineering problem. Coming up with the lists of functional requirements and non-functional constraints is the architecture problem.

More on this tomorrow…


Hello Harry, I can't say I totally agree that it is the software architect's role to come up with the list of functional requirements. That's what business analysts or requirement engineers do. The role of the architect is to identify which requirements are important and to surface the significant quality attributes (non-functional requirements) of the system (again, the architect is not the source of the quality attributes but his role is to determine which the most important ones are). The main point, however, is that I think this is just a small part of the architect’s role. You still need to identify major component, the way they interact and demonstrate how the various quality attributes and main use cases are taken care of by suggested solution. Additional roles includes documenting the architectural decisions, the responsibility for technology mapping, evaluation of the architecture and making sure that the architecture both followed and correct during the development of the project I posted my definition of software architecture a while ago on my blog (http://www.rgoarchitects.com/blog/PermaLink,guid,6c1fc5b2-5c07-4675-b29d-eb8882cd8715.aspx) which details this further. Arnon