Proving the Technical Architecture

The doctor can bury his mistakes, but an architect can only advise his client to plant vines.

Frank Lloyd Wright

Can you describe simply how an application is partitioned into a number of discrete components, each of which has a specific purpose? Can you describe how these components interact? Can you describe how and why each component uses the technical infrastructure? Can you describe how a change to a component or to the technical infrastructure will affect the performance of the application? If you have difficulty answering these questions, and the system architecture seems to look like that in Figure 15-8, the application probably doesn't have a coherent and efficient underlying structure to it. Maintenance is likely to be a major problem. An application requires a sound technical foundation that has been proved.

Figure 15-8 A technical architecture?

Typically, a layered architecture will be adopted to improve maintainability by isolating different implementation technologies from one another and from the core business logic of the application. It is vital that the technology for building components and for communicating among components be thoroughly tested and benchmarked. The robustness and performance characteristics must be understood so that sound designs can be created and technical risks managed.

Layering insulates an application from change. If used appropriately with an object-based approach, layering can reduce dependencies in project scheduling by insulating one part of an application from another.

The layering model can be as simple or as complex as required for the technical environment. For example, at TMS, we have used a 10-layer model to describe and categorize the elements of a complex Visual Basic distributed system. The model shown in Figure 15-9 is for a much simpler system.

Where the application will be physically partitioned, the deployment mechanisms should be understood. In particular, you should assess the process and the impact of repeated deployment. Operations staff who deploy systems should be aware of possible version conflicts and any special installation requirements. In particular, they should understand how the registration database is used by all the applications that they install.

Figure 15-9 A layered architecture

Proof of Concept

As mentioned earlier, a key objective of the Pathfinder project is to prove to the business managers and to the IT teams that a business function can be delivered using the application architecture. Using the Pathfinder substantially reduces the perceived risk.

The proof of concept must include thorough testing of the application architecture. Such testing will cover, for example, stress testing the architecture. The architecture should be proven to be a viable basis on which to develop the entire application. Proof of concept includes delivery of the business function into a simulation of a live environment by those who would normally deliver the application. It should be delivered to the user for testing. Difficulties in managing rapid development in the IT department and in the business will be highlighted. Prove that you can deliver. Prove it to the business management, to the technicians, and to the skeptics!