What do we mean when we use the word "Architecture" in the context of software?
In the world of buildings, the word "architect" has a fixed, dependable meaning, but not so in software.
It's a question of abuse. The old-fashioned meaning of "architect" might be closer to MasterBuilder?
, but in software, too often you get ChiefArchitects?
. Our field might be unusual in granting lofty titles and great influence to people who cannot perform the essential tasks well. (This is not entirely due to TheDilbertEffect?
.) How many head chefs cannot prepare a wonderful sandwich as well as the apprentices? How many heads of an accounting department cannot prepare an adjusted trial balance as well as the average receivables clerk? Yet how many ChiefArchitect
s are not top-notch programmers? How many would have trouble writing a compiler?
As a result the word "architect", and "architecture" along with it, is so abused as to be almost useless.
Perhaps this is part of the reason behind the debate over the use of this 'title' in computing circles: the lack of agreed definition about what a
(software/computing) architect actually is or does or may do.
Hi Martin. I agree that there is a large problem with the use of the word "Architect" within the software industry. The word "Architect" has a very specific meaning of being the lead individual responsible for designing both FUNCTION AND FORM and being the primary advocate for clients and users. In contrast, "software architects" focus on mainly function and almost never serve as the advocate for the end user; they are essentially senior infrastructure engineers who design the internal structures of software systems.
The arguments presented below that an architect needs to be able to perform software construction themselves is false; a great building architect never needs to pick up a single hammer, just as a true digital architect never needs to write a single line of code...though they certainly need to understand the limits and constraints of software development.
A true digital architect must follow the architectural process of:
1. meeting with clients and users to identify their needs and business requirements
2. iterative design and refinement with the clients and users
3. documenting the design (both function and form) and preparing the software specifications
4. implementation oversight and verification that the design is followed
5. test the system with clients/users, and make design adjustments
6. deliver the final product to clients/users and analyze their feedback
Those who do not primarily serve the needs of clients/users, do not design both function and form, and do not follow a complete architectural process should not call themselves "architects".
--Jim Mazzu (architects.aminda.com)
Martin, I agree. However, I think you'd be surprised. The debate about architects in ComputerScience would persist even without the use of this non-word. Fortunately, this is largely just a Wiki phenomena. People in ComputerScience at large aren't nearly as antagonized by the word. In fact, there are even some great books on the topic of SoftwareArchitecture with my favorite being ArchitectureInPractice?. -- RobertDiFalco
Perhaps the vagueness of the word "architecture" on WardsWiki
is a genuine hindrance to discussion. It seems that every time someone says anything that uses the word, the discussion degrades into an argument about what the word means. Maybe we should stop using it entirely, so we can avoid all the semantic quibbling and get back to the discussions that really matter.
Another problem is that software people tend to think that building architects integrate with the other construction jobs better than software architects integrate with coding teams. It's not necessarily so. I don't know about the really big projects, but in home architecture and building, there exists the same contention between the guys who swing the hammers and wield the saws and the architects who sit up in their air conditioned offices and draw pictures that don't always map so nicely to reality. Many home builders think architects are superfluous on many projects. I think the phenomenon might be termed ProfessionalEnvy?
, a little confusing to parse, but it means that there's envy towards those who have deposited themselves in a position to use mental leverage and delegate the details to another class of worker. I think skepticism and a bit of envy is a healthy thing. Professionals should always be challenged by lay people who can read and write and solve real problems without the PhD, thank you. -- WaldenMathews
(sans degree so far)
What machines are we running? Do we need a firewall here, and what about here? You think the routers we already have will handle everything when we start the VPN?
Somehow, a SystemMetaphor
is chosen, either by the team as a whole or by a SoftwareArchitect
. This is more about ConceptualIntegrity
, and less about the actual implementation.
In some software teams, SoftwareEngineer
are considered separate roles, and the SoftwareArchitect
is responsible for the overall ConceptualIntegrity
, but not the actual underlying structure. Sometimes this is supplemented with Domain Leads. The Domain Leads are responsible for the specification and implementation of the artifacts in their domain as well as the interfaces in their domain that reach out to other domains.
In fact, I would like to believe that the Software Architectures I have design are more like styles
which would not be changed even if the implementation language changed.
It is unfortunate that the term has been confused in software, when its source -- the building industry -- sets a fairly clear example to follow. And there is good reason for software engineering to follow civil engineering: as larger scale commercial endeavours they match quite closely. The difference of medium is relatively unimportant.
In building, there is a distinction between architecture and engineering. Architecture is about the external, user-facing features; it addresses user problems; it is the 'what'. Engineering is about the internal, non-usable features; it addresses technical problems; it is the 'how'. Yes, architecture must have some concern and knowledge of the technical, but it is subsidiary, as a dependency, and not the focus. (Of course this is somewhat idealised, but that is appropriate.)
In software the term 'architecture' confuses the two concepts, and has no distinct meaning; it is mainly a grandiloquence for high-level engineering design. But following more closely civil engineering gives it substance: it is then the overall external usage, function, and appearance of the software system -- the usage structure
, in a deep sense. (This was Brooks' view in 'The Mythical Man-Month'.) For id's Quake 3, for example, it is the desktop executable packaging, the first-person 3D interface, the game-play, the network multiplayability, the content modifiability, etc.
The term 'engineering', in software, is strengthened by having a proper 'architecture'. Indeterminate matters like requirements and usability are distanced. And it shrinks slightly into a more well-defined logical realm -- the technical structure
. Then it treats only what kind of data is moved, where, and what processing is done to it. These are the truly essential concerns of engineering for software. For id's Quake 3, for example, it is the image rendering techniques, the content data-structures, the network protocols, etc.
This separation of architecture and engineering has two benefits: It gives engineering more stabilised, clarified, digested requirements, allowing it to work more determinately. And, it concentrates more attention on pure 'product design' -- something of pivotal value, yet without a sufficiently prominent identity.
If a team of programmers agree to a set of process principles - ExtremeProgramming
, or WaterfallMethod
, or whatever - then they're thinking about a process architecture.
If someone's designing a large API, or even a programming language, to be used by hundreds or thousands of other programmers, then this is the sort of architecture they're dealing with. This is what people talk about what they refer to AlanKay
) or JamesGosling
) being architects.
Often, when people on WardsWiki
say Architecture, they're referring to SoftwareArchitecture
STRUCTURES or ARCHITECTURES?
What do ComputerScience
people mean by 'Architectures'?
On the Wiki page 'ArchitectsDontCreateArchitectures
' part of the explanation of what the large/big/'Global' issues (software) Architects contribute is given as:
'In this case, "big" may be another way of saying "hard to change later".
By analogy, the framing style of a house or barn would be relatively hard to change later, while the siding or exterior color would be relatively easy.'
But this sounds more like 'Structure' to me than 'Architecture', and this interpretation seems to be further supported by the statement by RandyStafford
(himself quoting from SystemsArchitecting
"The essence of architecting is structuring ... The systems architect's task is to bring structure in the form of systems to an inherently ill-structured world of human needs, technology, economics, politics, engineering, and industrial practice." The structure brought forms the concept whose integrity must be maintained.'
Whilst 'structure' may be used in a very wide sense, possibly meaning 'order' or a 'sense of order' to a building Architect 'Structure' is usually understood to be the 'bones' of a building, the 'main lines' of support, load, force, even construction.
Without 'structure', a building 'envelope' will usually fall down!
Sometimes, of course, eg in some traditional buildings, the envelope is
the structure, whereas in traditional timber framed or modern steel/concrete framed buildings the structure is clearly separate from the envelope.
For most architects, then, and in most building schemes, 'Structure' is not the same as 'Architecture'. Structure is a large contributing factor to 'Architecture' but only part of the multi-faceted identity that forms 'Architecture'. The 'architecture' of a building will also include 'decoration', 'circulation', 'spatial design', 'colour experience', 'iconography', 'planning', 'construction', 'finishes', etc as well as a whole host of other qualities more difficult to define: hierarchical, emotional, associative.
Within this understanding the material and colour of the 'siding' (mentioned in the quote above) may well be an important part of the 'Architecture'.
(From my educational tradition 'Good Architects' are concerned with all of the above aspects (and more) of building design).
So do ComputerScience
folk really mean 'Structure' when they say 'Architecture'? -- MartinNoutch
That is, 'Architecture' is making (and committing to and building upon) intentional structural decisions, which typically become difficult to change.
One thing is sure: SoftwareArchitecture
is anything but part of ComputerScience
I heard a new spin on the 'Architecture' word today on the radio over here (UK).
One of the new US Defence Chiefs/Ministers talked about the 'Architecture' of the NMD (National Missile Defense?) system not being quite right yet!
I guess anything can now have an 'architecture', using the word as a replacement for traditional terms like 'arrangement', 'system', 'organization'.
Does it add mystique/glamour/importance using 'architecture' instead?
Martin, I think we'd all like to hear what part of a building is its architecture. For example, I'm not sure why many doing remodeling or restoring call themselves architects. Those creating new structures ... why aren't they just called "building designers"? What am I missing? -- RobertDiFalco
- Yes, "architecture" is the name of the quality that has no name. Or maybe, "architecture" is a name for a quality whose quality has not emerged yet. But it's emerging, anyway. Who are we to argue to argue with something that's emerging? Though maybe it isn't really emerging after all. For all we know, maybe it's being forcefully extruded by some wizard behind some curtain. I sure would like to get my hands on one of those architecture-extruders I hear so much about.
- We don't need to resort to analogies among professions to understand what software architecture is; we can stay within the software field and do just fine. We define Software Architecture thusly: Software Architecture is that which will solve the Software Crisis. What more do you really need to know? Don't ask for more details; you'd only expose your own ignorance.
- If you're not one of us architects, then you're part of the problem.
- Architects do not think about implementations, because thinking about implementation is evil. A well-architected building should be just as good if it were made out of jello as it is when it's made out of wood. That's a really fine architecture. I live in a 100-year-old Victorian, but the architecture sucks. At least my jello experiments so far seem to indicate that.
- Every object in real-life should conform perfectly to its abstract design. If there's ever any sort of mismatch between the two, architects fix the problem by castigating the real-life object, explaining the ethereal principles of design theory until the object is shamed enough to magically transform itself. Good object. Have a cookie.
- Remember that architecture is not merely structure, it's a structure of structures. This definition will work for a while, until there are too many architects and too many architectures, at which time we will need a new word that means a structure of architectures. Superstructure? Superarchitecture? Supercalifragilisticstructialidocious?
- The future is wide open, with more theory to write and more words to define. Meanwhile ... dang, my office chair just broke again. Who the hell makes these things?
- -- WaldenMathews
All of the above is tremendously cynical, I hope. From what I can tell, honestly, 'architecture' is nothing but a fancy word for 'pattern'. In software, patterns of all shapes and sizes matter, and the size of your pattern has no real correlation to the size of your maleness.
Make mine patterns.
The problem with a QualityWithoutaName is that it can mean anything to anybody, very much like 'Architecting' and is just as susceptible to 'TheEmperorsNewClothes' syndrome.
I agree that pattern might a useful word, but 'Software Pattern-maker'??
Using Architecture in software may be not just misleading but inaccurate and ClothesStealing?. -- MN
Agreed. Perhaps I was not cynical enough. The naked emperor's house has no architecture either. One of the unspoken beauties of patterns is that there is no word that means pattern-maker. Is it all that important where they come from, anyway? -- WM
Walden, why should there be an argument about design pattern
versus system architecture
? A pattern is something that becomes part
of a software system - it is not the complete
software system in and of itself. Why would you object to that? A bunch of patterns is just a bunch of patterns, you need some sort of design that arranges those pattern structures into some kind of super-structure. There is design at the pattern level as well as
the system level. There are a number of good resources that go further into this level -- for example, AttributeBasedArchitecturalStyles
, the LenBass?
, and the ArchitectureBasedDesignMethod
. There's a big world of software development out there and not everything is explained by patterns
And Martin, how could I expect you not to think SoftwareArchitecture
is a misnomer? After all, didn't I read in another page where you called yourself a real architect. <g> Have you ever heard the one about first walking a mile in someone else's shoes? You might feel differently after designing and delivering a few complex and long-lived software systems. The world is ever evolving and as a result, language will change and evolve along with it. That's life. But, for what it's worth, I have a couple of friends that are building architects and they seem to find architecture in everything, even gasp
As for QualityWithoutaName
, that term wasn't coined by anyone involved with software
, it was promoted and used by the same person who came up with Pattern Languages, ChristopherAlexander
- oddly he was also a real architect
You also might want to take a brief look at http://www.sei.cmu.edu/ata/ata_init.html
Extending from Architects, we have Architecture. There are respectable universities with masters level courses on Software Architectures, and I've experienced one of these. I have to say that I'm not convinced there's anything to this branch of study that cannot be found in an appreciation of patterns. Do you have any experience or thoughts in this area? -- WaldenMathews
SystemMetaphor, Language, and Process
I have a very negative reaction to chief architect...
This doesn't surprise me. In fact, I think most XP fans dislike the role of an architect. However, I kind of think this is a combination of trendiness
more than anything else. For example, its pretty clear who the ChiefArchitectOfXp
is. That doesn't mean that many people don't participate and refactor its design, but all of them are not the architect. I would say that it is very clear that KentBeck
and one or two others maintains the ConceptualIntegrity
of XP (or formulated the initial vision) much as AlanKay
acted as the ChiefArchitect
s of Smalltalk in order to maintain its ConceptualIntegrity
I think I'm going to vent my spleen a little and I'll probably come back later and delete this, but the emphasis on extreme
(rather than elegant
) together with the apparent hostility towards the role of architect
makes me immediately suspect of XP. I hear the engineers XPers most respect and they are all SoftwareArchitect
s. What's the rub? Isn't FredBrooks
an architect? Isn't JamesGosling
the architect of Java? BjarneStroustrup
the architect of CeePlusPlus
? The interaction between AlanKay
seems (to me) to be a classic
example of Architects and Programmers working together and advancing each others craft to create something fantastic. As always, in practice, there is hat switching, but the roles are still well defined.
Maybe it is all about baggage. I suppose due to bad experiences with architects, the role of architect is being discarded or undervalued. I've heard the same thing about reusable components - due to bad experience, teams do not want to attempt to created shared resources between their projects. Does that mean that reusable components are bad?!? I can pretty much guarantee that whether one wants to accept it or not, every successful software project has had one or two architects with an initial vision who worked to maintain the ConceptualIntegrity
of that system and factor in all the great input from their teammates. If one has a lot of baggage to carry around that prevents them from calling these people architects, I think its a shame. However, it doesn't change the fact that they played the role of SoftwareArchitect
. -- RobertDiFalco
Architecture as the Client's needs
If we took a cue from some U.S. architects, we could say that the customer is the architect in the sense of having a vision for what is to be built. Like a lot of real architects, who don't worry about details like bathrooms or where the girders go, the customer leaves the technical details to the developers. But whenever developers have a question about what the system should do, they ask the customer.
However, in the U.K., architects are generally interested in TotalDesign?
To me, saying that the customer is the architect is an oversimplification that can lead to suboptimal solutions. I'd like to say that the customer is the customer in the sense of having a vision for the problem that needs to be solved.
In my mind, the customer defines the ProblemDomain
and not its possible solutions.
For example, the customer may state I need a way to cross the foobar river
. I will then work with the customer to gather information such as how the river should be crossed, how often will it be crossed, by how many cars/people at a time, etcetera. Then I work with the customer and others in an effort to really put a fine edge on the problem by further analysis of the problem domain
-- how deep
is the river, how strong
is its current
, what is the wind like in this area, etcetera. Then, using my
skill and experience in the SolutionDomain
(i.e. knowing how to solve these types of problems), I present the customer with various solutions like suspension bridge
, rope bridge
, or even ferry
. I present them with the trade-offs of each solution in the language of the ProblemDomain
(not my language of the SolutionDomain
). Then I constantly work with them to ensure that the solution matches the problem at every step of the way.
To me, making the customer the architect could be a disaster. The customer is not an engineer and shouldn't become one. However, they do understand the need for a problem to be solved much better than I ever could. -- RobertDiFalco