Architecture Definitions
Architecture DefinitionsWhat 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 ChiefArchitects 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.
-- MartinNoutch
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 and SoftwareArchitect 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 than systems 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.
Process.
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.
Language.
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 (SmalltalkLanguage) or JamesGosling (JavaLanguage) 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' (ouch): "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?
-- MartinNoutch
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
Therefore
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? book SoftwareArchitectureInPractice, 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 software.
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 and baggage 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 or AdeleGoldberg acted as the ChiefArchitects 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 SoftwareArchitects. 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 and DanIngalls 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.
-- RalphJohnson
However, in the U.K., architects are generally interested in TotalDesign?.
-- MartinNoutch
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 or submarine. 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
See: ArchitecturalCulturalAssumptions, CanAnArchitectureEmerge, StopUsingMetaphors, WhatIsArchitectureAnyway
EditText of this page
(last edited November 9, 2010)
or FindPage with title or text search