Many choices must be taken during the attachment-forming process. Some may be related to the library or infrastructure selection, while others may be related to the application of particular design patterns.In any event, the architect is often in charge of making the choice. The architect gathers all available data, considers it for a period, and then specifies the guidelines that the developers must follow. The fact that there is an improved method won’t surprise you.
The decision-making process is described by Mary and Tom Poppendieck in their work on lean development. They think that the ultimate choice should wait until the most crucial moment, when the team’s inaction will have permanent (or difficult to reverse) repercussions and a decision will be made on its behalf if no decision is made. And that makes sense—the more information available, the later a judgment can be taken.But more often than not, “more information” is not “sufficient information,” and as is widely known, wiser decisions are made “backwards.” For an architect of quality, what does that mean?
An architect’s mind is always racing with what choices he will have to make soon. When it comes time to make a decision, the architect may ask many developers to select one solution and work on it for a while if the team is composed of more than two or three developers and they practice collaborative code ownership.When a turning point occurs, the group gets together to go about the benefits and drawbacks of various approaches.
When one has the chance to reflect on the past and consider the ramifications, the optimal resolution to the issue is typically readily apparent to all.Actually, the architect just needs to oversee the adoption process rather than making a choice.
This method works for both easy and difficult tasks. Not only does it give the team flexibility in using the Hibernate templates that the Spring infrastructure offers, but it also successfully addresses the issue of which JavaScript infrastructure to select for the project. Of course, the task’s complexity has a big impact on how mature the solution is.
It requires more work to try two or more solutions than it does to apply an a priori solution. except an a priori decision frequently results in decisions that are subsequently found to be inadequate, leaving the architect with little alternative except to reject the current implementation and all of its consequences—both of which result in an inefficient use of resources. Even worse, if no one on the team is aware that the technique selected is not ideal since all possible options have not been considered.Then there’s no way to know if the effort was in vain. Ultimately, the most economical course of action can turn out to be trying multiple ideas.