It is essential to plan well before initiating the development process. Dr R Srinivasan explains why 20 percent of an engineer's time should be devoted to planning

In any branch of engineering design and development, it is absolutely essential to have a well-laid plan before the actual development starts. Many experts have insisted that 20 percent of an engineer's time should be devoted to planning. Good planning will always lead to increase in efficiency and hence towards better productivity. Time management experts teach that a key element in reducing the stress of a person is through proper planning of activities. Planning is all the more important in software development.

I have explained in one of the earlier articles that as soon as the scope of the project is understood by the software development group, they should do a thorough analysis of the project, followed by a good planning on how to execute it. The most important aspect of the planning stage is to decide the system architecture, which has been explained in the last article. Unfortunately, in many organisations least importance is given to software architecture, thereby ending up with either a system of weak architecture or the absence of documented specifications. William Brown, et al, mention that it may be due to the reason that either the manager or the project leader are over confident that they can decide the architecture and implement it without any proper documentation. This practice of deciding the architecture by implementation leads to code writing that will not commensurate with the architecture and is a typical example of another antipattern called, 'Architecture by Implementation'.

The manager and members of a software development team should take note of the architectural aspects in the course of development, such as, the hardware, communications, handling database, security aspects in incorporating applications, elements and tools needed as part of programming and coding, and finally in system management. To explain this in little more detail, the development team should take cognisance of the following so that they do not get into the problem of this antipattern. The software architecture should include usage of the appropriate language and library, choice of correct coding standard, module interfaces, test plan, etc.

Under the communication architecture decision of proper networking protocols, architectural persistence to include databases and file handling systems are important points to note. Inadequate and insufficient details on the above are normally the symptoms leading to Architecture by Implementation Antipattern. The other factors that lead to this situation will be detected in the course of project execution. These risks are hidden due to lack of domain knowledge in the team, absence of technical backup and contingency plans, misunderstood requirements and unnecessary complexity introduced in the planning stage. According to statistics, 30% of projects in software development meet with problems during development and operations stage due to unresolved architecture issues and lack of risk management.

The refactored solution for this antipattern is to adopt a structured approach to look into the architecture and this is where well-written documentation is essential, through which it will be possible to extract the decisions taken on architecture. It is needless to say that such a document must be easily understood by everybody in the team. Hillard et al, in their paper, 'Experiences Applying a Practical Architectural Method', bring out nine steps to define system architecture using viewpoints from the perspective of every stakeholder in the project.

They are:
1) Clear definition of the architecture goals explaining what would be achieved by this architecture, who are the stakeholders.

2) He specifies questions that would answer and satisfy the stakeholders.

3) Decide the views that would represent the blueprint of the architecture

4) Finalise the architecture from each viewpoint.

5) Integrate them to arrive at the final decision.

6) Validate the architecture with formal requirements.

7) Review and refine the views if necessary

8) Communicate the finalised architecture to every system stakeholder.

9) Bring out a good documentation of the architecture and upgrade it, if necessary, after bridging possible gaps between the blueprints and implementation scheme.

Hillard, et al, name this as the Goal-Question Architecture (GQA), because the views of every stakeholder are taken into account in arriving at the final architecture. While Stovepipe System Antipattern exemplifies inadequacy of computational architecture, Architecture by Implementation Antipattern deals with the problem of occurrence of gaps due to multiple viewpoints in deciding the architecture at the planning stage of the software project.

( To be continued)

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)