In the last few weeks I've had many conversations with Architecture colleagues about the differences between Architecture and Design. These conversations don't typically start with this question, but more likely about the content of specific deliverables such as documents or strategy papers. Typically as an Architect you are required to deliver guidance on solutions as part of a project cycle, or as part of a larger overall programme. The point at which that guidance changes from 'Architecture' into 'Design' can be quite a contentious one.

For me, as an Architect, my responsibility is to guide the Strategy and direction of a project in terms of the technical aspects. I am effectively the technical manager, governing the direction that a project proceeds in. So how is that different from designing the solution yourself?

I like to think of Architecture as:

"Performing Governance and assurance around a solution to ensure that it aligns to Architectural principles, Strategic concerns and established patterns, in an elegant and cost effective way."

In plain English this is formulating which architectural principles are relevant and applicable, which patterns (in terms of both technical design patterns or business process patterns) are relevant and lastly whether there is an overarching strategy or strategies that drive the direction. It is effectively a set of rules, constraints and measures to guide the further direction of a solution (whether that is a project or a programme). It IS NOT the actual design of a solution but rather the instruction set that a design should use to build their design. When Architectural Governance kicks in and I review a designers design documentation, this is the rules set that I use to effectively 'mark their homework'.

Now, if we have defined the Architecture side of this argument, we should really do the same for the design side. This is a lot more real-world and far less abstract, normally because it is much easier to visualise than 'Architecture' is.

"Design is the process of collecting and placing business and technical building blocks to enable business capabilities."

Again, in real terms this means finding vendors, products and technical elements that fulfil as many of the identified requirements as possible, and arranging them in such a way as to enable an end to end business capability, usually by combining many simpler capabilities into a larger one.

Thinking of Architecture and design in this way makes it very easy to see where the boundary between these separate activities lays, which in turn means it becomes far simpler to see where any handover between resources should be, or where responsibility within a project lies. This sort of clarification also really helps to define the boundaries of an Architectural role, allowing them to focus on specific Architectural deliverables.