10.5 Software Envisioning

"He who does not tell his reasons for fighting tyranny, will have his reasons told by the tyrant."

-Terry Mitchell

It is essential that software architects understand some important aspects of mass psychology. Most people believe that "perception is reality" and "seeing is believing." And there may have been some time, before technology, when that was a reasonably effective way to think. However, in developing software, initially there is little to demonstrate to convince people of the benefit of a particular design approach. To a very real extent, stakeholders are required to have a degree of faith that an architect and development team can truly deliver software according to plan. The weaker the faith a team has in a particular approach, the less likely a development team charged to implement the approach will be successful. There will be a tendency to give up quickly when things do not function perfectly and to resort to approaches that have worked for the various individuals on past projects. With a strong belief in a particular approach, there is a greater likelihood that developers will pursue a given approach and bring to bear skill sets required to overcome obstacles rather than be stymied by them. As computing technology advances, a greater level of faith is required to be instilled into a team to get the commitment to best ensure the success of a project. The available tools, APIs, and commercial components require a larger investment of time, patience, and experimentation to extract the value out of them required to best add value to the overall project. Faith is the motivating force that will best achieve the goals of successfully implementing a system.

For an architect, the ability to envision new systems and impress them upon people's imaginations is vitally important. The architect works in the gray area between intuitive perception and the logical certainty of software. To translate intuitive system concepts into software reality, the architect must have a talent to envision architectural structures. Then the architect must be able to document these visions and articulate them in a way that sells the concepts to other people. In other words, architects start system envisioning by creating an image of what to create, and then they proceed to build the system, providing more and more depth to the vision, until it appears obvious what the system is about, why it should be built, and how it can be realized.

Not all system concepts are worth building even if they are very "sexy." It has been said that "whatever man can see and believe, man can achieve." Software development is an ideal refutation of this kind of wrong-think. A great majority of software projects envision systems that cannot be effectively realized. In effect, many software projects are subject to the problem of "imagination run rampant." The architect is responsible for moderating this situation. Even though the architect has the power of imagination, like most people, the architect is also responsible for managing risks, both technical and people-oriented, that could have an impact on project success.

In an often-used analogy, software efforts are like building different types of cars. First, they build a Ford Edsel. The system does something useful, but the engineering and manufacturing are not superb; in fact, they are just the opposite! Often the system does not meet the full expectations (system illusion) of the users. But in the eyes of the developers, if the system actually works, they gain much confidence and are ready to try again with much more ambition. When the team tackles the next system challenge, it builds a Cadillac with all the bells and whistles. With encouragement from the users, the system developers create overly ambitious requirements that cannot be effectively realized. Cadillac projects are likely failures. They tend to bog down in trying to create a system that is too complex; the effort lacks focus. After this failure, the team takes a much more sober approach to the next system. This time they envision and build a Volkswagen Beetle, a modest system, but very practical and well engineered. It meets human needs and works reliably. That's the whole point.

Architects want to facilitate their projects to avoid these extremes. Architectural planning creates a solid system structure that goes beyond the engineering limitations of the Pinto/Yugo. Consequently, architects give developers an excellent chance to avoid this phase of system evolution. Architects also argue against building the Cadillac system. They want to advise their colleagues to be practical and avoid the pitfalls where so many other projects have failed. Ideally, they want to design and build the VW on the first attempt. Sometimes architects can't talk people out of making these classic mistakes, so they may get forced into building the Edsel or Cadillac. At this point, they need to make their opinions well known. If the others don't appreciate their concerns, then the architects need to document them clearly and move on to new challenges. They should not dwell on lost battles or try to undermine the committed direction of a project, whether right or wrong, once they have lost the argument. As a computer scientist once said, "It is the fate of competent advisors to have their best advice ignored."