Become a master player in bridge


Managing Design Complexity

"100% of your design documentation isor "parts") are cataloged and
contained  incross-referenced to each other. Consider a
parts manifest as included in a major
the specifications of your informationappliance maintenance bookley (or lawn/garden
resources."tool), I am sure this type of diagram is
familiar to any homeowner who has reviewed
- Bryce's LawThere are many companies today,product maintenance/warranty booklets.Every
most overseas, still tackling major systemspart in the product is identified by number
projects particularly in the areas of bankingand name (see section to the right in the
and manufacturing. These mammoth applicationfigure). To the left side in the figure is a
development efforts contrast sharply withschematic showing how each part relates to
American companies who have failed in suchthe other parts and, as such, represents the
undertakings and are now content withassembly of the product for maintenance
chipping away at systems, program-by-program,purposes.The concept of "Bill of Materials"
with the hope that disjointed software willprovides the means to inventory resources
somehow/someday interface with each other.thus allowing us to share and re-use them.
Whereas foreign competitors talk in terms ofFor example, many of the parts shown in
enormous systems with hundreds of programsFigure 2 are re-used in other lawnmower
and millions of lines of code; largemodels offered by the manufacturer. How can
integrated systems tend to intimidate thewe share and re-use resources without such a
most ardent of American developers. But thisconcept? The answer is simple: we cannot.
is not so much a story about competition asAnd this explains why there is considerable
it is about understanding designredundancy in our information resources and
complexity.People in both the east and thework effort. It also suggests most of our
west recognize the design and development ofdesign decisions are maintained "by the seat
a total system is no small task. A systemof our pants." Most college courses
can consist of many business processes,involving computing are unfamiliar with the
procedures, programs, inputs, outputs, files,Bill of Materials concept. Their focus is on
records, data elements, etc. The problemprogramming and file design, and little
lies in how to best control these informationelse.The concept of "Bill of Materials" has
resources and the design decisions associatedthree  objectives:
with them. Two approaches are typically
used: progressively break the problem intoTo uniquely identify each resource by number
smaller, more manageable pieces, or; tackle aand name (as well as by aliases). Names are
minuscule portion of the problem at a time.nice, but numbers offer a more precise way to
Whereas the former requires a long termuniquely identify a resource. Identification
perspective, the latter can show a quickis critical. After all, we cannot share and
return, which is more appealing to a companyre-use something if we do not know it
with a "fast track" mentality.Some time agoexists.To record the part's specifications.
we conducted a study of customer applicationThus providing a way to determine if the part
development projects. Our research centeredcan be re-used in another product (thereby
on two types of projects: those aimed atpromoting the sharing of parts and
building a total system, and; those aimed ateliminating redundancy).To record where the
building a single program. One obviouspart is used in a product(s) (aka
conclusion was that the number of information"Where-used"). This specifies the
resources used in a major system wasrelationship of parts to each other and,
considerably more than in a program.However,thereby, their assembly. This is also
the key observation made in the study wasextremely useful for "impact analysis"
that there is a finite number of designwhereby we can analyze where the part is used
decisions associated with each type ofin all of our products, not just one, which
information resource. As an example, for anis vital for making intelligent decisions
output, decisions have to be made as to itsabout modifying a part. For example, if we
physical media (screen or report), sizechange the specifications of a part in one
(number of characters), messages associatedproduct, this will severely impact other
with it, etc. For a data element, itsproducts  it  is  also  used  in.
logical and physical characteristics must be
specified (definition, source, label, size,By controlling parts in this manner, a
class, length, etc.). For a program, theproduct's  design  is  fully
language to be used, program logic, required
file structures, etc. These design decisionsdocumented.The "Bill of Material" concept
can be simple or complex; regardless, theycan easily accommodate information resources
are all required in order to design a systemand offer the same benefits of sharing and
or a program. When we multiply the number ofre-using components. By doing so, we can
design decisions by the number of informationeasily manage the 50,000 design decisions
resources,  we  get  anaccompanying a system design project. Our
system/software products may be less tangible
idea of the magnitude of a systems designthan an automobile, aircraft or lawnmower,
project versus the design of a single programbut we can still apply the same concept to
(see Figure 1).FIGURE 1NUMBER OF RESOURCES INtheir control.Therefore, an IRM Repository
AVERAGE  SYSTEMS  PROJECT: 2,006should have the ability to identify, specify,
and cross-reference all of the resources
NUMBER OF DESIGN DECISIONS TO BE MADE:mentioned in Figure 1. This can certainly be
49,850NUMBER OF RESOURCES IN AVERAGE PROGRAMdone manually with paper but this may lead to
PROJECT: 98bureaucratic and access problems for
developers. Instead, automation is
NUMBER OF DESIGN DECISIONS TO BE MADE:recommended. There are several such
2,070NOTE: Decisions are design orientedcommercial products on the market, but it is
only; they do not include Project Managementalso fairly easy to create such software
related decisions (such as those associatedusing today's Data Base Management Systems
with planning, estimating and(DBMS) which are now fairly easy to define
scheduling).From this perspective, theand relate resources (they also provide
average system design project is nearly 25excellent documentation services).The IRM
times larger than the average software designshould be viewed as the hub of all
project in terms of complexity. As adevelopment efforts and provide the means to
footnote, our findings also revealed theinterface (import/export) with a myriad of
"average" system design project is sevenother development tools; e.g., CASE,
times larger than a "complex" software designprototyping aids, program generators, etc.
project.This discrepancy in system/softwareSuch tools will use the intelligence of the
complexity provides a clue as to howinformation resources as contained in the IRM
companies address the problem. Since ato function accordingly. As an example, a
software design project is smaller andprogram generator should be able to interpret
seemingly more palatable to implement than athe program and file specifications in order
total systems project, some companies willto produce the necessary code. Such
focus on software engineering tools anddevelopment tools should also have the
techniques, and abandon total systemsability to turn around and import resource
engineering practices. This is one reasonspecifications back into the IRM. This is
why programming tools enjoy popularityparticularly useful for documenting existing
today.Contrast this with the size of Japan'ssystems/software (aka "Reverse
"Best" project to build the country's nextPopulation").For information on how to create
generation of on-line banking systems. Thisan IRM Repository, please see => concept of
was a major application development effort"Bill of Materials" is an important part of
resulting in 72 "average" systems; aan overall strategy to implement an
considerably larger project than what is"Information Factory" environment to design
typically addressed in the Unitedand develop information resources. But this
States.MANAGING DECISIONSThere are twowill be the subject of a separate
aspects to handling decisions: how they arepaper.CONCLUSIONThis philosophy to managing
formulated, and how they aredesign complexity is no different than what
controlled.Trying to make nearly 50,000is found in the engineering and manufacturing
design decisions in one step is not only anof any product. Engineers break their design
impossible task, it is a highly impracticalprojects into smaller stages so that reviews
way of operating. Just like the design ofcan be performed and revisions implemented.
any product, a system must be designed inA "bill of materials" processor is used to
gradual phases in such a way as it becomestrack
possible to review and refine the design. In
other words, the 50,000 design decisions willthe parts or a product and how they
be made throughout the life of a developmentinterrelate; which is no different in intent
project, not all at once.It is thethan the IRM tool.For people imbued in
responsibility of a systems engineeringprogramming, it is difficult to think in
methodology to define the sequence of eventsterms of "parts" as described herein, but it
for designing a system. As such, theis a practical solution and can be applied to
methodology represents the channel forany development effort, large or small.
formulating decisions. Breaking a complexStandardization and integration of
system design down into smaller, moreinformation resources is built by design, not
manageable  pieces,  also  provides  for:by accident.Without a formalized methodology
for design or an IRM tool to record design
Parallel development and delivery ofdecisions, a major system design is
portions  of  the  systemincomprehensible; there are just too many
variables for the human mind to remember or
(concurrent development within a singlecontrol using manual techniques. It is not
project).An environment conducive forthat analysts do not want to take on a major
building quality into a product (as opposedsystems design project, they simply cannot.
to inspecting for quality afterwards).TheThey lack the organization and proper tools
formulation of Project Management relatedto perform the job effectively. Because of
decisions (such as estimating and schedulingthis, they default to the things they know
the delivery of systems, in part or in full).best, programming, and tackle systems in
piecemeal.The difference between east and
This philosophy of design is no differentwest here is not one of working harder, but
than  any  other  productsmarter. The Japanese and Europeans are
simply better organized and equipped to
design/development effort, such asperform system design than their American
shipbuilding, automobile manufacturing,counterparts. This can be attributed, in
bridge building, etc. All require a specificlarge part, to management's sensitivity to
methodology that breaks the product down tothe role systems play in a company. Because
its sub-assemblies and parts; therebyof this, they are not afraid to tackle large
organizing the specification of parts and theendeavors, while American companies view such
design decisions associated withundertakings as seemingly too massive to
them.Managing the decision making process forundertake. As such, they sidestep large
even the smallest of application developmentprojects in favor of smaller projects that
projects can be a huge undertaking. Wemay address only a portion of the overall
estimate there are approximately 500 designproblem. This is resulting in the unsettling
decisions associated in a small softwaresituation where our competitors are rapidly
design project (as compared to more thanbecoming the world's systems engineers, while
125,000 decisions in the typical complexAmericans become the world's software
system design project). To record andengineers.For more information on our
control these decisions requires somethingphilosophies of Information Resource
more sophisticated than just paper andManagement (IRM), please see the
pencil; it requires an automated "Information"Introduction" section of "PRIDE" at => Bryce
Resource Manager" (IRM), a software toolis the Managing Director of M. Bryce &
capable of inventorying and documenting anAssociates (MBA) of Palm Harbor, Florida, a
enterprise's information resources.Whethermanagement consulting firm specializing in
you call it an "IRM", a "Repository", a "DataInformation Resource Management (IRM). Mr.
Dictionary" or whatever, the philosophicalBryce has over 30 years of experience in the
heart of the product is based on the age-oldfield. He is available for training and
concept of "Bill of Materials" wherebyconsulting on an international basis.
resources (also referred to as "components"



1 A B C D 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99