Does A Building Need An Architect?

Step 2) Brainstorm every imaginable opportunity and all potential changes. By being brave, you will find quantity will eventually become quality. This is purely an exercise in discovery. After all, you must walk on the moon to personally feel and relate to its gravity.

Step 3) Narrow creative processes to techniques that are likely to work, and get sensible. Start applying a cost and benefit analysis. Determine what your true resources are. It is important to understand budgetary constraints, staff ability constraints and timeframe constraints. You need to be vigilant regarding a cost to benefit analysis, as well as a hassle to benefit analysis. Look for potential risks and landmines in the road ahead. Be honest with yourself about the impact of learning curves, culture shock, political impact, systems impact, debugging impact, moving the big ship impact, etc. Repeat step three as many times as it takes. Don’t let mental fatigue prematurely hasten this vital process.

Oftentimes, focused surveys will evolve requiring an increasingly narrowing brainstorming process. Once you are comfortable with the final incremental impact analysis, you are ready for the next step in the application evolution.

Step 4) A high level of confidence regarding strategic planning and schematics is a required precursor for this step. Once the written problem/ resolution logistical spec is done and the final agreed-upon procedural changes outlined, it will be time to sharpen informational processing to support and proactively enforce the objectives of everything you wish to accomplish.

This is where the interface of technology and application come together. Ultimately, all of the high-level planning becomes low-level information handling. When designed correctly, the end-user interface should mandate highlevel performance. Ironically, high-level application will become lines of code and clever programming; this will ultimately become templates, macros, Web sites, databases, smart queries and smart metrics. Codes sequenced in billions of zeros and ones will be routed at the speed of light through networks that should be designed to support all of this with scalability, in addition to anticipated growth and budgetary constraints.

Step 5) Construction industry architects maintaining the most proactive design methodologies will still encounter change orders due to unforeseen problems. The more proactive the blueprint, the fewer the change orders. This holds true in application architecture too. No matter how well you plan, you will encounter unforeseen problems resulting in change orders.

You should always plan, budget and anticipate accordingly. Modifications to the original application design of your IT project will happen. It is easy to make rash decisions when you are in “let’s just get it done” mode. This thinking is likely to create more change orders. Keep in mind, less is better. You can avoid falling into a trap by employing the same methodologies as described in steps one through four, with a narrowed focus on what precipitated the need for a change from the original application.

A strong foundation becomes increasingly critical as you add more stories to a building’s design. Designing information technology to support your operations follows the same rule. The more layers of complexity will likewise require a stronger application. This is especially true when you are introducing either new technology or technology intended to dramatically enhance operations. Overlook this, and you may find your parking spot in front of the Leaning Tower of Pisa.