Architectural Process vs. Architectural Framework, spotting the difference.

Recently I was asked to define my architectural process; at the time I answered that I used a TOGAF 9 process in the execution of my work.

After thinking on it, I came to the realisation that there is a distinct difference between an architectural process and an architectural framework, and that I, like many had gotten the two confused

An IT Architectural Process is how one approaches the process of IT Architecture, I define architecture as a high fidelity risk management process that transforms the ideas the IT Architect generates into solutions for the problem under consideration.

As in the building industry, the work of an architect can be done by another party, but the highest quality results with the least hassle, usually result from contracting a professional, experienced architect to run the process of producing the conceptual designs down to the construction documents.

An IT Architectural Framework establishes a common practice for creating, interpreting, analysing and using architecture descriptions within a particular domain of application or stakeholder community (Wikipedia).

An IT Architect should be able to articulate the process they use in order to deliver value, but how often do we pause and take stock of our personal architectural process, and how it relates to the bigger picture of Enterprise Architecture and architectural frameworks such as TOGAF and Zachman?

The architectural framework defines what documents and designs get produced when, and what the format of those designs should be.

For example, you may be required to produce an Architecture Design Document using a particular template, or produce your designs using a particular modelling language such as UML or ArchiMate.

An experienced IT Architect should be able to run their personal architectural process within any architectural framework, as the architectural process defines what needs to happen, and the architectural framework defines how these things need to be done.

Over time an IT Architect will find that with exposure to multiple architectural frameworks they will begin to incorporate best practices from many different architectural frameworks into their personal architectural process.

An architectural process is built up through about a decade of experience of solving problems and producing designs, the process may be sped up if the IT Architect can find good mentors to learn from.

Here is a quick and dirty guide to IT Architectural process. Now take this with a grain of salt – this is just my process, there is no right way or wrong way to design and it’s certainly not the only way. Put ten IT Architects in a room together and you’ll get ten different processes (in addition to a bunch acronyms you’ve never heard of!).

IT Architecture is a combination of problem solving and decision making. To perform effective problem analysis, definition and sizing of the problem are vital. It is critical that the context of the problem is set before an attempt is made to solve it.

Typically people struggle to begin with solving a problem, this is because they tend to get emotional or overwhelmed at the beginning of an architectural engagement. The tendency is to react with what you ‘think’ the problem is. An IT Architect must choose to understand more about the problem.

A time-boxed review of each domains perspective of the problem is a useful technique to help one in focusing on what is important.

It is vital that you take the time to find out what others think is the cause of the problem or what they consider to be an acceptable solution, but make sure that they have supporting evidence, or you are at risk of being led astray. It is easy to get distracted by history and politics.

A disciplined IT Architect will be strict in setting the context, parameters and scope of the solution space, the biggest trap is in over analysis of the problem space.

This activity should be performed at a level appropriate to the task at hand, one size does not fit all, so be aware of the time taken relative to the size of the task.

Take time to verify your understanding of the problem/task before jumping to solution mode, you should aim to be able to describe the problem/task, understand the possible causes, business drivers and context for the specific task.

Design and problem solving tends to generate many alternative solutions to the task at hand. IT Architects will attempt to remain as objective as they can at this step to avoid eliminating alternatives based on any personal bias.

Aim to generate a list of alternatives and narrow it down to a short list by eliminating only those that do not match any compulsory criteria set by the defined context.

The process of narrowing the list down will involve all your skill as an IT Architect, as you will need to see patterns in the requirements, and be able to make trade-offs between possible solutions/designs. Unfortunately there is no short-cut for this, practice, natural talent and experience will make you better at this.

Your architectural framework can be of help here as such frameworks mandate the creation of principles and quality attributes that IT Architectures need to meet in order to be considered acceptable.

Running your ideas past a respected colleague is an invaluable step in ensuring you have not missed solving the problem, or have over or under designed the solution.

If a design or solution cannot be shared and communicated to others it is useless as it will never get implemented.

Depending on the type of task; design or problem solving, the solution or design must be documented in a way that can be easily disseminated to others.

Design tasks should have sets of schematic designs that clearly communicate the design of the solution in a format that others can understand. Examples of these could be UML, iDesign method or block diagrams in PowerPoint.

Problem tasks should have a decision document created that lists the alternatives considered and the criteria used to eliminate them. Detailed lists of vendors reviewed and the type of thinking you employed in order to arrive at this decision should be part of the document.

In all documents a list of requirements raised and a list of all those involved in the analysis in the various stages as well as their involvement must be added so that you can protect yourself from finger pointing should the solution not work out due to an incorrect requirement or assumption.

These designs/documents should be available in a repository where others can gain access to it as needed and should not be locked up on the IT Architects computer.

IT Architects are experts at refactoring problems on the fly, to refactor means to change the internal structure of something without altering the external behaviour. This skill must be used to modify and alter the process to improve it.

This skill also allows IT Architects to synthesize patterns out of past problems and to use pieces of other designs in other contexts.

Every IT Architect should be able to articulate and run their own personal architectural process, some IT Architects will run their process within an architectural framework, but the process and the framework are two important, but different elements in the IT Architects toolkit.