ftp.umcs.maine.edu/2015-02-07.ftp.umcs.maine.edu.tar/ftp.umcs.maine.edu/pub/WISR/wisr6/proceedings/ascii/burdick.ascii

Text File | 1993-10-19 | 24KB | 472 lines

            Domain  Analysis  and  Information  Engineering:


       Promoting  a  Combined  Attack  on  Stovepipe  Systems



                                          Roberta G. Burdick



                                           Unisys Corporation

                                     Government Systems Group

                             12010 Sunrise Valley Drive, Dept.  7670

                                           Reston, Va.  222091

                                           Tel: [phone]

                                           Fax:  [phone]

                          Email:  [e-mail]



                                                  Abstract


    The call for improved software quality and productivity and reduced development and main-
tenance costs has become a familiar battle cry, used to justify an ever-expanding number and
variety of increasingly specialized disciplines, methods and tools: data administration, business
process reengineering, business reengineering, information engineering, object orientation, and
domain analysis, to name but a few. Although some of these disciplines did not originally focus
on reuse, each is gradually coming to recognize that reuse is central to their efforts toimprove
software quality and productivity.
    However, professionals in any of these disciplines often work with little understanding or
connection to the others. Therefore we are unable to collaborate on our separate contributions
to the same underlying problems.  As a result, we are far from agreement on howto achieve
reuse, or even what reuse means.
    Ideally, to realize the promised benefits of reuse adoption, an alliance should be arranged
between the relevant disciplines. This paper is proposing to start this alliance with an arranged
marriage of Domain Analysis (DA) and Information Engineering(IE). It discusses the "stovepipe
domain" problems that this marriage would solve. It describes the common and complementary
traits of both "parties" that should lead to marital success. Finally, it explains why the religious
centers of semantic modeling and/or object orientation, which represent a set of values and
practices already shared to some extent by DA and IE, may offer an ideal support framework
for this marriage.


Keywords:  reuse, reuse planning,domain analysis, information engineering, interoperability,
domain scoping, stovepipe domains, component, variant


Workshop Goals: Exchange of ideas and experiences with other researchers and practitioners;
brokering the marriage proposed above.


Working Groups: Reuse, integration, and interoperability (suggestion); Reuse management,
organization and economics; Domain analysis and engineering; Reuse and OO methods



                                                 Burdick- 1


1      Background



Most of my 16 year career has been focused on management information systems (MIS) integra-
tion problems.  My work has consisted of identifying,  analyzing,  repairing,  working around,  and
preventing  information  inconsistencies  by  addressing  the  problem  of  unplanned  inter-system  re-
dundancy.  For  this  reason, .I  have  chosen  to  investigate, and  participate  in  the  evolution  and
adoption of, several disciplines with an eye toward reuse.  My responsibilities have included prac-
titioner, technology transfer agent, methodology integrator, and applied researcher.  I have been
a data administrator (Mobil Oil), an information center coordinator (Mobil Oil, World Bank), an
information engineering, object-orientation, and business reengineering consultant and methodol-
ogist (World Bank, James Martin and Company, Syrinx), and a domain analysis researcher and
technology transfer agent (Unisys - STARS).


While at JM&Co., I authored a paper integrating Information Engineering and Object Orientation
entitled "Information Asset Management and Reuse."As a staff engineer on the Unisys STARS
Reuse  team, I  have co-authored  our  Software  Engineering  Environment  (SEE) "Reuse  Product
Plan" and evaluated several candidate SEE  tools for reuse supp ort. I am currently planning and
analyzing the semantic and architectural requirements for fine- grained integration of CTA's KAP-
TUR [1], Unisys's Reuse Library Facility (RLF), and IDE's Software through Pictures (StP) tools
to improve reuse support for our STARS demonstration project.  I am also participatingin the for-
mulation of our upcoming guide to Reuse Oriented Software Engineering (ROSE), an instantiation
of the CFRP [2].



2      Position



2.1     Introduction



Neither Domain Analysis nor Information Engineering is itself a monolithic discipline.  Each term
describes families of disciplines with both commonality and variability among its members. In this
sense, both DA and IE are themselves domains,worthy of more formal study to compare, contrast,
and classify the thinking behind their various branches.  However, the ob jective of this paper is
to stimulate further research and discussion on the merits and methods of DA/IE integration; not
to expand on the distinctions among the various DA and IE schools.  To this end, the following
discussion exploits simplifying generalizations.



2.2     DA and IE: Commonality



Domain Analysis and Information Engineering have much in common.  Both trace their lineage to
the ubiquitous quest for improving software quality and productivity, while cutting development
and maintenance costs. Both point to planned and managed reuse as a central tenet. Both stress
the importance of models and architectures that identify and codify relationshipsamong multiple
systems, and that systematically partition that knowledge along several dimensions:  problem vs
solution space, specialization vs aggregation hierarchies, as-is vs to-be models,etc.  Both implement
their architectures using templates, component- based and generative techniques;  both use their
architectures to guide the creation of reusable assets, and the comp osition of assets into systems.


In  addition, branches  of  both  disciplines  state  emphatically  (especially  when  not  in  marketing


                                                        Burdick- 2


situations) that the successful transition from the "one system at a time" mentality requires not only
technological but cultural and organizational change [3 , 4 , 2 ]. Both promote technology transfer,
and  recommend  small  modeling  teams, guided  by  modeling  experts  but  staffed  by  professionals
who collectively represent expertise and stakes inall asp ects of the area under study. Finally, both
disciplines emphasize process as well as product, stress the importance of planning and learning,
and have developed remarkably similar frameworks for the development of a new kind of supporting
infrastructure.



2.3     DA and IE: Vive la Difference



The key differences between Domain Analysis and Information Engineering are first of all differences
in defining the problem scope. These scope differences reflect the origins of DA and IE in different
client communities, and their consequent fo cus ondifferent but related problem spaces.


The optimum scope of an Information Engineering initiative isan entire enterprise.  Ideally, spon-
sorship of the IE initiative should residewith the enterprise's chief information officer or equivalent
[5] (in practice, narrower sets of interrelated functions are often studied initially, with significant
benefit).  The scope of the initial planning pro ject is broad and shallow.  This results in multiple,
carefully scoped candidate follow-on projects; each is increasingly narrow inscop e anddeep in its
level of detail.


IE, which spearheaded the "enterprise modeling" discipline, was developed in response to the inte-
gration problems facing Management Information System (MIS) developers and the collaboration
problems  facing  their  end-users.  Coordination,  collaboration,  and  information  exchange  among
separate business activities (e.g.  accounting, payroll, benefits, personnel, etc.)  is vital to the ef-
fectiveness  of  a  complex  business  enterprise.  However,  the  separate  systems  supp orting  each  of
these business activities tend to be designed and developed in isolation. Frequently, each system
is designed for use by customers representing a single organization within the enterprise.  Because
these systems function as stand- alone vertical slices through the enterprise, often impeding rather
than supporting collaboration, they are sometimes described as "stovepipe systems".


The gaps and overlaps among these "stovepipe systems" present both their maintainers and end
users with enormous difficulties. Their shared information is often defined and captured in multiple
systems and files. These redundant and inconsistent stores and definitions escalatesystem life-cycle
and  usage  costs  and  increase  developer  and  user  frustration.  Since  many  systems  are  designed
to  support  organizations  whose  functions  overlap, similar  functionality  is  also  redundantly and
inconsistently defined and maintained. Structural and dynamic interfaces among these systems are
frequently non-existent, or added on an ad hoc basis.


Information Engineering results in integrated systems,composed of reusable assets that are planned,
architected, and designed to support enterprise-wide collaboration.  IE stresses the value of cre-
ating enterprise-wide architectures, carefully partitioning sharedinformation and functionality to
create reusable "information assets," and capitalizing on combining these reusable information asset
components to compose sets of interoperating systems.


The recommended scope for a Domain Analysis initiative is a group of similar systems representing
both significant commonality and variability. Generally, these are functionally similar systems [1],
but this is not strictly necessarily [3].  Whatis necessary is that they represent an opportunity for
reuse that offers a clear business advantage.  Ideally they should be under the control of a single
development organization or a single sponsoring higher-level manager [3 ].



                                                        Burdick- 3


Domain Analysis originated in response to the needs of software development organizations with
core competencies in one particular functional area (e.g.  accounting). Their lines of business fre-
quently  consist  of  scores  of  similar  systems, each  "developed  to  spec"  for  a  different  client  (or
sometimes for the same client). This multiplicity of unplanned system variants results in escalating
system life-cycle and usage costs and increasing stakeholderfrustration.  Therefore, Domain Anal-
ysis asserts that reuse is most likely to be successfully implemented and adopted by capitalizing on
commonality, and understanding and controlling the variability, within sets of functionally similar
systems (system families).


DA architectures  may  describe  current  system  commonality and  variability,  and,  in  some  cases,
prescribe the range of variability to be supported in the asset base. To do this, DA models generally
describe  variants  as  "features"  embodying  the  concerns of  "stakeholders."  These  "stakeholders"
may represent not only the user community but, for example, varying development standards, and
development and operating environments. Tofully understand the history of and reasoning behind
system  variants, several  DA branches  also  stress  the  capture  of  system  genealogies, noting  the
decisions, trade-offs, and rationale behind each feature.


To  summarize  these  differences, IE focuses  on  reuse  that  supports  collaboration  among  related
functional areas (such as accounting, payroll, b enefits, p ersonnel), often ignoring the nastiness of
modeling the variability among multiplesystems supporting any one function (e.g.  accounting).
The result of IE's emphasis on commonality sometimes flies inthe face of real-world requirements,
and misses enormous opportunities for reuse. On the other hand, DAfocuses on reuse that supports
the commonality and required variability among multiple systems supporting any one function (e.g.
accounting), often  ignoring  the  nastiness  of  modeling  the  collaborations  among  related  domains
(such as accounting, payroll, benefits, personnel). The result of such isolated DA projects could
very well replace "stovepipe systems" with "stovepipe domains."



2.4     DA and IE: The Courtship



Far from being incompatible, these differences between Domain Analysis and Information Engi-
neering actually reflect orthogonal and highly complementaryconcerns.  The reuse-based interop-
erability fostered by IE has an important role to play in many organizations adopting DA. The
MIS area is not alone in requiring systems to communicate, share information, or support collab-
oration among their users. Following are several scenarios showing the need for an IE perspective
in traditional DA arenas:



    fflStrategic and tactical DoD systems, manufacturing and process control systems, even CASE
       tools must frequently interoperate or support user collaboration to fulfill complex functions
       or missions.


    fflSeveral  DA approaches  recommend  scoping  small  subsystem-level  domains, acknowledging
       that systems will later be assembled from assets spanning several domains.



In the above scenarios, the need for the multi-domain interoperability architecture provided by IE
cannot be overstated.


On the other hand, many enterprises adopting IE have considerable variation among functionally
similar systems,  the objects within them,  or the environments in which they are developed and
operate.   The  DA  approach  to  control  and  management  of  this  commonality  and  variability  is


                                                        Burdick- 4


potentially invaluable to such organizations.  Following are several scenarios showing the need for
a DA perspective in traditional IE arenas:



    fflLarge  enterprises  often  have  decentralized  operations, with  significant  distribution  of, and
       consequent variability among, core functions. Frequently, they also have decentralized data
       processing  responsibilities,  with  heterogeneous  system  and  application  hardware,  software,
       development processes and standards, etc.


    fflScores  of  similar  MIS  applications,  and  even  similar  enterprise  models,  are  "developed  to
       spec" by external companies for whom such work constitutes a line of business.


    fflEven less complex organizations may discover that many of the entities of interest to different
       functions  are  actually  variants  of  the  same  object  (e.g.  Customers,  employees,  suppliers,
       contractors, affiliates, etc. are all, potentially, variants of "person"; in some cases, it may be
       important that they are occasionally the same person.  Reuse of the more generic concept
       "person" offers both potential definitional and information value.)



In all of the above examples, the adoption of DA to manage the reuse of commonality and optimize
the variability among the systems and environments would prove invaluable.



2.5     DA and IE: The Wedding



The good news is that organizations recognizing the need for both DA and IE do not have to do
double work to adopt both disciplines. Because some of their objectives and methods overlap, and
others are complementary,this interdisciplinary marriage can be accomplished relatively easily.  The
marriage will work on an organizational and management level because both disciplines examine
similar information, pose many similar questions, and employsimilar methods and processes.  They
both recommend the development of similar organizational frameworks and infrastructures, require
similar planning, training and expertise, and require similar committed participation of many of
the same stakeholders.


The marriage will also work on a technical level because b oth DA and IE modeling and architec-
ture  development  activities  employ similar  structures  and  processes  to  partitioning  information,
albeit with different emphases. Both DA and IE systematically examine and partition information
about the full life-cycles of multiple systems (or functions),decomposing and classifying, identifying
commonality and necessary variability, and eliminating unnecessary redundancy.


Although other techniques are also usable, specialization analysis and decomposition analysis are
two orthogonal techniques that,when combined, effectively support both the IE and DA partition-
ing process.


DA is primarily concerned with extending or tailoring reusable assets to form variants of similar
systems.  Therefore,  the primary metaphor and partitioning mechanism of DA models is the gen-
eralization/specialization hierarchy.  Nevertheless,decomp osition is used, by some DA approaches,
to model the context of operation for systems within a domain.  It is alsoused to identify simi-
lar sub-structures within the domain (for feature comparison and component-based reuse), and to
model the topology of the structural and dynamic relationships among them.


IE is primary concerned with combiningreusable asset components to form interoperating systems.
Therefore, the primary metaphor and partitioning mechanism of IE mo dels isthe decomposition/


                                                        Burdick- 5


aggregation hierarchy.  Nevertheless,IE may occasionally employ specialization analysis to identify
and partition functional and structural variants as required by stakeholders representing different
user (i.e. functional) organizations and life-cycle stages.


IE  and DA  techniques  are  best  combined  by  combining  their  scopes  and  primary  partitioning
mechanisms, starting with their respective planning stages.  In this stage, a large problem space
can be defined, consisting of multiple interop erating system families.  This space can be partitioned
into  a  high-level  architecture  of interrelated  components.  Each  component  known  to  have  vari-
ants may be partitioned, in turn, into high-level specializations.  Single components (or groups of
several interrelated components) can be identifiedand prioritized as candidates for more detailed
follow-on project stages.  In these follow-on project stages, each partition (whether component or
specialization) can be re-partitioned as required into lower-level components and specializations.
IE techniques can be used to model the components, and DAtechniques can be used to model the
specializations.  The high-level architecture can be used to coordinate the work of these projects,
and to integrate their results into a growing asset base from which interoperating system variants
will be composed.



2.6     DA and IE: The Church



Together with inheritance, specializationand aggregation hierarchies form the foundations of both
semantic modeling and object-oriented (OO) modeling. Both DA and IE models and architectures
can be fully represented using semantic networks and ob ject-oriented modeling techniques.  These
scalable, versatile modeling techniques are useful for improving the precision of both DA  and IE
models and optimizing the reusability of their resulting asset bases. They are equally applicable to
a wide spectrum of problem spaces, and maintain consistent structures and representations across
the complete system life-cycle.  They can be combinedto represent specialization-based reusable
structures  in  models  and  architectures, and  to  implement  those  same  structures  in  code.  For
these  reasons  (as  well  as  so  many  others  that  another  paper  could  be  written  on  this  subject),
these techniques are logical, if not ideal, candidates for DA and IE integrated modeling and asset
building projects.



2.7     DA and IE: Happily Ever After?



The marriage of DA and IE seems to fulfill the quest for planned,  managed,  optimized reuse as
neither  can  do  alone.  These  two  disciplines are  not  only  orthogonal  but  complementary.  They
have common ancestry and similar backgrounds.  Each seems supportive of the other's objectives.
Furthermore, each seems designed to fill methodological gaps left by the other. Like any marriage,
theirs will require work to truly achieve a union.  However, if both parties commit to this union,
they stand a good chance of marital success. Their children should turn out to be the high quality
efficiently produced software we have been seeking.



3      Comparison



Several domain analysis approaches (notably KAPTUR[1 ] and GTE's DSSA [6]) develop rigorous
IE-like topological architectures,but only within a single domain. Some domain analysis approaches
stress the need for domain planning, but they do not require or even recommend rigorous modeling



                                                        Burdick- 6


to scope and architect the boundaries of multiple interrelated domains [2 , 3].


Conversely,as IE adopts a more object-oriented approach to modeling [7] it is starting to pay more
attention to supporting functional variability.  However, this rarely extends to support for envi-
ronmental variability, let alone modeling of variation in systems engineering methods and system
architectures themselves.  Furthermore, IE  does not yet include a formal approach to reusing its
own models on subsequent similar projects, and does not describe how to builda library describing
the taxonomic commonality and variability among such models.


In short, I am not acquainted with any literature describing truly comparable approaches, or any
applications of such approaches.  If anyone else has done any significant work in this area, I am
most anxious to learn about it.



References



[1]  S. Bailin, "Kaptur: Knowledge acquisition for preservation of tradeoffs and underlying ratio-
     nale," tech. rep., CTA Inc., Rockville MD.


[2]  "Stars reuse concepts volume 1 - conceptual framework for reuse processes (cfrp) version 2.0.
     stars-uc-05159/001/00," tech. rep., Electronic Systems Division, Air Force Systems Command,
     USAF, HanscomAFB, MA., Nov. 1992.


[3]  "Organizational  domain  modeling  (odm)  volume  1  -  conceptual  foundations,  process  and
     workpro ducts descriptions  version  0.5.  unisys  stars  informal  technical  report,  stars-uc-
     15156/024/00,"tech. rep., Electronic Systems Division, Air Force Systems Command, USAF,
     Hanscom AFB, MA., July 1993.


[4]  J. Martin andJ. Odell, Development Coordination Handbook:  JamesMartin & Company. James
     Martin & Company (proprietary), 1991.


[5]  J. Martin, Information Engineering, A Trilogy. Prentice Hall, 1990.


[6]  "Domain specific softwaare architectures, command and control, domain model report,cdrl clin
     0006," tech. rep., GTE, Chantilly VA., May 1993.


[7]  J. Martin andJ. Odell, Object Oriented Analysis and Design. Prentice Hall, 1992.



4      Biography



Robin Burdick has been a Staff Engineer on the Unisys Corporation STARS Reuse team in Reston
Va.  since December 1992.  During her 16 year career, she has worked in all phases of the MIS life-
cycle, primarily as a consultant andtechnology transfer agent. Her IE responsibilities have included
project management, information strategic planning, business area analysis, business system design
and development, information asset management, and methodology development. Other respon-
sibilities have included testing and quality assurance, end-user support and training, information
center  coordination, software  configuration  management, and  data  administration.  Throughout
her varied career, she has specialized in discovering and improving methods to deliver efficiently
developed maintainable flexible software that supports b othanticipated and ad-hoc enterprise-wide
collaboration.  Ms.  Burdick holds a BA cum laude from the University of Pennsylvania.



                                                        Burdick- 7