Realising the value of your information TM Powered by Intraversed Business Definitions for Data Management Professionals Intralign User Guide Excerpt Copyright Intraversed Pty Ltd, 2010, 2014 W-DE-2015-0004 2010, 2014 Intraversed Pty. Ltd. - ABN 71 125 000 866 - Phone: 0417 215 475 - Email: tsmith@intraversed.com.au - Website: www.intraversed.com.au
Table of Contents 1. Introduction 3 2. Differences in approach to writing definitions 3 2.1. Business Model versus Logical Data Model 3 2.1.1. Avoiding Abstract Concepts 4 2.1.2. Focusing on Stakeholders and Definition of Business Terms 5 3. Other Information Assets 5 4. Business Terms and Business Rules 6 4.1. Example Definition of a Business Term that will conform to the expression templat 9 2
1. Introduction Intralign, in conjunction with Intraversed s Business Information Management methodology, provides a capability to align and coordinate information assets using measurable governance and collaborative management of: 1. business terms and business rules; 2. libraries of key information artefacts (reports, procedures, policies, documents, pages, etc.); 3. quality issues and projects. The objective is to improve business effectiveness by maximizing the translation of tacit knowledge into explicit knowledge and making it easily accessible. Intralign is a tool for capturing and sharing information about information: 1. The non-ambiguous definition of Business Terms; 2. The cataloguing of other relevant Information Assets; 3. The stakeholder and lifecycle information relating to those Business Terms and other Information Assets. If you are from a data architecture or other IT background, you might consider it a kind of metadata tool and we would, in this case, stress that it is concerned only with business metadata, i.e. Business Terms and Information Assets rather than data dictionaries and IT assets (system databases). However, we are concerned with how business metadata relates to IT systems for two reasons: We want to ensuring that the business terms are fully understood and utilized by IT projects that impact the stakeholders of those business terms; Cataloguing Information Assets that translate (or transform) data from our IT systems into reports and metrics that are consumed by your company s business community or can be reused by future IT projects. 2. Differences in approach to writing definitions If you have any experience with data models, there are some key differences in the approach to defining Business Terms using Intralign s language structures versus creating Entity Relationship (ER) diagrams or Object Modeling diagrams. 2.1. Business Model versus Logical Data Model The premise here is that data models, typically conceptual-level ER models, are often used as a mechanism for modeling the business concepts and its rules, and that these business models are quite different from 3
logical data models (LDM) 1. To illustrate this premise, let s look at a common Business Term in use by the telecommunications industry: Example: Basic Telephone Service (BTS) A BTS might exist in the business model and be defined using business rules and other common Business Terms, for example: A Basic Telephone Service (BTS) is a residential class of Telephone Service that is established using the Public Switched Telephone Network (PSTN) and has a free listing in the White Pages directory. In this example, the LDM might contain entities called Telephone Service, Network Type and Class of Service but there probably won t be an entity called BTS. Therefore, to describe a BTS using the available entities, we would have to know that the values Residential and PSTN are valid for the Class of Service and Network Type entities. However, these values would not usually be clear from the logical model s diagram,although they should be documented in the text of the entity definitions. Having illustrated the difference between business and logical data models, it must be noted that translating a business model into a logical data model is not a simple process and some assume incorrectly that the solution is to combine the two into a single LDM this is often the basis of industry reference models. Whilst this can be achieved, the resulting model will contain abstract concepts; it will be a generalized model that can no longer describe the specific business terms and business rules. Some Data Warehouse (DW) practitioners even attempt to combine the DW logical model with the physical data model the model used to create the database structures effectively ignoring the need to document how the business requirements should be represented as records in the database. 2.1. Avoiding Abstract Concepts Having explained the difference between business and logical models, the first difference in approach can be presented: the avoidance of abstract concepts. Because Intralign is designed to support business terms and rules, abstract concepts are not appropriate. This is because abstract concepts can often only be defined effectively by referencing their own subclasses. Whilst these concepts are very useful in standardizing database structures and combining data for operational efficiency reasons, they serve no useful purpose in the language of non- technical business operations. Example: Party The abstract concept Party (with the exception of those in the business of law, insurance, etc.) is often classified as: an individual or an organisation or a group of people for some purpose. 1 A logical data model in this context is a model of the organization s data and relationships that is independent of implementation requirements or IT system constraints. 4
Note the use of the conjunction or this word is typically found in the classifying statement of an abstract concept s definition. A data model would probably include a party concept in order to simplify the relationships between areas of the model a single relationship from a superclass is less cluttered than many identical relationships from the subclass. However, within Intralign we would only be concerned in the definitions of individual and each relevant organisation and group, such as business, charity, etc. 2.1. Focusing on Stakeholders and Definition of Business Terms When creating data models, the approach we have seen as typical is to conduct interviews or workshops with the business community then work in isolation, exploring different entity relationship structures until a workable view is attained. The definitions behind the entities,attributes and relationships are then added to clarify the picture and, in most cases, the business community are then asked to sign-off. The second difference in approach is that business stakeholders and Business Terms come first. Business Terms loosely correspond to entities and attributes. They are a type of Information Asset and their definitions will almost always include Business Rules. Intralign is focused on the definition and maintenance of Business Terms by the stakeholders; ownership is established before the definition is written and the stakeholder group can collaborate in refining the definition. Then the definition is validated by the rules engine, where the relationships are also identified and activated. 3. Other Information Assets Once the Business Terms are complete and, preferably, validated, other Information Assets can be identified or created and then registered and linked to, or classified against, the Business Terms. Intralign does not store copies of these other Information Assets Intralign is not a document management system but it does enable lifecycle management, tracking and governance over key assets. These Information Assets typically: 1. describe how the Business Terms relate to databases or data models, e.g. queries, transformation rules or reference data tables; 2. provide additional information about the Business Terms, e.g. product specifications or standard operating procedures; 3. present metrics as reports, e.g. a sales report from the accounting system, the sales target spreadsheet or data quality reports. 5
4. Business Terms and Business Rules We ll start by outlining some of Intralign s own Business Terms that you will need to know (and may have already come across). These are also documented within Intralign. A Business Term is a name that must consist of one or more words and indicate something of importance and should improve communication within the business community and assist in achieving business objectives. A Business Term will either: 1. Have a Definition; or 2. have a Primitive Definition; or 3. be an acronym or synonym, both of which will have a single Business Rule that classifies it against the Preferred Business Term, thereby directing the user to Definition of its parent. A Definition describes a Business Term using one or more Business Rules. The only exception is the Primitive Definition. Intralign definition methodology is designed to be easily interpretable and are structured for clarity. Figure 1 A Structured Definition of a Definition A Primitive Definition is the definition of a Business Term as found in the Intralign dictionary or imported from some external source. A Business Rule is an Expression that conveys how the Business Term relates to another Business Term. Each Business Rule will conform to one Rule Type. Note: Intralign Business Rules are concerned primarily with definitions as opposed to definitional rules 2 and behavioral rules, the sense of prohibition of the latter being provided by the Option Phrase that leads the Business Rule s Expression. 2 Definitional rules also called structural rules provide the criteria for determining the state of being, are the domain of IT systems, and should not be captured as part of the Definition. See Business Rules vs. System Design Choices by Ronald G. Ross http://www.brcommunity.com/b544.php 6
An Expression consists of an optional Option Phrase, and one or more other short phrases, e.g. a verb phrase, Cardinal Phrase and prepositional phrase. An Expression must conform to an Expression Template. Figure 2 A Structured Definition of an Expression An Option Phrase is used to standardize each business rule and indicate business rule sets. This is achieved by using conjunctions and optionally one of five modal verbs: must, will, should, can, may (in descending order of strength). These modal verbs are used in the deontic sense expressing duty or obligation rather than the epistemic sense (relating to validation). These modal verbs also work easily with the base for of any verb, thereby [almost] eliminating the need to conjugate the verb. The first of each set of business rules will provide the modal verb, with subsequent rules of the set using only conjunctions. In data modeling terms, the modal verb indicates cardinality: must = mandatory; will = optional becoming mandatory; should, can & may = optional. Figure 3 A Structured Definition of an Option Phrase 7
A Rule Type defines the Expression Template that will be used to validate a Business Rule. There are 10 pre-defined Rule Types: Classification Rule there must be only one classification rule. This defines the class to which the Business Term belongs, e.g. a spoon is a type of cutlery. In linguistic terms, this defines the Business Term s hypernym. In data modeling terms, specifically entity- relationship diagramming, this defines the super-type. However, the exclusivity of the Business Term with regards to its siblings (other sub-types of the super-type) are handled via the other rule types. Functional Rule a Business Term will typically have either consequential and/or functional relationships with other Business Terms. The functional rules state the purpose of the Business Term and are typically applied to Business Terms that the organisation has control over, e.g. a voice message service is designed to record a message when a voice call is not answered. In data modeling terms, these rules will define the Business Term as being the parent of an existent-dependent relationship with another major entity. Consequential Rule as stated above, a Business Term will typically have either functional or consequential relationships with other Business Terms. The consequential rules state the outcome or responsibility of the organisation should the Business Term occur, e.g. a serious adverse event may occur to a subject in a clinical trial. The outcome will invoke investigation and reporting Business Terms. In data modeling terms, these rules will define the Business Term as being the parent of a (typically optional) dependent relationships with other major entities. Compositional Rule these rules describe how other Business Terms relate as components to the Business Term being defined, e.g. a postal address must have a city and will either have a box number or have a street number, etc. In data modeling terms, these rules will define the Business Term as being dependent (existent or non-existent) upon [a relationship with] another major or reference entity. Characteristic Rule these rules further describe the Business Term by inclusively or exclusively relating other Business Terms, e.g. the business-line product will typically service business customers. In data modeling terms, these rules may represent attributes or relationships that are difficult to show in an entity-relationship diagram. Conditional Rule these rules define conditions under which a preceding rule will apply. In data modeling terms, these rules are not explicit, although the fact that a condition may exist would be implied by an optional relationship to the entity that represents the preceding rule. Financial Rule these rules describe characteristics that are financial in nature, e.g. a sales tax financial rule might state that it will apply 10% to the total sale price. Calculation Rule these rules list mathematical calculation, e.g. gross profit equals gross sales revenue minus cost of sales. Regulatory Rule these rules describe characteristics that are in place due to external requirements, e.g. certain businesses are prohibited to sell to minors and the definition of a customer might include the rule must not be a minor. Notational Rule these rules do not have Expression Templates and allow the Definition to include notes, quotes and examples. These rules do not define relationships with other Business Terms. 8
4.1. Example Definition of a Business Term that will conform to the expression template Taking the definition of a Business Term from above, the structured approach identifies first the hypernym name. We then identify the other business terms (nouns) that are important: word; importance; business community; business objective. Note how rules 4 and 5 are grouped because the option phrase of rule five only provides a conjunction. Note also the cardinal phrase one or more in rule 3. Also note the use of the (one allowable) prepositional phrase within the business community in rule 4. A Business Term (using our structured approach) 1. is a name (classification) 2. that must indicate something of importance (functional) 3. and must consist of one or more words (compositional) 4. and should improve communication within the business community (characteristic) 5. and assist in achieving business objectives (characteristic) 9