Decision Making Framework

If you don’t currently have an established decision making framework to help you decide which technologies you would use in a given situation then we would recommend that you look at the book called Applied Architecture Patterns on the Microsoft Platform. With customers who do not have an established decision making framework for architecture decisions we have used an approach based on the method described in this book on many occasions.

Click Here to Buy

This book has many samples looking at situations where there is a challenge to decide how to solve an integration problem. The book uses a process of looking at the requirements and then putting together some candidate architectures which are possible ways to solve the problem. This gives you an option to rule out some of the possible technologies as a constraint or requirement you identify might rule out a potential candidate architecture. Once you have your candidate architectures you would then compare then in terms of the following categories:

1. Design
2. Delivery
3. Operations
4. Organisation

This would mean you have looked at each option from a range of perspectives and should have a rounded view of each possible option. Finally the bit we added to the framework in the book is a process of rating the candidate architectures to identify which one we will use. The below diagram shows this process.

Analysing the Requirements

When we look at the requirements of the integration problem we need to solve, a common mistake is to focus on the functional requirements and ignore some of the non functional requirements. The functional requirements are important and are often easier to get details on what they are, but we should spend some time to make sure we have as a minimum have a list of what they are, but ideally flush out some of the details of them. There are cases where the non-functional requirements could completely change which of the candidate architectures would be the best choice. As your organisation matures in its ability to design and deliver integration solutions you will probably find that there are many non functional requirements which are common to multiple projects. This can also lead to the factors in the organizational area which contribute to common solutions to these common non functional requirements.

Producing the Candidate Architectures

The next step is to produce some candidate architectures which represent ways you may solve this problem. To keep the framework light weight we would encourage that this is done via some diagrams with notes or bullet points which can articulate to the rest of the team what it is that the candidate architecture would do. It is important to try not to write lots of documentation about the candidate just diagrams and key points for consideration. Just enough information for the decision which needs to be made. In addition to the candidates which could potentially solve the problem, we would often list the candidates which have been discarded at this stage. An example of this might be that a problem could be solved with a certain technology or combination of technologies but due to a constrains this candidate architecture could not be used. Listing the options which are discounted and the reason why can be useful later if a decision needs to be justified. It is also important not to waste time outlining a candidate architecture which we could never use lets just log it and the reason why and move on. The overview of a candidate architecture should be just enough information for the team to make a decision.

Comparing Candidate Architectures

The process of comparing candidate architectures can depend on the organisation as to what will work best. In small scenarios it can simply be one person who compares then and in another organisation it could be one or more teams of people. My preference is to identify key stakeholders who need to be involved in this decision and invite them to take part in the comparison process. Examples of stakeholders could include: Architects, Developers, IT Pro’s, Support Team. For each candidate architecture someone will talk through the design and some of the key areas within it and highlight the key points related to the design, delivery, operations and organisation aspects of the solution. Once all of the candidates have been presented we would then move to the rating stage.

Rating

The aim of the rating stage is to identify which candidate architecture is the one we will use. The ideal would be that everyone on the team will agree on the same decision. This is not always an easy thing to achieve. In cases where we have quite important or challenging decisions I like to follow a process similar to Planning Poker for Agile Estimation. The idea here is to reduce the impact of strong characters in this decision making in the initial stages and to give everyone a fair chance to represent their view. Everyone is allowed to submit a rating out of 10 for each candidate architecture for each of the four categories (Design, Delivery, Operations, Organisation). We would review the results and get a feeling of everyones gut feeling for each option. We would then proceed to ask questions and make challenges around the designs and then make a 2nd attempt to rate the solutions. At this stage we will look at peoples rating that has changed a bit and ask them to explain it to see if this gives us new insights. We also compare the solution results using a chart and graph like below:

If the process identifies that everyone is in agreement then we can simply document the decision and get on with things, but this is not always the case. The idea of the framework is to give it a good chance that everyone will be in general agreement with the solution that is the best fit considering all of the parameters involved. The framework should ensure that everyone has had an opportunity to ask questions and to get their perspective across before an options is chosen.

What if we can not agree?

This will happen, there are a number of reasons that the teams may not be able to agree which is the best solution. The aim of the framework is to remove the personal preferences and favouritism from the decision making process and to provide decisions based on structure and logic and what is in the overall best interests of the organisation.

If we have some team members who cant agree then we need to make sure that we have identified a decision maker in the event that we need to have a decision maker who can step up to do this. Getting this to be the right person is important. A common mistake here is to pick a person to be the decision maker based on job title. The decision maker needs to be someone who will own the decision, be accountable for it and see the solution through. I have seen cases where the decision maker is a senior or enterprise architect who knows little about the technical aspects of the decision they are making. Also Ive seen cases where the decision maker chooses an option and then moves on leaving a development team to see through the results of their decision as a leader.

Documenting the Decision

Finally once we have made our decision it is important to document and store this decision somewhere. I always try to imaging that in 6 months time someone may come along and challenge a design decision we made. I think about what I would expect to be in place to help me address this challenge.

As a minimum I would expect:

1. I can easily find where we stored details of the decision
2. The documentation on the decision explains what the decision was about
3. The documentation explains which options we considered
4. The documentation explains which choice we chose
5. The documentation explains why we picked the option we chose

If you have followed a logical process and based the decision on clear facts then any challenge to the decision can be handled in a structured manner. It is still possible that the decision might now not be the best choice. Things can always change over time, but if you have followed a decision making process and have a clear justification for the decision that was made then reasonable person should be able to understand the choices that were made and why.