Implementing a Process for Good Application Development Architecture

One of the challenges of being an IT consultant is leveraging experience in a variety of project work. Different business problems mixed with different technologies in various environments can offer few consistencies. One consistency, however, is a warning we proclaim with every opportunity: You never recover from a bad architecture. Fundamentally, it costs you more to maintain and scale an application that has begun with a poor design.

It is much harder to alter a section of code or a database design when the existing architecture does not accommodate the change. How many applications do you support that were born with good intent but exist today as a hodgepodge of quasi-operational functionalities? Remember, bad applications never die… they just cause your budget to fade away.

A good design begins with the proper process. This is less about formal tools and training and more about getting the right people communicating effectively. Here’s how.

Independent of your role in the development cycle, from business sponsor to developer, there are steps that you can take to ensure the proper progress of application development. First, understand that every development effort (large or small) should begin with paper and pencil. One of the easiest ways to translate requirements, across all skill levels, is to draw some simple pictures that illustrate key components (i.e. what types of data will we send or how will clients interact with the system). These conceptual drawings allow you to quickly frame the scope and focus the effort and also lead seamlessly into the more detailed technical designs.

Once these drawings are completed (remember no code has been written yet), translate them to some electronic form; PowerPoint works well. Preface this work with a couple of slides that highlight project objectives and you have distributable presentation material. The objective is to create definition that all team members, stakeholders and internal experts understand and agree to. One of the key components in successful architecture design is communication (within and outside the core team). The clarity of the information should be such that you could present it to non-team members, defending every aspect of the technical decision. There is an inherent, somewhat subtle, pride in having to present ideas in a formal environment. It ensures better quality, spurs good discussion and facilitates brainstorming.

When you have detail (user definitions, data flow diagrams, etc.) that everyone is comfortable with then you are ready to start the building process. As development begins and throughout the development cycle the concepts defined in the original design should hold. They provide the means to validate both progress (how are we doing against the core application goals?) and maintain focus (are the main goals still the same?). Monitoring these details also facilitates the inevitable change control process.

The design portion of an application’s lifecycle is the foundation upon which all else resides. The ultimate success of a development effort is always closely tied to the quality delivered from the initial design effort.