There are no right answers

Well that’s not completely true there are right answers, they are just not universal and will be relative to constraints at a point in time. 

So, how can we identify the best or most appropriate decision given what we know? 

The first step is to clearly define the problem at hand and identify the key constraints and factors that will impact the decision. This includes understanding of the business context, the underlying technology, as well as the potential risks and benefits of different options. We also need to consider the potential impact of the decision to understand how much effort and resources are appropriate to making the decision e.g. if a decision can be easily reversed then there is little point in conducting long and in-depth analysis and a much lighter approach would be more appropriate. 

Jeff Bezos categorised this difference as ‘one way doors’ and ’two way doors’ Where with ‘one way doors’ there is no going back and with ’two way doors’ it is possible to go back if the decision doesn’t work out as expected.

Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.
As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.1 We’ll have to figure out how to fight that tendency.

https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm

Once the problem and constraints are identified, it’s important to develop a range of options or alternatives. These options should be evaluated based on a set of predetermined criteria, such as cost, risk, feasibility, and impact to both the business and the technology estate. For Type-1 decisions this evaluation should be data-driven and involve input from appropriate stakeholders across the organisation.

It’s important to recognise that there may not be a single “right” answer, but rather a set of options each with their own trade-offs and benefits. It’s up to the decision-maker(s) to weigh these options and select the one that is most appropriate for the specific context.

If the problem and constraints are not well understood it’s difficult to identify a clear set of options, or if there is a high degree of uncertainty, a more agile approach is required.  This can involve experimenting with different approaches or options in a low-risk, iterative manner to gather more information and refine the understanding of the problem and constraints. It can also be beneficial to work with suppliers to create PoC or demonstrations which address a particular pain point or use case.

Remember uncertainty and ambiguity are a normal part of decision-making in a rapidly changing technological landscape. Rather than trying to eliminate uncertainty entirely, architects should embrace it and develop strategies to manage and mitigate risk. This requires a culture of experimentation and continuous learning, where failures are viewed as opportunities for improvement and adaptation.

How can we help make better decisions

When we have a high degree of uncertainty, the key is to take a flexible and iterative approach, gathering data and feedback along the way to refine the understanding of the problem and constraints, and to develop and evaluate a range of options. One approach to this type of exploratory decision-making is the “lean startup” methodology. This methodology involves developing a minimum viable product (MVP) to test a hypothesis or validate an idea, and then iterating and refining based on customer feedback and other data. Another approach is to use scenario planning, which involves developing a range of plausible future scenarios and exploring the potential impacts of each scenario on the organisation and its strategy.

There are several tools, methods, and techniques that can enable improved strategic decision-making in the context of change and transformation in an IT landscape or enterprise. Here are some of them:

1. Wardley Maps: Wardley Maps are a strategic planning tool that enables organisstions to visualise and understand the evolution of their IT landscape, identify areas of opportunity and risk, and make informed decisions based on a thorough analysis of the environment.

2. SWOT Analysis: SWOT Analysis is a method used to identify the strengths, weaknesses, opportunities, and threats of an organisation. It can be used to identify potential risks and opportunities, assess the competitive landscape, and develop strategies that capitalise on the organisation’s strengths while addressing its weaknesses.

3. PESTLE Analysis: PESTLE Analysis is a tool used to analyse the external environment of an organisation, focusing on political, economic, social, technological, legal, and environmental factors. This can help organisations identify potential risks and opportunities and develop strategies that address these factors.

4. Scenario Planning: Scenario Planning is a technique used to explore and prepare for alternative futures. It involves developing a range of possible scenarios based on different assumptions and uncertainties and assessing their potential impact on the organisation. This can help organisations develop contingency plans and prepare for unexpected events.

5. Decision Analysis: Decision Analysis is a structured approach to decision-making that involves identifying alternatives, assessing their potential outcomes, and evaluating the risks and benefits of each alternative. It can help organisations make more informed decisions and minimise the risks of indecision.

6. Lean Startup: Lean Startup is a methodology that emphasises rapid experimentation and iterative development to reduce the risks of developing new products or services. It involves testing assumptions, gathering feedback, and making adjustments based on customer feedback.

In conclusion, using a combination of these tools, methods, and techniques can enable organisations to make more informed strategic decisions and increase the likelihood of success in change and transformation initiatives in an IT landscape or enterprise.

Where do refrence architectures abd frameworks factor?

Frameworks and reference architectures can provide guidance and best practices, they should not be treated as prescriptive or universal solutions. Rather, they should be adapted and customised to meet the specific needs of the organisation and the constraints of the problem at hand.

For example, a reference architecture may recommend a specific technology stack or approach, but this may not be the best fit for a particular organisation based on factors such as budget, skill sets, and existing infrastructure. It’s important for architects to take a flexible and adaptive approach to these frameworks, and to customise them as needed to drive towards the best answer.

Governance and Assurance

Decisions should be made based on a clear understanding of the problem and constraints, and should involve input from stakeholders across the organisation, which requires a culture of transparency and collaboration, where different perspectives and ideas are valued and considered.

Governance (or Assurance as I prefer) should be structured to support this culture of collaboration and data-driven decision-making. The use of cross-functional teams and communities of practice can help creating organic structures to evaluate options, increase knowledge and make recommendations.

A clear decision-making processes that involves input from stakeholders at all levels of the organisation.

Decision Tracking (Decision Log)

A decision log is a powerful tool to help architects capture and track important decisions made throughout the architecture process. Through maintaining a decision log, organisations can provide transparency, accountability, and help informed decision-making.

Transparency and Documentation

• A decision log serves as a transparent record of all architectural decisions, providing visibility to stakeholders and team members.
• It documents the rationale behind decisions, enabling better understanding and future reference.
• It creates a historical archive of decisions, aiding in knowledge management and preventing the loss of institutional knowledge.

Accountability and Governance

• A decision log establishes accountability for decisions made by capturing the individuals responsible for each decision.
• It enables tracking of decisions against project milestones, ensuring adherence to governance processes.
• It facilitates auditing and compliance by providing a traceable trail of decisions made throughout the architecture lifecycle.

Communication and Collaboration

• A decision log fosters effective communication between enterprise architects, stakeholders, and project teams.
• It provides a shared reference point, reducing miscommunication and misunderstandings.
• It encourages collaboration by allowing stakeholders to review and provide input on decisions.

Risk Management and Mitigation

• A decision log helps identify and manage risks by documenting decisions related to risk analysis, mitigation strategies, and contingency plans.
• It enables organizations to assess the impact of decisions on other architectural components and systems.
• It facilitates proactive risk management by tracking the outcomes and consequences of decisions.

Continuous Improvement and Lessons Learned

• A decision log supports continuous improvement by enabling analysis of past decisions and their outcomes.
• It facilitates learning from successes and failures, allowing organizations to refine their decision-making processes.
• It aids in identifying patterns and trends, leading to the development of best practices and informed decision guidelines.

Attributes to Track in the Decision Log

1. Decision ID or reference number
2. Date and time of the decision
3. Decision maker(s) or responsible party
4. Description of the decision
5. Rationale and justification for the decision
6. Impacted capabilities and business functions
7. Impacted components or systems
8. Alignment or exceptions to architecture principles
9. Associated risks and mitigation strategies
10. Decision status (e.g., pending, approved, rejected)
11. Decision outcome and implementation details (include links, rather than duplicating text)
12. Reviewer or approver (if applicable)
13. Comments or notes for additional context
14. Related documentation or artifacts (e.g., meeting minutes, supporting research)

In conclusion

Whilst it’s important to recognise that there will always be compromises in the decision-making process. In some cases, compromises may be necessary to balance competing priorities and constraints, such as cost vs. risk or speed vs. quality. However, these compromises should be made transparently and based on a thorough evaluation of the options and their impacts.

The ability to differentiate between Type 1 and Type 2 decisions, will simplfy your life, and keeping a log of all decisions both small and large, empowers both architects and project teams in making well-informed decisions aligned with the organisation’s goals and objectives.