Does A Building Need An Architect?

Information Technology (IT) is more complex than most buildings. As such, it requires a similar architectural process in order to achieve a positive and predicted outcome. Too many IT projects don’t conclude positively or as predicted. Business analysts run hundreds of surveys in companies located throughout North America. They’re exposed to many IT environments of various complexities. As an analyst, my experience has led me to believe that IT professionals typically fall into three categories. The first and largest group would be those who believe they are IT illiterate. The second-largest group would be those who consider themselves the second coming of Bill Gates. (This group is considerably smaller.) The third and smallest group are those who believe they have no understanding of IT. This common disparity creates a frequent problem. Those who believe they have no understanding of IT look to anyone with some understanding as highly proficient in all areas—even worse, they often confuse PC proficiency with IT proficiency.

The truth is that even those who are brilliant in the IT domain are rarely strong across all divides. It is more likely that quality IT staff members will have superior abilities in one or two areas. The following are four basic areas of proficiency to consider. Certainly, there are many ways to slice this pie, but in order to keep this short and sweet, consider these four.

• Hard (Hardware & Networking)
• Soft (Software, Database & Coding)
• Application (Planning & Programming Adaptation/High Level)
• Project Driver (Single Point of Contact & Oversight/Super High Level)

It is rare for a person to be exceptionally strong across all divides. Placing too much faith in the office “PC guru” is one reason why so many IT projects fall short of the anticipated miraculous impact on sales and profits.

Projects are often driven by the shininess of new equipment and the technical jargon added to a staff ’s vocabulary. The person or persons entrusted may believe acquiring state-of-the-art servers, monster switches, brilliant routers and the latest cabling and optical fiber is the answer to everything. The problem is that the real “answer” is to question what was never asked or was not asked properly.

Questions are the foundation of a building in the IT world referred to as “application.” An ergonomically designed building in the construction world requires a quality architect. A well-designed IT environment requires the same.

The best application architecture comes from processing what you are trying to accomplish, while momentarily ignoring the seduction of the hardware and software and the allure of multibillion marketing practices. It is not uncommon for a highly complex technology environment to become an expensive albatross. If the brain for the brain is missing, the application side is weakened. Wildly expensive, enormously sophisticated software purchases loaded with unimaginable binary horsepower fall victim to the same short-sightedness. I have analyzed many companies determined to purchase bigger servers and laborious software; however, they have absolutely no way to support it.

Proper planning is the key. As obvious as that statement seems, technophobia often critically weakens this essential step via a “passing the hot potato” style of delegation.

Architects require surveys of existing conditions, such as soil conditions, to support enormous building weights. This ultimately defines footings and foundation requirements. Lot sizes, in combination with the local laws pertaining to setbacks and zoning, affect what you can and cannot build. The survey is where an architect starts in the construction world—the same applies in application architecture. A survey, as well as the following steps, must be performed.

Step 1) Take a survey of the current platform. Both the business platform and the technology platform need to be analyzed. The current hardware is normally the only substantial survey ever taken. The analysis must be heavily weighted toward current business operations. Potential opportunity, lost opportunity, efficiencies and inefficiencies, as well as the current operations model, must be graphically converted into flowcharts that define everything. Schematics need to clearly depict the flow of information, interdepartmental processes and global processes accompanying written specs. A company outsider should be able to understand in detail critical processes from the survey’s findings. An identical process is used in the construction industry by architects who eventually evolve their construction document from existing conditions documents called asbuilt drawings, plot plans or “surveys.”