This week, I’m attending a training course on the architecture and design of distributed enterprise systems and yesterday morning, somewhat mischievously, I asked the course instructor where he draws the distinction between architecture and design.
We explored an analogy based about a traditional (building) architect in which I suggested an architect knows the methods and materials to use but would not actually carry out the construction work. But the instructor, Selvyn Wright, made an interesting point – if we admire a building for it’s stunning architecture, often we’re talking about the design. Instead, he suggested that architecture is a style or philosophy whereas design is about the detail.
In the UK IT industry, the last 10 years or so have seen a trend towards “architect” job roles in business and IT. Maybe this is because the UK is one of the few countries where to be a great engineer is discouraged and technical skills are undervalued, rather than being held up as a worthy profession.
In reality, there is a grey line between an architect and a designer and I had frequent conversations with my previous manager on the topic (usually whilst discussing my own development on the path towards enterprise architecture – another commonly mis-used term, probably best saved for another post). Regardless, architecture and design do get mixed (in an IT context) and there comes a point in the transition when one can look back and say “ah yes, now I understand”.
I suggest that point is when someone is able to abstract the logical capabilities of a system from the technology itself. At that point, they’ve probably crossed the line from a designer to an architect.
In other words, an architect can understand the business problem from a logical perspective and create one or more possible solutions. The required capabilities are the logical model and the physical elements are those which need be bought, built or reused to match those capabilities. Architecture is about recognising and employing patterns.
Having decided what an architect is, we come to the issue of design. Indeed, design is a word more often used in a creative sense – a website designer, for example, has a distinct set of skills that are very different to those of a website developer. Ditto for a user interface designer or for a user experience designer. Within the context of the architect vs. designer debate, however, a designer can be viewed as someone whose task it is to work out how to configure the physical elements of the solution and create designs for elements of software applications, or of IT infrastructure.
Architect or designer, either way, I still struggle with the term “architected”. Designed seems to be a more grammatically correct use of English (adding further complexity to the design vs. architecture debate) but it seems increasingly common to architect (as a verb) these days…
Hey Mark
It’s a debate I often have too – both in my head and in discussion with others :-) And I’m often reluctant to use the term ‘architect’ when the physical version has such a specific and necessary education background to become qualified and registered to practice. And by it’s nature, has to cope with limits and legalities that do not easily translate into software boundaries.
I tend to consider software architecture to be the elements of the process that benefit most from applying the principles of building architecture (and structural engineering, come to think of it) and need to deal in absolutes – what the end solution ‘must’ provide in terms of functionality, performance, availability, reliability and scale. Creating a ‘blue print’ of the essentials that any design and build must work with/adhere to. An overall design can be included, but it depends on the project remit. And I tend to work with collaborative systems with the all-too unpredictable human element :-) rather than automated transactional ones.
Not sure if that’s a good or bad approach. I find I’m uncomfortable with applying terms such as architect and engineer that have specific industry meanings. Software-based solutions are so often more about craftsmanship, another term like engineering too often undervalued as a profession. Yet it’s a skilled person who can mix up art, science and engineering to create something great.
Interestingly, I was just on holiday and got into a discussion with an architect. She commented how her industry was influenced by technology. When CAD first came in, so many architects went ‘boxy’ with their designs because cubes were the easiest thing to draw with early versions of the software (she still prefers to draw by hand). Now, the current trend is all ‘curvy’.
Final thought – when we look at buildings for reference, we tend to only consider the one-offs – the very expensive landmarks. Instead, perhaps we need to also consider the housing estates, the office blocks. They’re all ‘architected’ too. Unique and stunning design can be part of an architect’s remit, but usually only when there is the budget of a wealthy sponsor…
Great post!
One of my favourite debates! For me architecture is about understanding the basic elements or components of a structure, and how they relate and interact with each other. Design is a lower level of abstraction concerned with detail such as aesthetics (where relevant), and the method of interaction between the sub structures within the basic components.
As for the use of the term architect in IT job titles, it’s job title inflation aiming to get bigger salaries and give the impression of professionalism in an industry plagued by dirty rotten hackers. True professionals are few and far between #cynic :)
Great reply too – and a particularly salient point about the need to consider the ordinary as well as the “unique and stunning”. I’m with you on the value of craftsmanship too.
I guess whether you use the title depends on your role but my job title (grade) was “Senior Customer Solution Architect (CSA3)”, even when I was “designing” solutions (i.e. thinking about configuring infrastructure, rather than in abstracted terms). In fact, I’m a little embarrassed by a post I wrote about architecture a few years ago (based on an MSDN article…) when I clearly wasn’t quite as far along the “architect” path as I thought I was (maybe I’m still not!).
As someone from an infrastructure background, I get nervous when we look at software architecture. Whilst I’m learning that software is the “one true way”, I think we need to think about architecture in a broader sense. If architecture is about spotting and applying patterns (as I suggested in the post), then there are business patterns, software patterns and wider architectural patterns to think about – so architecture is broader than just software (i.e. software architecture is a subset of the whole piece).
Regardless of semantics – the “ilities” are all elements to consider, first from a logical perspective and then by mapping them to physical components to meet the required capabilities.
Mark, Excellent post, I think you er ‘nailed’ it.
I had a wonderful boss in a past life who used the building analogy a lot – widening Enterprise Architecture to the likes of a town planner – laying out the guidelines and ‘design rules’, in building terms its the local vernacular – most notably roofing materials – slate in some places in the UK, red pantiles in the East Riding of Yorkshire.
For a simplistic approach I work on the principle that an Architecture works at an abstracted level above products – an Architecture doesn’t name products, it identifies features and characteristics, e.g. security features required of a firewall.
Architectures link the business drivers (aesthetic qualities in buildings) to the policies and requirements of the implementation of the Architecture (design instances of implementation).
If your architecture names a product, its a design, because the named product always brings a stack of elements to meet the implementation requirements.
The result is that a well written Architecture has a long life (if it is to be of any value, it is not shelfware, an Architecture provides guidance to an instance designer).
A design is the implementation of a product (or products) that by necessity have a much shorter lifecycle owing the fact that products change or are enhanced over time – if you have a workstation ‘design’ based on Windows 7 – it is immediately out of date owing to the fact that Windows 8 has been released.
Really enjoyed your discourse..
Despite being used a la mode as similes I see it like this; an architect says “this is how it must be made”, a designer says “this is how it will look”.
The terms have changed over the course of my thirty years in the business (not helped by skipping the ocean – language here can seem aberrant).
When I hear someone tell me they have ‘architected’ some software I have an overwhelming urge to shout “ha!” In software, architects may design and designers may well design the architecture but really the former means the nuts and bolts and the latter means, to me at least, the creature itself and the life it displays.
Thanks Roger – glad you enjoyed it – although I imagine there are some “architects” out there who will be less pleased with the distinction.
Your former boss’ design rules would be akin to our architectural principles – and you make a good point about longevity and avoiding naming products. I can feel a follow-up post coming on here…
Symon,
I like that distinction – particularly as it deals with design in both the aesthetic sense and from a technology perspective (much of my time “designing” infrastructure configurations earlier in my career, for example).
I particularly like your closing comments though:
Fantastic (from a fellow cynic).
Ian – I’m glad you share my view on “architecting” technology. I quite like your how it must be made/how it must look distinction too, although I tend think it leans more towards aesthetics (which may be more appropriate in software than in infrastructure) – Symon (see a few comments further down) made a good comment in that regard.
There was a time (late 1990s) when to be a “technical design authority” was the goal. A few years later and it was the “lead architect”. Today it seems to be “enterprise architect” – something entirely different, in my view (as I said in the post, that’s probably best saved for another day!).
I think there’s something about values here. A designer will bring a set of values to the table (user experience, aesthetics, performance etc) whereas I think an architect designs those values. This is where the analogies with building architecture break down a little – because, to put it bluntly, buildings are easy so the architect also plays the design role. If architects had the time they’d do the building work as well, or at least that’s the impression I have.
In software or infrastructure architecture we understand the business problem (as you say) and then define what it is about the solution that matters the most. A designer can then define the solution and we’ll know whether it’s a good one based on its conformance with those values.
In a way this debate is getting overtaken slightly by iterative/agile methods?
Martin – I’m certainly getting the feeling that the building architecture analogy only goes so far before it becomes a little tenuous. This comment thread is certainly generating lots of definitions – and I think your second paragraph is a fantastic summary of the way we work in the IT world.
Not sure if iterative/agile methods really overtake the need for architecture but they may decrease the time before we start to see value from the resulting designs.
I first started worrying about this question about 12 years ago. Some form of it was the question most frequently asked of me by students to whom I was teaching the HP Services solution architecture methodology. I now have an answer that satisfies me, but it depends on a somewhat unconventional notion of what architecture is really about. I will not try to do justice to explaining that concept of architecture in this comment; I presented the “short” version of that explanation at The Open Group Conference and Members Meeting in Barcelona last October. If you are an Open Group member, you can find the talk in the conference proceedings; if not, I’d be happy to send you a copy. It runs 140 slides, and the .PDF is 1.35 MB. Drop me a note at lfehskens at alum dot mit dot edu and I’ll send it to you.
The problem, as my insightful colleague David Jackson frequently reminds me, is that the IT community has a peculiarly idiosyncratic notion of the relationship between architecture and design. Only within the IT community are these two disciplines treated as if they are different; everyone else thinks of architecture as a particular kind of design, and therein lies the resolution of this quandary.
The problem is that the IT community uses “design” to mean what I have come to call “little d design”, while everyone else uses “design” to mean what I have come to call “Big D Design”. “Big D Design” is the making of intent-driven decisions, or a set of such decisions, while “little d design” is the making of those decisions necessary to allow an implementation effort to proceed, or again, a set of such decisions. Thus, “little d design” is the activity that typically immediately precedes implementation, and hence the question that Mark has asked is sometimes expressed as “where/when does architecture end and (little d) design begin?”.
Architecture is thus clearly a special case of “Big D Design”; i.e., it is a form of intent-driven decision making. So the real question, whose answer will also explain the difference between architecture and “little d design”, is “exactly what kind of Big D Design is architecture?”. Or asked in a different way, “what makes a Big D Design decision an architectural decision?”. For reasons that are explained in the talk, it’s not about detail (or “not-detail”), or level of abstraction. Nor is it about “style or philosophy”, or patterns.
I’ll cut to the chase, though this will likley not make any sense without the background in the talk, and just provoke a lot of fruitless arguing.
Architecture is about whatever is essential to ensuring that something is fit for purpose, that it is what it’s supposed to be and does what it’s supposed to do. Sharon got closest to this idea when she wrote about “absolutes – what the end solution ‘must’ provide in terms of functionality, performance, availability, reliability and scale”. And it’s not just these “-ities”; it’s whatever the stakeholders consider essential to fitness for purpose.
A few comments acknowledge that our adoption of the word “architecture” is actually a metaphor, and as such we have to be very careful what we carry over from the discipline of civil architecture.
Several commenters also correctly note that the job title is widely abused. There is indeed a far too common tendency to mistakenly assume that “if I am very good at X, I deserve to be called an X architect”.
Finally, regarding Sharon’s remark about her conversation with a “real” architect; there is an excellent in depth treatment of the issue of how our modeling tools constrain the models we build, and thus the designs they represent, in “Simulation and its Discontents” by Sherry Turkle, MIT Press, ISBN 9780262012706.
len.
Hi Mark,
This is a very interesting discussion and I like yourself come from a technical background..
The thing is that when you say ” I was designing configurations”, I am not sure if that s the correct term, its certainly not in mine anyway. I come from an Infrastructure background, mainly deploying Cisco systems hardware/software. My title started of as a network “engineer” and I was mainly looking at designs put together by senior engineers and then configuring the tin. I cant really say I was designing the configuration as I can only configure what the systems have been designed to allow me to configure – following rules that have been defined beforehand and I cant really change that..
I then got CCIE level and started to design networks and for this looked at different types of devices, their throughput, power, rack space etc. Now at this point, am I a designer or an architect, I asked myself many times. I came to the conclusion that “designer” was best suited because I was only looking at components that had are available of the shelf and i am putting together a solution for a given requirement. i was not really “architecting” anything, if that’s a word. These components were designed by the various vendors (switches, routers, firewalls etc) and I was picking the ones that best fitted to my requirements..
Finally got to the stage where i stated looking at EA. Now, EA looks beyond a vendor or a product and you remain agnostic for both. You really have to look a the bigger picture and try to get a birds eye view of what is going in your organisation.
My mentor put it very nicely I think when he said, “EA is architecture by design and not by architecture by accident”. This is where the building of a city and the city planner analogy makes it a bit clearer; making sure the hardware/software solution that you are about to deploy is not just a point solution and that it fits with everything else around you and that if you need to change/upgrade in the future you can do so easily and that its agile.
Excellent posts above and its very interesting to see other takes on this discussion- am i an architect or a designer? – well my brother who is a RIBA qualified architect seems to thing that I cannot even use the word :-)!!