 |
|
By:
Dr.Thomas
J Mowbray
Chairman,
iCMG |
Deadly sins are mistakes
in software development that result
in failed projects, cost overruns,
schedule slips, and unfulfilled business
needs. Deadly sins are pervasive:
one third of all software projects
are canceled and five out of six software
projects are unsuccessful.1 Unfortunately,
object technology has not changed
this overall prognosis. In fact, each
new technology wave (such as client-server)
tends to increase software risk and
the tendency to commit deadly sins.
Experts such as Strikeleather,
Booch,
Shaw,
and others agree: software architecture
is perhaps the most significant factor
in software system success or failure.
There are some interesting and unique
deadly sins associated with object-oriented
(OO) software architectures.
The seven deadly
sins of OO architecture are depicted
as cemetery. Among these, there are
two unpardonable sins:
the sin of haste
which leads to poor architecture quality,
and the sin of avarice
which leads to excessive architecture
complexity.
Once these particular
mistakes are committed system-wide,
they may be impossible to remediate.
The other deadly sins are closely
related to these unpardonable sins,
as explained below.
1.
The Sin of Haste
Hasty decisions
lead to compromises in architecture
quality. Software projects are often
subjected to severe schedule-related
stress. At project inception, managers
are pressured to trim budgets and
schedules to make unrealistic estimates.
As successive project deadlines are
missed, anything that appears to work
is considered acceptable, regardless
of quality. In this environment, long
term architectural benefits are sacrificed
for expedience.
Quality OO architecture
is the product of careful study, decision-making,
and experimentation. At a minimum,
the OO architecture process includes
farming of requirements, architecture
mining, and hands-on experience.5
Ideally, OO architecture comprises
a set of high-quality design decisions
that provide benefits throughout the
lifecycle of the system
. Significant domain
experience for the architect is essential
for an OO architecture to be competently
defined and defended. With appropriate
domain experience and design patterns,
quality OO architectures can be defined
rapidly.6 However, it is always a
mistake to make OO architecture decisions
hastily.
2. The Sin of Apathy Apathy
about OO architecture
leads to a lack of partitioning. A
key aspect of OO architecture is proper
partitioning. For example, OO architecture
partitions the system into class categories
and defines their interfaces and connections.
The critical partitioning
decision in OO architecture is between
stable reusable design and replaceable
design.5 The stable design remains
with the system throughout its lifecycle,
as individual software modules are
modified, replaced, and added. Replaceable
design details are best allocated
to profiles, vertical specialization,
and metadata.6
Neglecting the critical
partitioning means that the core of
the architecture must change in response
to subsystem level changes. This means
that subsystem-level changes impact
all of the modules in the entire system.
Thus, the sin of apathy leads to poor
support for change. In addition, poorly
partitioned architectures make application
interoperability and reuse difficult.5
3.
The Sin of Narrow-Mindedness
One of the key outcomes
of architecture partitioning is the
identification of metadata. Metadata
is self-descriptive information in
an software system that enables the
system to change dynamically. Many
object-oriented systems are built
with filely no metadata, a deadly
sin. Without metadata, the application
software contains hard coded bindings,
relationships, and assumptions about
system configuration. For example,
the number of servers or clients and
their locations can be made transparently
variable with straightforward use
of metadata services. CORBA standards
include various public metadata services,
such as: the Naming Service, the Trader
Service, and the Interface Repository.6
4. The Sin of Sloth
Distributed object
technology enables application developers
to define system-level interfaces
quickly using the ISO Interface Definition
Language (ISO IDL).5 Automatically
generated interface stubs and skeletons
make the task of constructing a distributed
system relatively easy. The ease of
creating and changing interfaces leads
to the deadly sin of sloth: lack of
configuration control.
Although this sin
is more commonplace in small-scale
OO projects, the habit of frequent
interface change is difficult to overcome.
The more interfaces change, the more
the interface semantics becomes unclear
to developers. Ultimately developers
and maintainers spend more than half
their time performing system discovery,
trying to understand how the system
works. The system loses any notion
of architecture long before this point
is reached.
Proper configuration
control starts with the first phase
of prototyping. Ideally, system-level
interfaces are kept stable during
active software development and only
modified infrequently. Stable interfaces
enable parallel development, effective
documentation, and reduced software
obsolescence.
5. The Sin of Avarice
The second set of
deadly sins is organized around the
sin of avarice: lack of abstraction.
Architectural avarice means the modeling
of excessive details. This results
in excessive complexity due to insufficient
abstraction.
Excess complexity
leads to many software problems and
project challenges. Overly complex
systems are expensive to develop,
integrate, test, document, maintain,
and extend. In some cases, development
steps are skipped (such as testing)
in order to make up for the lost time
and money. This can lead very quickly
to project failure.
6.
The Sin of Ignorance
The sin of ignorance
(implementation dependency) often
occurs in the migration of applications
to distributed architectures. In ignorance,
one assumes that system-level interfaces
can be extracted from fine-grain definitions
of existing application objects. For
example, when an IDL interface is
reversed engineered from existing
C++ header files, implementation-dependent
interfaces are created and promulgated
throughout a system and its subsystems.
If an object's interface
is unique and there are no other implementations
supporting the same interface, then
the interface is implementation dependent.
Every client or object using this
interface will be dependent upon unique
implementation details. When this
occurs repeatedly on a system-wide
scale, a brittle system is created.5
This sin is also evident when vendor-proprietary
interfaces are used without proper
layering and wrapping for isolation.6
7. The Sin of Pride
The sin of pride
is the not-invented-here syndrome.
Object technology supports many reuse
opportunities through the integration
of commercial packages, freeware,
and wrappered legacy.5
Often, architects
unnecessarily invent new designs when
knowledge from pre-existing systems,
products, and standards could be readily
applied through architecture mining.6
Re-invention involves
many unnecessary risks and costs.
New software must be designed, coded,
debugged, tested, and documented.
New architecture must be prototyped
and evolved before it is proven to
provide software benefits.
Concluding Remarks
The "seven deadly
sins" is a popular motif that has
been used successfully to identify
ineffective practices. In the OO architecture
context, the key sins are haste and
avarice.
Haste leads to a
lack of architecture quality. Without
a quality architecture the system
will be expensive to maintain and
extend.
Avarice leads to
too many architectural details (i.e.
excessive complexity). Management
of complexity is a key role of architecture.
With excessive complexity, software
costs and project schedules are easily
overrun.
The practice of
these deadly sins can lead to software
project failures and many other consequences
due to deficiencies in OO architecture.
|