|
 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, iCMG, Bangalore.
He can be contacted at r.srinivasan@icmg.nu)
|
