Software architects have to take responsibility for their decisions as they have much more influential power in software projects than most people in organizations. Studies of software projects show over two-thirds of them either are outright failures or deliver unsuccessfully (deadline slip, budget overruns, or low customer satisfaction). Many of the root causes point to improper decisions software architects made, or failures of follow-through on the right architectural decisions.
How can you become a responsible software architect who makes effective architectural decisions?
First, you have to be fully cognizant of your decision process, whether it is agile or ceremonial. You should NOT claim that an architectural decision has been made until the following two conditions are met:
- A decision has been put in writing because architectural decisions are rarely trivial. They must be substantiated and traceable.
- A decision has been communicated to the people who execute it, and the people who will be affected directly or indirectly. Communication is all about creating shared understanding.
Second, review your architectural decisions periodically. Examining the results of your decisions against expectations. Identify architectural decisions that remain valid and those that do not.
Third, enforce your architectural decisions. Many software projects get software architects involved only in the design phase, then they move to other projects or the consultation contract ends. How can they ensure that their deliberate architectural decisions have been implemented correctly? Their decisions will be at best good intentions unless they follow-through with them.
Finally, delegate some decision making to others who are experts in a problem domain. Many architects wrongly assume they have to make every architectural decision. Therefore, they position themselves as a know-it-all expert. In reality, there‘s no such thing as a universal technical genius. Architects have areas in which they are quite proficient, areas in which they are knowledgeable, and areas in which they are simply incompetent. Adept architects delegate decisions about domain problems in which they are not proficient.
