The need for a decision framework

There is no substitute for the hands-on experience of designing and building software solutions. The key is how you take what you have learned in each situation and apply these principles and lessons to subsequent projects. Recording and maturing a reusable set of decision criteria goes a long way towards establishing personal confidence in our architectural decisions. Each project should not be a blank slate. Rather, we should be leveraging our experiences and the experiences of others and reuse them so that we can surface key issues, prioritize our feature set, and establish which trade-offs we will need to make early on. While we cannot know every detail or requirement before starting to craft a solution, we must still make critical decisions that have significant impact on the direction of the solution architecture. This is all the more a reason to make consistent, well thought-out decisions.

There is nothing magical about a decision framework. In our case, the recommendation is to do the following:

• Gather all the facts that you can. See the next section (Sources of Input to the Framework) for ideas on where to obtain the data points necessary to make informed decisions.

• Look for the hard architectural decisions. What is the big picture? What are the critical aspects that we need to tackle right away? An example of this is determining whether or not your strategy is to copy data between systems, do real-time lookups, or leverage a shared data source. Broad data-sharing patterns shape how you build your system and this is an example of a weighty decision that impacts how we lay out the rest of the solution.

• Capture and evaluate alternatives. It has been said that "if you only have one solution to a problem, then you are not thinking hard enough". Every significant decision point should have multiple possible alternatives that reflect the interests of the project or organization as a whole.

• Weigh the strategic importance of feature requests. All desired solution capabilities are not created equal. If I work in an environment where we have limited in-house development resources and place a premium on system maintainability, then I will value products with standard support tools over products that have a more robust, but custom feature set. Amplify what the solution must do and avoid being distracted by "nice to have" capabilities.

The list of solution criteria we have in this chapter is by no means exhaustive. Instead, it is meant to provide a baseline for you to customize with your own experiences and organizational priorities. Following a framework strategy of "gather information, inspect for impact, assess alternatives, and weigh importance" will help you become successful regardless of how big or small your specific list of solution criteria is.