Managing Design Complexity

"100% of your design documentation is contained ineach other. Consider a parts manifest as included in a
the specifications of your information resources."major appliance maintenance bookley (or lawn/garden
- Bryce's LawThere are many companies today,tool), I am sure this type of diagram is familiar to any
most overseas, still tackling major systems projectshomeowner who has reviewed product maintenance
particularly in the areas of banking and manufacturing.warranty booklets.Every part in the product is identified
These mammoth application development effortsby number and name (see section to the right in the
contrast sharply with American companies who havefigure). To the left side in the figure is a schematic
failed in such undertakings and are now content withshowing how each part relates to the other parts and,
chipping away at systems, program-by-program, withas such, represents the assembly of the product for
the hope that disjointed software will somehowmaintenance purposes.The concept of "Bill of
someday interface with each other. Whereas foreignMaterials" provides the means to inventory resources
competitors talk in terms of enormous systems withthus allowing us to share and re-use them. For
hundreds of programs and millions of lines of code;example, many of the parts shown in Figure 2 are
large integrated systems tend to intimidate the mostre-used in other lawnmower models offered by the
ardent of American developers. But this is not so muchmanufacturer. How can we share and re-use
a story about competition as it is about understandingresources without such a concept? The answer is
design complexity.People in both the east and thesimple: we cannot. And this explains why there is
west recognize the design and development of a totalconsiderable redundancy in our information resources
system is no small task. A system can consist ofand work effort. It also suggests most of our design
many business processes, procedures, programs,decisions are maintained "by the seat of our pants."
inputs, outputs, files, records, data elements, etc. TheMost college courses involving computing are unfamiliar
problem lies in how to best control these informationwith the Bill of Materials concept. Their focus is on
resources and the design decisions associated withprogramming and file design, and little else.The concept
them. Two approaches are typically used:of "Bill of Materials" has three objectives:
progressively break the problem into smaller, moreTo uniquely identify each resource by number and
manageable pieces, or; tackle a minuscule portion ofname (as well as by aliases). Names are nice, but
the problem at a time. Whereas the former requires anumbers offer a more precise way to uniquely identify
long term perspective, the latter can show a quicka resource. Identification is critical. After all, we cannot
return, which is more appealing to a company with ashare and re-use something if we do not know it
"fast track" mentality.Some time ago we conducted aexists.To record the part's specifications. Thus
study of customer application development projects.providing a way to determine if the part can be
Our research centered on two types of projects:re-used in another product (thereby promoting the
those aimed at building a total system, and; thosesharing of parts and eliminating redundancy).To record
aimed at building a single program. One obviouswhere the part is used in a product(s) (aka
conclusion was that the number of information"Where-used"). This specifies the relationship of parts
resources used in a major system was considerablyto each other and, thereby, their assembly. This is also
more than in a program.However, the key observationextremely useful for "impact analysis" whereby we
made in the study was that there is a finite number ofcan analyze where the part is used in all of our
design decisions associated with each type ofproducts, not just one, which is vital for making
information resource. As an example, for an output,intelligent decisions about modifying a part. For
decisions have to be made as to its physical mediaexample, if we change the specifications of a part in
(screen or report), size (number of characters),one product, this will severely impact other products it
messages associated with it, etc. For a data element,is also used in.
its logical and physical characteristics must be specifiedBy controlling parts in this manner, a product's design is
(definition, source, label, size, class, length, etc.). For afully
program, the language to be used, program logic,documented.The "Bill of Material" concept can easily
required file structures, etc. These design decisions canaccommodate information resources and offer the
be simple or complex; regardless, they are all requiredsame benefits of sharing and re-using components. By
in order to design a system or a program. When wedoing so, we can easily manage the 50,000 design
multiply the number of design decisions by the numberdecisions accompanying a system design project. Our
of information resources, we get ansystem/software products may be less tangible than
idea of the magnitude of a systems design projectan automobile, aircraft or lawnmower, but we can still
versus the design of a single program (see Figureapply the same concept to their control.Therefore, an
1).FIGURE 1NUMBER OF RESOURCES IN AVERAGEIRM Repository should have the ability to identify,
SYSTEMS PROJECT: 2,006specify, and cross-reference all of the resources
NUMBER OF DESIGN DECISIONS TO BE MADE:mentioned in Figure 1. This can certainly be done
49,850NUMBER OF RESOURCES IN AVERAGEmanually with paper but this may lead to bureaucratic
PROGRAM PROJECT: 98and access problems for developers. Instead,
NUMBER OF DESIGN DECISIONS TO BE MADE:automation is recommended. There are several such
2,070NOTE: Decisions are design oriented only; theycommercial products on the market, but it is also fairly
do not include Project Management related decisionseasy to create such software using today's Data
(such as those associated with planning, estimating andBase Management Systems (DBMS) which are now
scheduling).From this perspective, the average systemfairly easy to define and relate resources (they also
design project is nearly 25 times larger than theprovide excellent documentation services).The IRM
average software design project in terms ofshould be viewed as the hub of all development
complexity. As a footnote, our findings also revealedefforts and provide the means to interface (import
the "average" system design project is seven timesexport) with a myriad of other development tools; e.g.,
larger than a "complex" software design project.ThisCASE, prototyping aids, program generators, etc. Such
discrepancy in system/software complexity providestools will use the intelligence of the information
a clue as to how companies address the problem.resources as contained in the IRM to function
Since a software design project is smaller andaccordingly. As an example, a program generator
seemingly more palatable to implement than a totalshould be able to interpret the program and file
systems project, some companies will focus onspecifications in order to produce the necessary code.
software engineering tools and techniques, andSuch development tools should also have the ability to
abandon total systems engineering practices. This isturn around and import resource specifications back
one reason why programming tools enjoy popularityinto the IRM. This is particularly useful for documenting
today.Contrast this with the size of Japan's "Best"existing systems/software (aka "Reverse
project to build the country's next generation of on-linePopulation").For information on how to create an IRM
banking systems. This was a major applicationRepository, please see => concept of "Bill of Materials"
development effort resulting in 72 "average" systems;is an important part of an overall strategy to implement
a considerably larger project than what is typicallyan "Information Factory" environment to design and
addressed in the United States.MANAGINGdevelop information resources. But this will be the
DECISIONSThere are two aspects to handlingsubject of a separate paper.CONCLUSIONThis
decisions: how they are formulated, and how they arephilosophy to managing design complexity is no
controlled.Trying to make nearly 50,000 designdifferent than what is found in the engineering and
decisions in one step is not only an impossible task, it ismanufacturing of any product. Engineers break their
a highly impractical way of operating. Just like thedesign projects into smaller stages so that reviews
design of any product, a system must be designed incan be performed and revisions implemented. A "bill of
gradual phases in such a way as it becomes possiblematerials" processor is used to track
to review and refine the design. In other words, thethe parts or a product and how they interrelate; which
50,000 design decisions will be made throughout the lifeis no different in intent than the IRM tool.For people
of a development project, not all at once.It is theimbued in programming, it is difficult to think in terms of
responsibility of a systems engineering methodology to"parts" as described herein, but it is a practical solution
define the sequence of events for designing a system.and can be applied to any development effort, large or
As such, the methodology represents the channel forsmall. Standardization and integration of information
formulating decisions. Breaking a complex systemresources is built by design, not by accident.Without a
design down into smaller, more manageable pieces,formalized methodology for design or an IRM tool to
also provides for:record design decisions, a major system design is
Parallel development and delivery of portions of theincomprehensible; there are just too many variables for
systemthe human mind to remember or control using manual
(concurrent development within a single project).Antechniques. It is not that analysts do not want to take
environment conducive for building quality into aon a major systems design project, they simply
product (as opposed to inspecting for qualitycannot. They lack the organization and proper tools to
afterwards).The formulation of Project Managementperform the job effectively. Because of this, they
related decisions (such as estimating and schedulingdefault to the things they know best, programming, and
the delivery of systems, in part or in full).tackle systems in piecemeal.The difference between
This philosophy of design is no different than anyeast and west here is not one of working harder, but
other productsmarter. The Japanese and Europeans are simply
design/development effort, such as shipbuilding,better organized and equipped to perform system
automobile manufacturing, bridge building, etc. All requiredesign than their American counterparts. This can be
a specific methodology that breaks the product downattributed, in large part, to management's sensitivity to
to its sub-assemblies and parts; thereby organizing thethe role systems play in a company. Because of this,
specification of parts and the design decisionsthey are not afraid to tackle large endeavors, while
associated with them.Managing the decision makingAmerican companies view such undertakings as
process for even the smallest of applicationseemingly too massive to undertake. As such, they
development projects can be a huge undertaking. Wesidestep large projects in favor of smaller projects that
estimate there are approximately 500 design decisionsmay address only a portion of the overall problem. This
associated in a small software design project (asis resulting in the unsettling situation where our
compared to more than 125,000 decisions in the typicalcompetitors are rapidly becoming the world's systems
complex system design project). To record and controlengineers, while Americans become the world's
these decisions requires something more sophisticatedsoftware engineers.For more information on our
than just paper and pencil; it requires an automatedphilosophies of Information Resource Management
"Information Resource Manager" (IRM), a software tool(IRM), please see the "Introduction" section of "PRIDE"
capable of inventorying and documenting anat => Bryce is the Managing Director of M. Bryce &
enterprise's information resources.Whether you call itAssociates (MBA) of Palm Harbor, Florida, a
an "IRM", a "Repository", a "Data Dictionary" ormanagement consulting firm specializing in Information
whatever, the philosophical heart of the product isResource Management (IRM). Mr. Bryce has over 30
based on the age-old concept of "Bill of Materials"years of experience in the field. He is available for
whereby resources (also referred to as "components"training and consulting on an international basis.
or "parts") are cataloged and cross-referenced to