Principles, Patterns, Policies & Processes

A question that I am regularly asked is "What is the difference between Architecture and Design?" which is one of those imponderable questions that is often the subject of great debate within the Information Technology community (though mostly down the pub).

Usually this ends up as a compare and contrast type of debate with conjectures such as:

• Architecture is about "What" and Design is about "How"
• Architecture is Objective and Design is Subjective.
• Architecture is Conceptual and Design is Physical
• Architecture is about Requirements and Design is about Solutions.
• Architecture is Platform Independent and Design is Platform Specific
• ...add for personal favourite

However the answer I'm most often drawn to is that Architecture is about establishing the framework that analysis, design and implementation must conform to. That is, it is about establishing the Patterns; Principles; Policies; & Processes that will be used to govern the Application Development.

• Architectural Patterns, as per their close sibling the Design Patterns, is any type of model, template, or artifact that describes a generic problem and the potential characteristics of any solution. The intent of a pattern is simply to capture the essence of a generic solution in a form that can be easily communicated to those who need the knowledge.

The Patterns are both abstract and concrete at the same time. They are Abstract in the sense that they describe a generic solution to a generic problem in generic terms but Concrete in that they can be directly applied to a particular instance of a problem to construct a definite solution.

They are also reusable and can be applied many times to other problems of a similar nature where, even if not directly applicable a Pattern can still indicate the general shape of another derived pattern e.g. the “Powered Vehicle” indicates the general structure of a Car, Lorry, Aeroplane, Train etc but may need extending or modifying to deal with the specifics of each.


• Architectural Principles define key characteristics for the design and deployment of the resulting systems.
  
Architectural Principles are usually captured in short succinct statements such as "All persistent data will reside in a designated Database of Record" or "All end-user data maintenance will be supported through a Single Point of Update", with the minimum elaboration necessary to explain what the Architectural Principle means in practical terms.

• Policies are the non-negotiable constraints that the business itself will apply to any systems or applications that need to be developed. They are really constraints on the Architect (who may not get any input into defining them) as well as the Development team.

These will cover things like technology decisions, programming languages, application availability requirements, disaster recovery, testing requirements and anything else that the business decides is an operational requirement

• Processes cover the mechanisms that will be used to govern the Development with respect to the Architecture including activities such as Design Reviews, Change Management, Divergence & Convergence and so on.

The Governance Processes are most likely to be tailored specifically to the organisation according to the development environment and how it like to manage things. However it is important to emphasise that the the Development activity should conform to the Architectural requirements NOT the other way round.

When brought together into a single coherent Architectural Framework the 4P's provide the tools necessary to ensure that any implemented systems meet desired "quality" criteria without, hopefully, being too prescriptive in how the target systems will actually be designed and built.

Given that the production of Architecture is really just focused on the production of a framework, the main involvement with Systems Development is in governance and, because we all like a diagram whenever possible, fits together like this:

An important point, at a bit of a tangent, is that Architecture is not about Task & Resource Management which is a function of Project / Program Management and, given that there a quite a number of well established methodologies for managing that activity, is not something that I think an architecture needs to consider.

So there we have it - the above is what I see as Architecture and everything else, including physical Design, is part of Development.

That doesn't mean to say the one person cannot carry out both Architecture and Design roles but it's nice sometimes to define where the boundary of responsibility lies.