Practical Ontology For Enterprise Data Management

Editor's Notes

• #2: As a methodologist and software engineer, I’ve designed CASE tools that collect and impose organization on meta-data at all levels of detail.\nAs 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.\nBut 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 knowwhat . . ., who . . ., when . . ., where . . ., and why . . . \n\n
• #3: Here are my short definitions of the words practical, ontology, and enterprise.\n
• #4: 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.”\nEverything else follows from that.\n
• #5: Why do I say “The message is the feature.” ???\nI work in a corporate ITS organization.\nIn that context, we rarely produce software products.\nWe mostly work on integrating products that we purchased.\nBut, what does that really mean?\nBusiness units communicate with each other by sending messages.If you analyze that message traffic, you discover almost everything you need to know.\n
• #6: At the most basic level, there are just three kinds of message.\nRequest - 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.\nQuestion - Answer . . . One business unit is requesting data from another business unit that is the custodian of that data.\nPublish - 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.\n\n
• #7: The five W’s may be refined according to the type of message.\nIn 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.)\nFor example:\nThe who should relate to the role or actor that sends and receives the message.\nThe where should relate to the computer applications or services that are acting as the electronic proxies for those actors.\nThe 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.\n
• #8: For the “Question - Answer” message, the most important fact is the “who” -- Who is the “system of record” for the data involved?\n
• #9: For “Publish -- Subscribe” the you want to know who is responsible for publishing.\nAll 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.\n
• #10: The operations folks are more interested in the five H’s rather than five W’s.\nOh, I cheated. The “How to do it?” question breaks down into several other questions.\nAs you are analyzing messages, you will need to pick up answers to these questions as well.\n
• #11: Here is the simple technique. \nThis is “Object Oriented Analysis 101”.\nThere are three steps:\nOne: Write the message out as a complete sentence.Two: Underline the nouns.Three: Figure out that the noun is referencing using entity-relationship concepts.\n
• #12: In the noun side of the ontology, you focus on the nouns that refer to entities.\n
• #13: You can analyze the message content to discover the capabilities that are implicit in the messages.\nObviously, 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.\n
• #14: Going somewhat beyond the message, you can identify the function required.\nThese might go into a business architecture or technical architecture.\n
• #15: The nice thing about standards is that there are so many to choose from.\nThe not so nice thing is that information is often lost or even garbled in the process of translating from one notation to another.\nI 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.\n
• #16: I am going to demonstrate the ideas I’ve been talking about \nin a structured English notation.\nThe particular notation that you use does not really matter.\nThe main point is that you have a way to capture different kinds of business process knowledge.\n\nYou also don’t need an expensive tool.\n5x8 cards will work almost as well as most of the meta-data systems that you might buy.\n\n
• #17: This is a structured English notation for defining plans.\nYou can use this notation to identify work that may proceed in parallel workflows.\nIf you diagram this, you get a kind of precedence chart or state-transition diagram.\n
• #18: Here is an example.\nThe nouns are underlined.\nA syntax analyzer would warn that some of the nouns have no antecedent in the post-condition.\n\nYou can take the algebra out of a programming notation, but you cannot take the programming out.\n
• #19: This is a structured English notation for defining procedures -- a sequence of tasks that are assigned to a single role.\n
• #20: Here is an example of that notation.\nNote that the primary actor can delegate a task to another role.\n\n
• #21: Structured English become executable once the nouns are known.\nIn natural language, nouns represent variables that are assigned values at run-time.\nThis notation provides the means of identifying the nouns and their relationships.\n
• #22: Here is an example.\nSome nouns may belong to a base vocabulary.\nThe base vocabulary contains terms that are common to all business situations.\nThe base could also be extended to include terms that are common to a given industry.\n\n
• #23: In the business world, a number is not a mathematical abstraction.\nIt always represents a measurement with a unit of measure and some limited precision.\nThis illustrates one of the differences between computer programming and business programming.\nIn computer programming, someone would be concerned with how this concept would be represented in the hardware.\nIn business programming, we simply require that the run time will do the right thing.\n
• #24: This is a structured English notation for defining dialogs, protocols, and use case scenarios.\n\n
• #25: Here is an example.\nThis basic idea is that it reads like a stage play.\n“He said” . . . “She said” plus some direction about what is happening in the background.\n\nI derived this notation from a chat-bot notation called “ALICE”.\nIn essence, this part of the system would execute like a chat-bot.\nBut, with some refinement, it can be used as any kind of event-driven production system.\n\nIn the context of an ontology, this notation provides a way to capture this kind of message exchange.\n\n
• #26: \n