The 7 Deadly Sins of OO Architecture
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:
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.
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.
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
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
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
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.
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
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.
