This session will delve into the step-by-step information gathering process and technical analysis that goes in to crafting an enterprise data model. Taxonology is where taxonomy modeling theory meets technology - and the sparks fly!
6. “The hierarchical classification of entities of interest
of an enterprise, organization or administration,
used to classify documents, digital assets and other
information”
-Wikipedia (Corporate Taxonomy)
10. Objects and Classes
• Objects are derived from classes
• Classes contain properties
• Classes can have one or more
subclasses
11. Objects and Classes
• Objects are derived from classes
• Classes contain properties
• Classes can have one or more
subclasses
{encapsulation,
instantiation,
inheritance,
specialization,
polymorphism,
canonicalization};
Taxonology:=
21. Getting Started
Tools and Techniques
• Questionnaire/Worksheet
• “Procs not docs”
• What are the documents that
start the process (i.e., input)?
• Who produces these documents?
• Data Dictionary and Glossary
• Document Matrix
22. Common Pitfalls
• Lean/Flexible
• Not all metadata is equal
• Used to search?
• Used for records/lifecycle
governance?
• Used for reporting?
• Used for workflow/process?
• Look for rigidity
• High-level properties can be data
typed liberally
23. Citizen Developers
“A citizen developer is a user who creates new
business applications for consumption by others
using development and runtime environments
sanctioned by corporate IT … today, end users
can build departmental, enterprise and even
public applications using shared services, fourth-
generation language (4GL)-style development
platforms and cloud computing services”
Source: Gartner, Citizen Developer Model
24. Eugene Stakhov, CRM, CDIA+
• Email: president@armanyc.org
• Phone: (909) CRM-GENE
Senior Solution Architect, IG
enChoice, Inc.
President
ARMA Metro NYC Chapter
crmgene @gstakhov
Editor's Notes
From a real world project that my colleague and I were working on years ago. We started out modeling a simple data flow process – there were supposed to be like 3 steps - and as more pieces of the architecture became known it morphed into this
This graphic illustrates an important concept in the reality of today’s information management landscape…The complexity of the various interrelationships, the countless moving parts that comprise a typical enterprise data ecosystem.
So let’s take a look now, at a high-level sample taxonomy for an insurance organization…
Starting at the top, the out-of-box Document class contains several key properties
The next level down is the first level of specialization … Enterprise Document class. Its key properties are bound by the organization & make sense within the context of the organization. Every single document, every single record within the company will have at least these properties…because they are inherited.
3rd level is where you start to get creative…How do you determine that next species of document? What do you use to tell the difference? This can get really interesting, a lot of choices here… This third level choice that you make is the basis of taxonomy design, and is the real meat of this discussion