Strive for “best” rather than “right”

There is no right solution to a problem; all you can really hope for is the best solution defined by members of your team. Thomas Edison once said:

"We don't know a millionth of one percent about anything."

Right:

• Tends to imply that you have all the data there is to have, that you completely understand the problem, and that there are no alternate solutions under any circumstances that can solve the problem. In other words, it implies alternative solutions are wrong.
• Will regularly stop you from remaining open-minded; a topic discussed further in the post titled Stay open-minded
• Oftentimes leads to analysis paralysis, in that action is halted until you’ve got it right

Best on the other-hand, while still implying finiteness, tends to be more open-ended. Best:

• Implies "not only" or "not perfect" solution, but rather, the best that the team can come up with
• Allows for some level of analysis, but leaves more room for drawing a line that says “we’ve analyzed enough, let’s move forward”
• Allows for the fact that you probably don’t completely understand the problem and that there very well might be alternative solutions to the problem, you just weren't aware of them when a decision needed to be made.

Consider the following process for defining the best solution to a problem:

1. Ensure that you’ve defined the problem, rather than just the symptom of a problem. This was discussed in a separate post titled Solve problems, not symptoms.
2. Define all unbounded solutions to the problem, which requires involving key stakeholders to help you define existing technologies, patterns, and frameworks which might be applicable. Use caution however...given all the variables involved, it’s rare that the solution to a given set of constraints on a project will be the best solution for the slightly different set of constraints on the next one. Clearly you want input from others involved in the project because even as a group, you won’t know all unbounded solutions to the problem, but you’ll certainly know more as a group than you will individually.
3. Determine the viability of each solution, to include its constraints, and the constraints of the environment (technical, people, and process). The constraints are often overlooked unfortunately. I’ve worked with many people over the years that assume (for example) that since a given product/technology has a feature they want to leverage, that they’ll be able to leverage it in their solution and then they make key decisions from that sometimes flawed assumption. Just because a product has a feature, and the organization has the product, does not necessarily mean that the organization's implementation of that product allows you to use the feature the way you expected to. Similarly, while implementing a certain bit of functionality on your PC might only take 10 minutes, it will take orders of magnitude longer in a production data center environment due to contraints, testing, etc.
4. Of your options, ensure that the person or group that has to live with the solution defines the best option. That person might be you, that person might be the developer, that person may be the operations team, or a host of other people or groups. The most effective architects know the most options, or know who to involve to get the most options into the discussion so the team can select the best one.

Once the best solution is determined, formalize the problem definition, key decision criteria, and solution and ensure all those that were involved in the process agree. Then formally document this somewhere, as later in projects, issues will crop up again, people will forget why particular decisions were made, and may question the reason that a given decision was made. That documented information will serve as a reminder as to how and why the solution was defined, which can prove to be tremendously valuable should the need arise to explain the rationale for the solution, and that need will arise, eventually.