Architecture-driven approach is much better than requirements-driven, document-driven, and methodology-driven approaches. Dr R Srinivasan explains why it is essential to decide on the architecture even before the design aspects of the system are planned

"The greatest challenge is the design of appropriate interfaces for interoperability among various applications "

In one of the earlier articles, I had mentioned the importance of architecture in software development. A good architecture is very critical for the software product to be stable, reliable and also to have provision for easy enhancement in the future. As mentioned by Thomas Mowbray and Zahavi in their book, The Essential Corba, architecture- driven approaches are superior to requirements-driven, document-driven and methodology-driven approaches. It is highly essential to decide on the architecture even before the design aspects of the system are planned. The three major aspects of software architecture are the functional partitioning of software modules, software interfaces between the modules and the technology deployed to take care of the interface. In short, under the software architecture, we take care of the design and implementation as well as the hardware and software platforms to be utilised in the development process.

Even though an organisation may have designated software architects, it is very common that software architecture is decided by a group of people including those who will be involved in the development process as well the maintainers. However careful they are in deciding the architecture, it is possible that there may be some mistakes and common problems during the process of creation, implementation and management of the planned architecture. In this era of enterprisewide application integration, particularly using the Internet as the backbone, the greatest challenge is the design of appropriate interfaces for interoperability among various applications. This is where lack of commonality and good architectural design will lead to system problems.

We will take up the associated antipatterns that occur under these situations, starting with what is commonly known as a 'Stovepipe System'. A system developed with ad hoc architecture is called a stovepipe system, deriving the name from the exhaust pipes of wood-burning stoves. Just like this system needs frequent maintenance to remove the corrosive material from the metal pipes, software systems with ad hoc architecture will face a similar need for frequent corrective actions. Various applications in an enterprise will have the characteristics of having been developed by different people on different software platforms and different languages. If there is no well-planned architecture of the overall system, the enterprise will have the problem of interoperability between various modules and also the reuse of a module.

Reinventing or redesigning the system architecture at this stage will not only be very exhaustive but also lead to high cost. Mowbray and Malveau, in CORBA Design Patterns, explain from another angle, providing the functional description of an enterprise-wide system in terms of a multi-layered architecture. By selecting and defining all the technologies associated with each layer independently will lead to creation of islands of automation, an example of a typical stovepipe system-stove pipe enterprises are caused by isolated technology decisions at every level of coordination.

Another example of a related antipattern occurs when an existing software is migrated to an enterprise level having distributed architecture. This is commonly known as Auto-generated Stovepipe Antipattern. A typical one will be to try the implementation of an existing fine-grained interface software on a distributed system-a futile attempt resulting in a lot sweat and frustration. The refactored solution for designing interfaces for existing software would be to reengineer the interfaces, if possible. The rule is that the interfaces should be designed to suit a larger grained object model. At the enterprise level stovepiping happens because of lack of a standard system model and system profiles. Sometimes lack of proper communication in the group at the time of deciding the system architecture or the inclusion of right type of system architects as part of the project will also lead to creation of an antipattern.

The refactored solutions for the antipattern on stovepipe enterprise is necessarily the coordination of technologies at several levels and a perfect understanding within the project team at the planning stage. Thomas Mowbray suggests a reference model defining common standards and a migrating direction for enterprise systems. Experts like Brown, et al, very strongly suggest four requirement and four specification models along with the number of personnel needed, in each case, to properly plan and resolve interoperability challenges. Their requirement model comprises of Open Reference Model, Technology Profile, Operating Environment and System Requirement Profile. The specification
models include Enterprise Architecture, Infrastructure facilities Architecture, Interoperability Specifications and Development Profile.

( To be continued)

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