Practical Ontology for Enterprise Data Management

An enterprise needs to know
what data they own,
who uses it,
when it is updated,
where it is stored and used,
why it is useful.

Transcript

1. Practical Ontology for Enterprise Data Management 5 W's: An enterprise needs to know what data they own, who uses it, when it is updated, where it is stored and used, why it is useful. Tuesday, November 29, 2011 As a methodologist and software engineer, I’ve designed CASE tools that collect and impose organization on meta-data at all levels of detail. As a enterprise architect, I’ve worked in an environment that uses planning-level data. In a planning context, you need a method for quickly characterizing the problem space at the enterprise level. I’ve stumbled on to a way to do that. But first, for orientation, you can’t go wrong thinking about the journalist’s 5W’s. When we are collecting data about Enterprise’s data, we need to know what . . ., who . . ., when . . ., where . . ., and why . . .
2. Practical . . . Ontology Practical  Delivers value  Easy to use Ontology  What exists  Relationships Scope: Enterprise – produces a set of products and services for a specific market / constituency Tuesday, November 29, 2011 Here are my short definitions of the words practical, ontology, and enterprise.
3. Simple Technique The message is the feature. Everything follows from that. Tuesday, November 29, 2011 Here is the essence of my working method. If you don’t remember anything else I say today, just remember “The message is the feature.” Everything else follows from that.
4. The message is the feature.  Generally, enterprise ITS organizations spend most of their resources integrating purchased components, not building them.  Business processes communicate by sending messages.  If you analyze those messages, you discover almost everything about the data. Tuesday, November 29, 2011 Why do I say “The message is the feature.” ??? I work in a corporate ITS organization. In that context, we rarely produce software products. We mostly work on integrating products that we purchased. But, what does that really mean? Business units communicate with each other by sending messages. If you analyze that message traffic, you discover almost everything you need to know.
5. Three Kinds of Message  Request – Response : Work Order Please deliver cake to customer.  Question – Answer : Query What is order’s delivery-address?  Publish – Subscribe : Notice Oven has reached preheat-temperature. Tuesday, November 29, 2011 At the most basic level, there are just three kinds of message. Request - Response . . . Whether it is called a purchase order, work ticket, job ticket, reservation, or whatever; in essence it is a work order request that some product or service be done or delivered. Question - Answer . . . One business unit is requesting data from another business unit that is the custodian of that data. Publish - Subscribe . . . The business unit that is the authorized observer announces a business event. It “publishes” it. Other units that have an interest in that kind of event may “subscribe” to those announcements.
6. Request – Response :  What = What action is requested? (Write English sentence.)  Who = Actor requesting, actor responding.  Where = Components (are proxies for actors)  When = Task Delegation / Hand-off  Why = Business Process Workflow Tuesday, November 29, 2011 The five W’s may be refined according to the type of message. In every case, you should write the message out a a well-formed English sentence. (Of course, if your organization works in some other language, you should use that language.) For example: The who should relate to the role or actor that sends and receives the message. The where should relate to the computer applications or services that are acting as the electronic proxies for those actors. The when and why should relate back to a workflow. The why is the workflow -- At “run time” the work flow will typically be triggered by a higher-level “master” work- order. The task will usually represent a delegation of some work from one organization to another.
7. Question – Answer :  What:  What is the question? (Write it in English)  What is the expected form of the answer?  Who = Client is asking System of Record  Where = Components (proxies for actors)  When and Why:  Details needed for operation (task in workflow)  Details aggregated into metrics Tuesday, November 29, 2011 For the “Question - Answer” message, the most important fact is the “who” -- Who is the “system of record” for the data involved?
8. Publish – Subscribe :  What = Business Event Fact (Write it in English)  Who = Who publishes? Who needs to know?  Where = Components that proxy for who.  When = Other actor needs to know:  Asset Changes  Account Changes  Outages  Work started / completed / suspended  Why = Audit / Tracking (Metric) / Trigger Tuesday, November 29, 2011 For “Publish -- Subscribe” the you want to know who is responsible for publishing. All kinds of business events need to be published. Don’t confused data events with business events, the data got changed for a reason. The business event is the reason, and that is what you want to capture.
9. Five Message H's: How . . .  How often = frequency of message  How fast = response time needed  How long = record retention period  How much = Mega / Giga / Tera / Peta – Bytes  How do:  How protected = encryption / access control  How transported = infrastructure used  How formatted = XSD / . . . Tuesday, November 29, 2011 The operations folks are more interested in the five H’s rather than five W’s. Oh, I cheated. The “How to do it?” question breaks down into several other questions. As you are analyzing messages, you will need to pick up answers to these questions as well.
10. Message ==> Nouns ==> 1.Write the message out as a full sentence. 2.Underline the nouns. 3.Analyze the nouns: Each noun refers to . . .  Entity: Identifiable / Countable  Entity Attribute: Describes some entity.  Attribute Categories: Example: Color Green  Entity-Owned Collection: Set, Bag, or List of . . .  Entity is defined by its supertypes and attributes Tuesday, November 29, 2011 Here is the simple technique. This is “Object Oriented Analysis 101”. There are three steps: One: Write the message out as a complete sentence. Two: Underline the nouns. Three: Figure out that the noun is referencing using entity-relationship concepts.
11. Entity Facts  What is the operational meaning of a data record?  Who  . . . is entity custodian? (business process)  . . . has access to which fields?  Where is entity record? (system of record)  When is the entity data changed? (life-cycle: business events)  Why is it useful? (ROI / ROA)  Clients that query  Business metrics derived  Compliance with rules / regulations / best practice Tuesday, November 29, 2011 In the noun side of the ontology, you focus on the nouns that refer to entities.
12. Message ==> Capability  Request – Response ==> Ability to provide a service / product  Question – Answer ==> Ability to interpret the query and answer it  Publish – Subscribe ==> Publisher is qualified observer . . . (sufficient for an internal notice) ==> Publisher is authority for that event data . . . (necessary for wider audience) Tuesday, November 29, 2011 You can analyze the message content to discover the capabilities that are implicit in the messages. Obviously, if a business unit is requesting a product or service from another unit, the other unit is expected to have the capability of producing that product or service.
13. Capability ==> Function / Feature  What capability?  User Story / Use Case  Given . . . When . . . Then . . .  Who = Which business process provides?  Where = Which application / component provides?  When = Business Process Task (business event) that requires capability  Why = Business benefit (faster / better / cheaper) Tuesday, November 29, 2011 Going somewhat beyond the message, you can identify the function required. These might go into a business architecture or technical architecture.
14.  Structured English (natural language structured for processing)  SQL – Data Description Language  Interface Description Languages  CORBA IDL  Java Interface declaration / equivalent in language X  Web Service Description Language (WSDL)  Business Process / Workflow Description  Business Process Modeling Notation (BPMN)  Business Process Execution Language (BPEL)  Miscellaneous XML  XML Schema Document (XSD)  Web Ontology Language (OWL)  Resource Description Framework (RDF)  ALICE (Chat-Bot NLP: translate queries to standard form) Notations Tuesday, November 29, 2011 The nice thing about standards is that there are so many to choose from. The not so nice thing is that information is often lost or even garbled in the process of translating from one notation to another. I prefer to work in structured English, it has the advantage of flexibility and being both human-readable and machine-readable. And, I believe, there is less information loss.
15. Examples in Hum • Hum is not a product. It is an experiment. • Open source - written in Smalltalk. • Examples to show basic concepts. • Point is that you can do this kind of thing using structured natural language as the notation. • 5x8 cards will work almost as well Tuesday, November 29, 2011 I am going to demonstrate the ideas I’ve been talking about in a structured English notation. The particular notation that you use does not really matter. The main point is that you have a way to capture different kinds of business process knowledge. You also don’t need an expensive tool. 5x8 cards will work almost as well as most of the meta-data systems that you might buy.
16. Plan Tree Goal: <imperative statement> Post-Condition: <assertion statement> Preconditions: • <assertion statement> • <assertion statement> Action: • <role> : <imperative statement> Each of these statements indicates a message. Tuesday, November 29, 2011 This is a structured English notation for defining plans. You can use this notation to identify work that may proceed in parallel workflows. If you diagram this, you get a kind of precedence chart or state-transition diagram.
17. Plan Tree - Example Goal: Bake a cake according to recipe. Post-Condition: Cake is baked per recipe. Preconditions: • Oven is at preheat-temperature per recipe. • Cake batter is in a prepared cake pan. Action: • Cook : Bake in oven for bake-time given in recipe. Tuesday, November 29, 2011 Here is an example. The nouns are underlined. A syntax analyzer would warn that some of the nouns have no antecedent in the post-condition. You can take the algebra out of a programming notation, but you cannot take the programming out.
18. Role-Action : Procedure Role: <Role-Name>. Action: <imperative statement> • <imperative Statement> • <role-name> : <imperative statement> • If <condition>: • . . . • ... Tuesday, November 29, 2011 This is a structured English notation for defining procedures -- a sequence of tasks that are assigned to a single role.
19. Role-Action : Example Role: Cook. Action: Bake in oven for bake-time given in recipe. • Open the oven door. • Place the pan in the oven. • Close the oven door. • Oven: Bake for the bake-time given in recipe. Message delegates step to automated oven (role). Tuesday, November 29, 2011 Here is an example of that notation. Note that the primary actor can delegate a task to another role.
20. Noun Relations Dictionary: <title indicates context> • A <noun> is a <noun>. • <noun> attributes include <noun>, . . . • <noun> categories include <noun>, . . . • <noun> contains a <collection> of <plural noun>. • . . . Tuesday, November 29, 2011 Structured English become executable once the nouns are known. In natural language, nouns represent variables that are assigned values at run-time. This notation provides the means of identifying the nouns and their relationships.
21. Noun Relations - Example Dictionary: Baker’s vocabulary. • A mixing-bowl is a container. • Recipe attributes include temperature, duration, . . . • Cake-type categories include layer-cake, bunt-cake. • Recipe contains a list of steps. • A temperature is a measurement. Yellow nouns above could be in a base vocabulary. Tuesday, November 29, 2011 Here is an example. Some nouns may belong to a base vocabulary. The base vocabulary contains terms that are common to all business situations. The base could also be extended to include terms that are common to a given industry.
22. Base Vocabulary Dictionary: Base vocabulary. • A weight is a measure. • Measure attributes include quantity, precision, unit-of-measure, method. • Unit-of-measure categories include Wh, VAh, V. • Wh is shorthand for Watt-hours. • . . . (Could be open source like OpenCyc.) Tuesday, November 29, 2011 In the business world, a number is not a mathematical abstraction. It always represents a measurement with a unit of measure and some limited precision. This illustrates one of the differences between computer programming and business programming. In computer programming, someone would be concerned with how this concept would be represented in the hardware. In business programming, we simply require that the run time will do the right thing.
23. Dialogs and Use Cases Dialog: <arbitrary title giving overview>. Context: <name-of-context for disambiguation>. (Vignette -- starts with a specific user statement) • U: <user statement> • S: <system response> • <role> : <action statement> Tuesday, November 29, 2011 This is a structured English notation for defining dialogs, protocols, and use case scenarios.
24. Dialog - Example Dialog: User authentication. Context: New session. U: [User arrives with cookie.] S: Hello [user name]. What would you like to do? Context: Expect user request. U: I want to pay my bill. S: Your balance is [user account balance]. Would you like to pay by credit card or PayPal? Tuesday, November 29, 2011 Here is an example. This basic idea is that it reads like a stage play. “He said” . . . “She said” plus some direction about what is happening in the background. I derived this notation from a chat-bot notation called “ALICE”. In essence, this part of the system would execute like a chat-bot. But, with some refinement, it can be used as any kind of event-driven production system. In the context of an ontology, this notation provides a way to capture this kind of message exchange.
25. Summary • Enterprise ITS needs to know what data it owns and who uses it, when, where, and why. • Enterprise actors communicate with messages. • By analyzing message nouns and context, we discover ontology content. • Structured English provides human readable information that is also machine readable once the nouns are identified. Tuesday, November 29, 2011