Creating that awesome framework/architecture has always been a task that a mighty few come face-to-face with. The reason for attributing this sort of an eliteness has always been because an application architecture needs to be well-planned. The application not only needs to be functional, it needs to be extendable and flexible. Every application goes through its cycles, and, till the final sign-off, development teams wait with bated breath. As change requests, feature requests and modifcations pour in till beta even (at times), it becomes necessary to create a framework that provides an easy way of doing these things.

A typical development process starts with preparation of the FSD – Functional Specification Document (or anything else that you call it!). This document will tell you what is needed and what the functionality would be for the application. In many cases, it would even provide standard scenarios that need to be covered. It is such an important document and needs to be the main reference point during the course of the entire SDLC – for current and future references. Once the document is well understood, the development process starts. Typically, you see a two-way split of tasks – Design tasks and development tasks. In the ideal world, workflow checks and processes keep issues from cropping up and causing inconsistencies, but, it isn’t always the case.

Getting down and dirty, application architecture is a very important phase in the development process. Architecture includes the following:
1. Understanding the functional requirements
2. Bringing in a broader perspective into the requirements to take care of the flexibility aspect and enable even minor elements to be taken care of
3. Choosing an application development framework after careful consideration of all aspects
4. Creating the proper flow of events and interactivity
5. Componentize/modularize the application
6. Development and manage of the framework
7. Carrying out tests on the framework, especially Unit testing and application profiling

Standards and architectures tend to die out towards the end of the project. When the testing results show up against the developers’ names, the “IF Fixes” are done, just to make sure that the issue is fixed. The product gets released and in many cases, the application goes through a severe structural makeover when it hits its next version. The architect’s role shouldn’t end with just creating the framework, it is a continuous process of monitoring and managing the frameworks.

A large part of the architecture also depends on selecting a good application development framework. For Flex developers we have quite a few frameworks like Cairngorm, PureMVC, Mate etc. Personally, I prefer PureMVC and that has a lot to do with the fact that I learnt that first and like the way it works. That will be a seperate discussion altogether. The importance of using such frameworks for complex/larger/flexible applications is very straightforward. Framworks provide a standard way of implementation, so, when the developer role comes into the picture, he follows these standards to make provide the functionality, fixes and modifications. It is a way to ensure a much smoother development workflow. Sometimes, the decision to use a framework could be a company standard, but, its best to leave it to the architect to decide which one fits in perfectly.

Put your thinking cap on, know your standards and frameworks and plan/structure your coding – that should get you started!