Software Architects are responsible for a much wider and more interesting range Of issues that include technical, intuitive and human factors, than Project Managers, writes Dr R Srinivasan

If we take a look at the life Cycle Methodology of software development, the different segments are - software Concept, Requirement Analysis, Architecture Design, Detailed Design (including high level and low level design), Coding and Debugging, and Software Testing, In any engineering design of product, It is Absolutely Essential to decide the architecture first before going to the detailed design because a product not based on a good architecture will be brittle and fail soon. Software engineering is no exception to this. In their book on, 'Software Architecture, Organisational principles and patterns,' David Dikel et al say that Software Architecture true is a speciality distinct from software engineering, Programming, and Project man agement. An architect balances and resolves design forces from many perspectives including system stakeholders and system developers. Software Architects are responsible for a much wider and more interesting range of issues that include technical, intuitive and human factors than are associated with the Project Manager.

In today's world driven systems pervade all walks of life. Some typical examples are -remote operation of household appliances, entertainment gadgets, automatic elevators, intelligent automobiles, mobile phones and more. These are in addition to sophisticated real time systems like industrial process control, satellite control, weather information systems, etc. This has brought us to the situation that a software product developed by a team in an organization has many end users. The conceptual integrity and reliability of each one of these products, as perceived by the end user, is the most important factor in ease of use. Frederick Brooks explains in his book, "The Mythical Man Month' that a clean and elegant programming product must present to each of its users a coherent model mental of the application, and of the user interface tactics to be used in specifying actions and parameters. It is the software architect who is responsible for the conceptual integrity of all aspects of the product perceivable by the user, which includes the detailed specification of all its function and the means for involving and controlling it. If the software project is big, comprising many sub systems, the structure should be such that the project will have a Chief Architect, having the over-all perspective, under whom there will be architects of the subsystems. Only in small projects the project manager can take the role of a software architect. So the point to be taken care of is: there should be architecture design before taking up a detailed design in a software project.

Many-a-times a customer who downloads software development looks at the capability of the organisation in software architecture because software development has almost always involved in fitting together products and organisations as will as developing codes. Software architecture is an important activity for both. To quote David Dikel again, "In practice, software architecture and the organisation from a sensitive and highly volatile matrix. Done right, the organisation and architecture can deliver great value; failure can melt the core of the enterprise". What was once an innovative client/server architecture is almost tending towards a dreaded legacy system, now paving the why for development of products to work under internet and Web-enabled applications, i.e. we are moving from the conventional 2-tier architecture to the 3-tire architecture, bringing in the concept of "middleware", Under this context software architecture becomes all the more important. It is therefore imperative to have a common architecture across the Internet-based software product line which will result in bringing out cost effective products with easy interconnectivity with each other.

It will streamline production documentation, training and also marketing. However, in real life situation, it is pointed out by Dr Thomas Mowbray and Raphael Malveau in 'software architecture Boot Camp', that software technology is critically important to the world's business and human society, however software engineering remains a chaotic, immature discipline unable to systematically deliver successful systems. What is missing is software architecture. If this happens, a software house will end up in developing "stovepipe" systems, where subsystems are integrated in an ad hoc manner without any acceptable strategic and having point-to-point connectivity. Such a system will inhibit any change, extensibility or scalability in future. Moreover architecture being ad hoc, the system will also inhibit interoperability and reuse of some already developed components, thereby increasing the cost of development.

Consequently, architecture driven software development is the most effective approach in building reliable and scalable systems. This is what has to be ensured in the development of large enterprise systems like e-Governance, where each ministry is a subsystem of the government and if the application of one should interact seamlessly with the other, there should be a common architecture to which all the applications will be developed.

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