I’ve worked for Fortune 500 companies engaged simultaneously in 50+ of IT projects as well as small companies with one or two products and I don’t believe there is a need for any organization to have a full-time software architect. Once the modeling is done, it is the work of coding and testing that truly takes the full-time effort. Once underway, 100 hours a month of time is enough for any architect to respond to most needs of all ongoing projects.

Those who have worked in software development, whether in corporate IT or in commercial software companies are most likely familiar with the analogy between building software and building buildings. That is, the architect designs the building and the software developer builds the building. Sometimes there is the equivalent of a structural engineer, but most often times the analogy is left in its simple form as a means of differentiating the roles and to demonstrate the separation of concerns and skills.

The importance of the analogy is to instill that without proper architecture up front, there is significant risk your building might fall down. However, the aspect no one discusses of this analogy is that the engineer is on site full time during the build out, while the architect does 80% of their work up front and then might provide intermittent reviews while the build out is occurring.

How do general contractors deal with this? They hire architectural firms to perform the design and review function. How do organizations deal with this function with regard to software? They hire the architect full time. Hence, the architect’s dilemma–what they heck am I supposed to work on when no new buildings need designing?

Additionally, it’s not uncommon to find that most commercial entities start building their software with engineers alone foregoing the architecture until a crises occurs, resulting in the answer, “let’s get an architect in here.” The belief here is that the architect will save the day and make sure all the buildings under development will meet coding standards and remove all future worry. Oh yes, and this is all to happen without tearing down the building and starting from scratch.

The architects answer of, “you need to start this over and do this right,” is often met with rejection and animosity toward the architect. Moreover, usually an engineer will come up with some hack to get the build out going again, which results in the architect now a full time expensive resource who in their mind couldn’t even come up with the simple answer that some engineer 1/2 the price figured out.

This all results in the architect stuck in a position where they deem all those in charge around them to be blithering idiots who have no care for the quality of the things they build as long as it leads to the end result of recognizing the revenue. In the case of real buildings, this approach cannot occur because life and death are at stake. However, in the case of software, since the impact to the actual business is minimal, when compared to loss of human life, the organization ends up with a group of hackers that look like heroes and a few architects wondering how they got into the mess they’re in.

Hence, it is my belief that until the IT industry recognizes software architecture in the same way as construction recognizes building architecture, that software architects will forever be frustrated by their situations.