The first and the most critical part of designing an architecture is to understand what are the objectives of the application. What is it intended to do and what purpose will it solve.

While developing a product a Program Manager (or a similar role) is responsible for creating a set of functional specifications that helps the architect and the Dev teams understand the goals of the system.

From an application's prospective it is highly critical to identify the key scenarios or use cases so that the problem areas can be nailed down, the use cases also help validating and reviewing the architecture as it is evolving.

According to the PnP Application Architecture guide to achieve architectural objectives it is important to identify:

1. Application Type*
2. Deployment architecture*
3. Architecture Style* and
4. Technology options*.

*More on these in next Posts …

Application architecture and Infrastructure architecture are the pillars to an application. Deciding on the infrastructure for a system is as important as defining its classes, objects and workflows.

You need to decide on the deployment topology based on the kind of application being built:

1. Product development usually involves an analysis of the minimum requirements for the product and also a recommended set of hardware requirement. The product needs to be tested under various conditions before recommending these to the client.
2. Custom solutions on the other hand are quite often bound to the client environment they are going to work.

In either case there are few things that become common:

1. Hardware is expensive and thus it is of prime importance to understand the end user build the application on that; rather on assumptions. Building a high end graphic user Interface for a small business solution might not just work out for a majority of clients. Sit back and think "who" is the solution for?
2. Decide your Architecture Type based on the end target i.e. "The Client".
3. Layer your design to improve scalability and maintainability.
4. Data sent over the wire is expensive .. Make minimum roundtrips.

In the "client- server" there were only two roles - The Client and the Server :) . Passing information was simple, the client made a request to the server and the server responded with an answer, soon everybody wanted their answers and they wanted them fast .. Having a single server responding to so many request made the poor guy burst out in tears. The main problem here was the responding server was not able to scale out because all the code was so coupled it was impossible to move it on separate boxes.

Then came the concept of 3 Tier applications which seemed to solve most of the problem, you break your application into a Client, Web and Database Tier and scale out the heavy bits since they were loosely coupled. These were physical separations of each of these tiers.

As software's started to become complex a need was felt of further categorization of the components in each tier, this logical grouping was coined was Layering. A typical 3 Tier application would consist of three layer - Presentation, Business and Data where each layer grouped components denoting the Client UI, Business Logic and Data access respectively.

The Layering architecture is one of the most popular architecture style and usually works for most kind of applications, it is however important to identify the need of layers based on the complexity of the system.

Some key guidelines here:

1. Make sure the components depend only on components in the same or lower layers.
2. Make the layers Loosely Coupled and Highly Cohesive.
3. Avoid any circular dependencies.
4. Use only the layers that are relevant to your scenario .. Just because your mate on the other project has three layers does not mean you should have them too .. Think wisely before defining the layer, it does not make sense to have a Presentation layer if you are developing a framework or a service. Similarly if you are creating an application that does not have a data store there is no need for a Data Layer.

* *The distinction between Tiers and Layers is an important one .. Will cover this in future posts.

the prerequisite to having meaningful review are twofold:

1. Follow Point 1 above, know what you are developing .
2. Establish design and architecture standards for your application and then use these standards to perform design inspections.

Use a Question driven approach to check if the current design meets the architecture objectives, infrastructure and organizational constraints, performance and security goals.

This is a build up step of the first steps, once you know the business goals and the infrastructure in hand, having these review become a breeze.

Moral of the story:

"The Application architecture should be able to achieve (1) with the resources identified in (2) by applying (3)."