Adopting the Practice of Enterprise Analysis in
a Mid-Sized Company
Mary Burns Furr
Adaptis, Incorporated, 1100 Olive Way, Seattle, Washington 98101, USAmbfurr@acm.org
Abstract
This case study describes initial problems faced by
Adaptis, a mid-sized company, when it adopted thepractice of enterprise analysis. The first problem wasto distinguish enterprise analysis from the practice ofdomain or business analysis. The second problem wasto create straw enterprise models for collaborativemodeling that were well-formed and, to the extent
practicable, based upon stable industry standards. The
study reviews approaches for solving these problems
and how they were applied. The results show that a
mid-sized company can successfully adopt the valueadding practice of enterprise analysis.

1. Introduction
Adaptis is a business process outsourcer (BPO) of
administrative services for healthcare insurance plans.
The range of services Adaptis supports includes claims
processing, eligibility and benefit management,
medical management, reimbursement and financial
services, customer service, and decision support. The
company, founded in 1996, now has over 150
employees with business operations in multiple
locations, including offshore.
The company’s success is based on personalized
service, compliance with laws and regulations, meeting
quality of service and service level agreement targets,and effective use of people, knowledge, andtechnology.
To successfully deliver outsourced services in a
distributed processing environment, Adaptis must
understand both its customers’ business domains andthe business domains that are central to Adaptis’ own
core competencies: operations management andsupport, professional services, account management,
database services, networking, security, systemadministration, product management, and systemdevelopment and integration.
In 2004 Adaptis created an enterprise analyst
position to facilitate building intangible corporate
assets that foster competitive edge. The first-year goals
for the enterprise analyst were to prepare theorganization to use enterprise analysis effectively andto create straw models that would jumpstartcollaborative modeling of the Adaptis enterprise.
This case study describes Adaptis’ first-year
experiences with the practice of enterprise analysis. It
is structured as follows: section 2 describes initialproblems faced in adopting enterprise analysis, section
3 describes sources investigated for problem-solving
guidance, section 4 presents the problem-solving
approaches applied and the results, section 5 presents
future and related work, and section 6 presents
conclusions.

2. Problems Faced
2.1. Defining the practice of enterprise analysis
A need of stakeholders (parties impacted by the
success or failure of the practice of enterprise analysis
at Adaptis) was to understand the differences between
enterprise analysis and other types of analysis, such as
domain analysis or business analysis. The terms
enterprise, domain, and business are often not definedwhen used in literature or conversation. Another needof stakeholders was to understand the differences
between enterprise analysis and enterprise architecture.

2.2. Developing straw models
The optimum means for eliciting requirementsfrom subject matter is a collaborative workshop.
However, in a lean and efficient service organization

that solves complex problems within short timeframes,
subject matter experts are scarce resources unable todevote extended periods of time to modelingworkshops. So, while enterprise analysis was viewed
positively by stakeholders, day-to-day operations wereviewed as more urgent and important. The enterpriseanalysis approach had to manage within this real-life
constraint. Straw models [1] were viewed as a way toengage stakeholders and discover which enterpriseanalysis techniques and assets would be of value.
A significant challenge in developing the straw
models was finding practical advice, examples, andbest practices that addressed the specific practice ofenterprise analysis.
Another challenge was locating industry
conceptual models and ontologies at an appropriate
level of abstraction for enterprise modeling.
As understanding of the environment in which
Adaptis interacts increased, it became apparent that astable enterprise model would require a higher level ofabstraction than anticipated. It was then necessary to
explain to stakeholders why a higher level ofabstraction would add value.

federation, purpose, role, resource, process, policy,
and accountability are the focus of the enterprise
viewpoint, whereas the concepts of things, actions, andrelationships (described by invariant properties andschemas) are central to the information viewpoint [3,4]. The following points [1] were perceived to be ofparticular importance to the practice of enterpriseanalysis:• A complete specification consists of all five
viewpoints, but not all viewpoints in aparticular specification may have properties
with interesting semantics.
• Different viewpoints are not more general ordetailed representations of the same concepts.
• Abstraction levels are used to express aviewpoint at different levels of detail.
• Concepts specific to a viewpoint, as definedby the RM-ODP, may be used in otherviewpoint specifications when it is useful to
do so.
• All viewpoints expressed in particularspecification should be consistent.

3. Sources Investigated for Guidance

3.3. Zachman Framework for EnterpriseArchitecture

3.1. Dictionaries
Interpretation and application of guidance found in
the professional literature was difficult because thesame terms were used by different authors andauthorities to convey different concepts. Dictionaries
were consulted when such a situation presented itself.

3.2. Reference Model for Open Distributed
Processing (RM-ODP)
The RM-ODP, a framework for the specificationof ODP systems, was explored as both a means to
distinguish between the kinds of analysis performed
within the organization and, as suggested by [2], ameans to “bridge communication gaps between
stakeholders.”
The framework comprises five viewpoints:
enterprise, information, computational, engineering andtechnology. The viewpoints specify different kinds ofstakeholder interests (e.g., business requirements,
information modeling, software design, system design,
system installation and integration) [1]. Each viewpoint
uses a viewpoint language to specify the systemcharacteristics of interest to the owners or users of thatviewpoint. For example, the concepts of community,

The Zachman Framework [5] is, according to [6],“a classification schema used to organize an
enterprise’s artifacts, thinking, reasoning, andcommunicating among the participants of theenterprise.” The Zachman Framework describes anenterprise architecture using two independent aspects[7]:• perspectives that frame theview of abusiness, a situation, an opportunity, or asystem• dimensions that specify a perspective based on
the basic interrogatives what, how, where,
who, when, and why
The planner and business owner perspectives of
the Zachman Framework were perceived to be the mostuseful for the practice of enterprise analysis. The
contextual view of the planner considers the complete
problem area relative to a single perspective. The
conceptual view of the business owner considers theboundary and area of concern of a project or enterprise[6].

3.4. The Open Group Architecture Framework
Version 8 (TOGAF 8)
TOGAF 8 is an industry standard architecturedevelopment method and resource base that has beendeveloped by members of The Open Group
Architecture Forum. A core part of TOGAF 8 is theArchitecture Development Method (ADM), an
approach for developing a description of an enterprisearchitecture that meets the business needs of theenterprise [8]. Another core part of TOGAF 8 is theEnterprise Continuum, a repository concept thatfacilitates use of assets such as models and patterns
during the process of developing an enterprisearchitecture. A third core part of TOGAF 8, theResource Base, is a set of resources such as guidelines
and templates that can help implement the ADM [9].

3.5. The Object Management Group Model
Driven Architecture (MDA)
MDA is a systems development approachsponsored by the Object Management Group (OMG).
MDA leverages the power of models by separating
their use from specific development methodologies andspecific technologies so as to preserve “a company’s
core software assets in the constantly changing worldof information technology" [8]. MDA also uses
viewpoints, which are described as a technique for
abstraction using a selected set of architecturalconcepts and structuring rules to focus on particularconcerns within a system. Of particular relevance to thepractice of enterprise analysis are the concepts ofcomputation independent viewpoint and Computation
Independent Model (CIM). A CIM [8]:• focuses on the business environment in whicha system will be used
• is commonly referred to as a domain or
business model• is oriented to the stakeholders of the system• helps understand a problem and share
vocabulary
Other points about the MDA that are relevant to
the practice of enterprise analysis are: a CIM may
consist of more than one model; a CIM typicallycommunicates the RM-ODP enterprise or information
viewpoint; and OMG envisions developing standard
domain models for industries (e.g., healthcare) [8].

3.6. Ontologies
An ontology is a shared conceptualization of aparticular domain that allows people to reason about
concepts and to derive mappings for establishing
semantically correct communication channels [10].
Reviews of the ontology literature were investigated to
discover ontologies of enterprise concepts [10, 11, 12].

3.7. Industry-Specific Standards
Standards for specific industries were also
investigated to discover enterprise-level concepts.
Standards for clinical and administrative healthcare
data are developed by Health Level 7 (HL7), a
standards development organization accredited by theAmerican National Standards Institute (ANSI) [13].
Healthcare insurance data standards for the exchange
of information for healthcare administration aredeveloped by the ANSI Accredited Standards
Committee (ASC) X12 [14]. Other sources investigated
are the works of the XML.org Insurance and
Healthcare focus groups [15] and the OMG Healthcare
and Insurance domain task forces [16, 17]. The North
American Industry Classification System (NAICS) wasinvestigated as a means to conceptualize the industries
with which Adaptis interacts [18].

3.8. Off-the-Shelf Models
Two kinds of off-the-shelf models were
investigated as a potential source of enterpriseconcepts: universal data models and process maps.
According to [19], a universal data model is “a genericor template data model that can be used as a building
block to jump-start development of the corporate data
model, logical data model or data warehouse data
model.” Healthcare, insurance, and professional
services universal data maps [20, 21] and SAPBusiness Maps for healthcare and insurance [22] wereof particular interest for this effort. Another source
investigated was the Process Classification Framework(PCF) developed by the American Productivity &Quality Center (APQC). The PCF is a high-level,industry-neutral enterprise model that allows
organizations to view activities from a cross-industry
process viewpoint [23].

4. Problem-Solving Approaches andResults
4.1. Approach to define the practice ofenterprise analysis
To sort out how the practice of enterprise analysis
should be integrated with other organizational
activities, such as enterprise architecture, domain
analysis, and business analysis, the following questions
were addressed.
What is an enterprise? A definition of the term
enterprise that reflects the environment in which a
BPO operates is: A group of people organized for aparticular purpose to produce a product or provide aservice [6].
What is a domain? The term domain is often usedwithout formal definition, which implicitly assumes
readers have a common understanding of its meaning.
In practice, it is difficult to reach a common
understanding of the term when it is used in the context
of modeling. The following dictionary definitions
reflect the two primary uses of the term found in theliterature investigated:• a sphere of knowledge, influence, or activity[24]• a knowledge domain that one is interested inor is communicating about [25]The first dictionary definition connotes theconcepts of realm and dominion. An example of thisuse is found in [26], where a domain is defined as a“set of objects, each of which is related by acharacterizing relationship to a controlling object.”
The second dictionary definition connotes aparticular body of knowledge and associated semantics.
An example of this use is found in [27], where adomain is defined as “an area of knowledge or activity
characterized by a set of concepts and terminology
understood by practitioners in that area.”
Although a quick Internet search revealed many
uses of the term, it was concluded that, within thecontext of modeling an enterprise or business (incontrast, for example, with modeling a data base or
network), the term domain connotes a realm of
influence or a specific body of knowledge.
What is a business? The term business is also
often used without formal definition. The following are
two definitions found in dictionaries:• a usually commercial or mercantile activity
engaged in as a means of livelihood [24]• a commercial or industrial enterprise and thepeople who constitute it [25]The second definition fails to distinguish abusiness from an enterprise in a meaningful way. For
the purpose of establishing context for the practice ofenterprise analysis, the first definition best
distinguishes a business (i.e., a means of livelihood)from an enterprise (i.e., a group of people organized toachieve a purpose).
What is the difference between enterpriseanalysis, domain analysis, and business analysis?
The following definitions clarified to stakeholders thedifferences between these terms:• Enterprise models specify the purpose,processes, entities, and organization of one ormore enterprises [28], and creating enterprisemodels is the practice of enterprise analysis.
• Domain models specify the important classes(i.e., concepts, including entities andprocesses) and vocabulary of a knowledge
domain [27], and creating domain models is
the practice of domain analysis.
• Business models specify the business andnon-physical system requirements of a
specific customer [27], and creating businessmodels is the practice of business analysis.
The above clarification of analytical viewpoints
and model content was helpful, because, in practice, avariety of positions (e.g., business architect, businessanalyst) routinely perform one or more of the above
analyses depending upon the needs of a particular
project. Clarification aligned efforts and prevented
duplication of effort.
What remains problematical is defining level ofabstractions to guide the universe of discourse [29] ascustomer business requirements are refined during asystems development project. The TOGAF 8 concept
of Enterprise Continuum [9] and mappings between the
RM-ODP, TOGAF 8, MDA, and Zachman Framework[30, 31] will be investigated to address this challenge.
How is enterprise analysis different thanenterprise architecture? The following definitions
clarified to stakeholders the differences between theseterms:• Enterprise analysis produces high-level, nonphysical descriptions and models of anenterprise's motivations and strategy forsurvival; industry entities, events, processes,
standards, and laws; industry businesspatterns, collaborations and use cases; and an
enterprise’s structure, including geographic
sites and major communication nodes. The
knowledge formalized by enterprise analysis
aligns and informs marketing, product•management, architecture, business analysis,
and system design activities.
Enterprise architecture is the process ofreasoning about the continual needs ofintegration,alignment,change,andresponsiveness of the business to technology
and to the marketplace through thedevelopment of models and diagrams [6].
Enterprise architecture builds the foundationneeded to survive and adapt to present andfuture business challenges.

4.2. Approach to develop straw models
A BPO system may interact with systems from
more than one line of business, more than one
customer, more than one regulatory jurisdiction, andmore than one industry. To facilitate flexibility and reuse, a BPO needs generic models that can beinstantiated to specify the system’s interactions withina particular environment. Creating these kinds ofgeneric models requires mapping and harmonizing
concepts and semantics across a wide spectrum oforganizations. For example, each customer of a BPO
has an enterprise viewpoint, each industry in which a
BPO interacts has a generic enterprise viewpoint, andthe BPO itself has an enterprise viewpoint.
The following describes the efforts taken todevelop straw models, and in the process of doing so,achieve the understanding expressed in the preceding
paragraph.
Getting started. The first step was to get gain
perspective of the problem area. The Zachman
Framework helped establish context and, whencomplexity began to cloud the mind, keep focused on
the basic interrogatives of what, how, where, who,
when, and why. Creating lists [6] of things to describe
the planner perspective, though simple in practice, wasa powerful tool.
Discovering stable conceptualizations. Highlevel, stable industry models helped discover and nameenterprise concepts. Particularly useful were NAICS,
universal data and process models, the PCF, SAPBusiness Maps, and ASC X12 standards for electronic
data interchange. Although most industry ontologies
and domain models were viewed as too immature forpractical application during the timeframe of this casestudy, they will be investigated again as the straw
models are verified and refined.
Finding a useful level of abstraction. The RMODP enterprise viewpoint provided insight on how tocreate well-formed, stable system specifications of the
Adaptis enterprise and the multi-industry environment

in which it exists. Compelling arguments about thepower of abstraction to manage complexity were
helpful in persuading stakeholders to view enterpriseanalysis as an investment rather than a cost [1, 32, 33,34]. The following describes the pragmatic course
charted to develop straw models:• To model the federation of communities withwhich Adaptis interacts (including entities,
policies, relationships, and collaborations),
produce an RM-ODP enterprise viewpoint
specification.
• To specify an internal viewpoint of the
Adaptis enterprise, produce a set of lists tospecify the planner perspective of the
Zachman Framework.
• To specify the business owner viewpoint,
produce UML models suggested by mappingsof TOGAF 8 and MDA to the Zachman
Framework where they add significant value
to the enterprise architecture.
• To harmonize industry concepts andprocesses, produce domain models thatprovide significant value to development
projects.

5. Future Problems to Be Addressed
5.1. Modeling business events
The term business event is a first-order concept in
day-to-day conversation with business owners.
Conceptualization of business events, decisions, andevent response processes is necessary for effective
specification of the enterprise, system services, andworkflow management requirements [35, 36, 37, 38,
39, 40]. Use of the RM-ODP viewpoints to model andcommunicate with business owners about businessevents will be explored (e.g., in the same vein thatevents are specified for the planner perspective using
the Zachman Framework).

5.2. Modeling product management concepts
Product management concepts such as product andmarketing feature need to be expressed and integrated
more effectively in specifications and models of the
Adaptis enterprise. The literature addressing the use of
domain analysis as a basis for product framework
design will be investigated to address this issue. An
approach for integrating the product management
concepts with the Zachman Framework, found in [41],will also be investigated. Patterns for specifying

product-related concepts, such as those found in [42],may also be helpful.

5.3. Solving wicked problems
The concept of wicked problems was proposed by[43] when, in the context of social planning, the wicked
nature of ill-defined design and planning problems wascontrasted with the relatively tame problems ofmathematics, chess, or puzzle solving [44]. A central
concept in solving wicked problems is issue. The useof issue-based information systems, therefore, is
proposed by [45] to track the issues and decisions madeduring the nonlinear process of solving a wicked
problem [46].
The reality of wicked problems became apparent
during an Adaptis project in which the possibility ofleveraging the knowledge formalized in the enterprisestraw models to improve access to the Adaptis
knowledge base was explored. When business analysts
were asked what of kinds information they need toperform their knowledge work more effectively, they
indicated their primary need was information about thehistory of a problem and the context and state ofrelated artifacts (e.g., issues raised, decisions made,what still needs to be done, cross-projectinterdependencies).
As a result of this needs assessment, it became
apparent that, to avoid making an existing information
overload problem worse when enterprise analysis
specifications and models are added to the Adaptis
knowledge base, the means to organize, relate, access,and maintain corporate knowledge must be
investigated. The use of RM-ODP concepts to model
this problem will be investigated. The TOGAF 8
concept of Enterprise Continuum may also be helpful.
An ontology for group memory [47] will be reviewed
as a basis for creating an Adaptis ontology andclassification scheme for specifications, models,designs, test cases, and procedures. Protégé-2000 [48],an open source ontology editor and knowledge baseframework, will be investigated as a tool to support thiseffort.

6. Conclusions
There was sufficient guidance available in thesources investigated to successfully initiate the practiceof enterprise analysis at Adaptis. It is expected thatevolution of industry frameworks, standards, andontologies will necessitate refactoring the initialmodels, even at the relatively stable enterprise-level of

discourse. The return on investment from enterpriseanalysis, however, is perceived to outweigh its cost andthe risk of failure.
Preparing the organization for the integration ofenterprise analysis has been a significant effort.
Applying organizational change management bestpractices [49] was helpful in this regard, andmanagement support was essential.

Acknowledgments
The support of Adaptis during this effort is deeply
appreciated. In particular, I wish to thank Jan Goetz,
Karen Storey, the Adaptis Product Development team,and the Adaptis Enterprise Architecture team.

References[1] H. Kilov, Business Models: A Guide for Business andIT, Prentice Hall PTR, 2002.
[2] H. Kilov, “Using RM-ODP to Bridge Communication
Gaps Between Stakeholders,” Proc. 1st Workshop on
ODP and Enterprise Computing (WODPEC 2004),
IEEE Digital Library, 2004.
[3] ITU-T Recommendation X.903|ISO/IEC 10746-3,
Information Technology - Open Distributed Processing Reference Model (RM-ODP): Architecture, ISO/IEC,
1996.
[4] ITU-T Recommendation X.911|ISO/IEC 15414,
Information Technology, Open Distributed Processing –Reference Model (RM-ODP): Enterprise Language,
ISO/IEC, 2002.
[5] J. Zachman, "A Framework for Information," IBM
Systems Journal, vol. 26, no. 3, 1987, pp. 276-292.
[6] O’Rourke, C., N. Fishman, and W. Selkow, Enterprise
Analysis Using the Zachman Framework, Course
Technology, 2003.
[7] Pereira, C. and P. Sousa, “A Method to Define anEnterprise Architecture Using the Zachman
Framework”, Proc. Fourth Symposium on Applied
Computing (SAC 2004), ACM Press, 2004.
[8] TOGAF ADM and MDA - Revision 1.1, The OpenGroup and OMG, 2005; http://www.opengroup.org/
cio/MDA-ADM/.
[9] TOGAF Version 8.1, The Open Group, 2003;
http://www.opengroup.org/architecture/togaf8-doc/arch/.
[10] P. Bertolazzi, C. Krusich, and M. Missikoff, “AnApproach to the Definition of A Core Enterprise
Ontology: CEO,” Proc. International Workshop on
Open Enterprise Solutions: Systems, Experiences, andOrganizations (OES-SEO 2001), Luiss Publications,
2001.
[11] V. Devedzic, “Ontologies: Borrowing from Software
Patterns,” intelligence, 1999, pp. 15-24.

[12] N. F. Noy and D. L. McGuinness, “Ontology
Development 101: A Guide to Creating Your First
Ontology,” Knowledge Systems Laboratory, 2001;
http://www.ksl.stanford.edu/KSL_Abstracts/
KSL-01-05.html.
[13] Health Level 7; http://www.hl7.org/.
[14] ASC X12; http://www.x12.org/x12org/index.cfm.
[15] XML.org; http://xml.org/.
[16] OMG Healthcare Domain Task Force;
http://healthcare.omg.org/.
[17] OMG Finance Domain Task Force; http://fdtf.omg.org/.
[18] U. S. Office of Management and Budget, North
American Industry Classification System: United States,
Washington: Government Printing Office, 2002.
[19] L. Silverston, “Is Your Organization Too Unique to Use
Universal Data Models?,” Data Management Review,
September, 1998; http://www.dmreview.com/
article_sub.cfm?articleId=425.
[20] L. Silverston, The Data Model Resource Book: A
Library of Universal Data Models for All Enterprises,
Vol. 1, Wiley, 2001.
[21] L. Silverston, The Data Model Resource Book: A
Library of Universal Data Models by Industry Types,
Vol. 2, Wiley, 2001.
[22] SAP Business Maps: When You're Going Somewhere
New, It Helps to Have a Good Map, SAP;
http://www.sap.com/businessmaps.
[23] Process Classification Framework, APQC;
http://www.apqc.org/portal/apqc/site/
content?docid=115313.
[24] Merriam-Webster Online Dictionary;
http://www.merriam-webster.com.
[25] UltraLingua English Dictionary;
http://www.ultralingua.net.
[26] ITU-T Recommendation X.902|ISO/IEC 10746-2,
Information Technology - Open Distributed Processing Reference Model (RM-ODP): Foundations, ISO/IEC,
1996.
[27] I. Jacobson, F. Booch and J. Rumbaugh, The Unified
Software Development Process, Addison Wesley, 1999.
[28] C. Marshall, Enterprise Modeling with UML: Designing
Successful Software through Business Analysis,
Addition Wesley, 2000.
[29] T. Halpin, Information Modeling and Relational
Databases: From Conceptual Analysis to Logical
Design, Morgan Kaufmann, 2001.
[30] D. Frankel et al., “The Zachman Framework and the
OMG’s Model Driven Architecture, Business Process
Trends, September, 2003; http://www.omg.org/mda/
mda_files/09-03-WP_Mapping_MDA_to_Zachman_
Framework1.pdf.
[31] Mapping the TOGAF ADM to the Zachman Framework,
The Open Group; http://www.opengroup.org/
architecture/togaf8-doc/arch/p4/zf/zf_mapping.htm.
[32] M. Cline, and M. Girou, “Enduring Business Themes,”
Communications of the ACM, May 2000, pp. 101-106.

[33] K. Bennett, and V. Rajlich, “Software Maintenance andEvolution: A Roadmap,” Proc. 22nd International
Conference on Software Engineering (ICSE '00), ACM
Press, 2000.
[34] M. Fayad, and A. Altman, “An Introduction to Software
Stability, Communications of the ACM, September
2001, pp 95-98.
[35] B. von Halle, Business Rules Applied: Building Better
Systems Using the Business Rules Approach, Wiley,
2002.
[36] J. Sowa, and J. Zachman, “Extending and Formalizing
the Framework for Information Systems Architecture,”
IBM Systems Journal, vol. 31, no. 3, 1992, pp. 590-616.
[37] D. Marca, and B. Perdue, “A Software Engineering
Approach and Tool Set For Developing Internet
Applications,” Proc. 22nd International Conference on
Software Engineering (ICSE '00), ACM Press, 2000.
[38] M. Cilia, and A. Buchmann, “An Active Functionality
Service for E-Business Applications,” ACM SIGMOD
Record, vol. 31, 2002, pp. 24-30.
[39] K. Taveter, and G. Wagner, “Agent-Oriented Enterprise
Modeling Based on Business Rules,” Proc. 20thinternational Conference on Conceptual Modeling,
Springer-Verlag, 2001.
[40] B. Daum, and U. Merten, System Architecture with
XML, Morgan Kaufmann Publishers, 2003.
[41] P. Ferdinandi, A Requirements Pattern: Succeeding in
the Internet Economy, Addison-Wesley, 2002.
[42] J. Arlow, and I. Neustadt, Enterprise Patterns and
MDA: Building Better Software with Archetype Patterns
and UML, Addison-Wesly, 2003.
[43] Rittel, H., and M. Webber; "Dilemmas in a General
Theory of Planning,” Policy Sciences, Elsevier
Scientific Publishing Company, vol. 4, 1973, pp 155169.
[44] Wicked Problems, Wickipedia; http://en.wikipedia.org/
wiki/Wicked_problems.
[45] H. Rittel, and D. Noble, “Issue-Based Information
Systems for Design,” Working Paper 492, The Instituteof Urban and Regional Development, University ofCalifornia, 1989.
[46] J. Conkin, “Wicked Problem Solving and Social
Complexity,” CogNexus Institute, 2003;
http://cognexus.org/wpf/wickedproblems.pdf.
[47] J. Vasconcelos, et al., “A Group Memory System for
Corporate Knowledge Management: An OntologicalApproach,” Proc. 1st European Conference on
Knowledge Management (ECKM’2000) Bled School ofManagement, 2000.
[48] Stanford Medical Informatics, “What is protégé?,”
protégé, Stanford University School of Medicine, 2005;
http://protege.stanford.edu/overview/.
[49] LaMarsh J., Changing the Way We Change: Gaining
Control of Major Operational Change, Addison-Wesley,
1995.