ORM

You want to get back in control of your knowledge and put it to the most efficient use.

Therefore: Take a more structured approach to tackle your knowledge capture and sharing in an elegant and sustainable way.

The greatest wisdom lies in the simplicity and natural order of things. They cannot be recognized, just because everything is so simple and natural.

—Johann Peter Hebel

Without a structured and centralized approach for managing an organization’s knowledge, one or more of the following issues may arise:

• Knowledge is only available during labour times of the head inside which it is carried.
• Crucial knowledge walks out of an organization when people leave the organization.
• It is not clear in which document knowledge that is needed can be found.
• It is not clear on which server a document is stored or in which place it is archived.
• It is not clear if a document contains the most recent knowledge.
• It is not clear which database is considered to be leading in case of contradicting knowledge.
• It is not clear whether all the company knowledge is overall consistent.
• When adding new knowledge, all existing knowledge holders wil have to be checked.
• Modifying knowledge throughout the entire model can be a time-consuming job.

What will speed you up is:

1. A structured and systematic method for identifying, structuring and managing knowledge, that is grounded in natural language and preventing incomplete or incorrect knowledge.
2. A single point of truth, preventing inconsistent and out of date knowledge.
3. A business model that integrates the data model and the process model into one complete model that contains and interrelates all business rules.

Therefore:

1. make explicit all knowledge used and required by an organization to execute its processes; and
2. put this knowledge to the most efficient use.

Three phases to achieve this goal:

1. Identify the knowledge holders of an organization. Altogether, they possess the knowledge that is crucial for performing the organizations key processes. An organizations knowledge is contained in:
   • people's heads;
   • paper documentation;
   • electronic documentation; and
   • databases.
2. Model and centrally store the knowledge contained by knowledge holders in a systematic and structured way, based on natural language, in accordance with world standards like BPMN and SBVR of the Object Management Group (OMG).
   • A process flow describes how knowledge is captured and used by an organization, for example the process prescription of ‘Billing a customer’.
   • A fact type diagram describes what information is recorded about some entity, for example a product and which business rules apply to this entity.
   • A concept description explains in detail what is meant by some concept in an unambiguous manner that is clear to everyone, for example the concept of ‘Price’. Concepts are related in a wiki-style manner.
3. Put knowledge to use in an easy, unambiguous and consistent manner: e.g. by generating (prototype-) applications, documentation, linking to well-known software packages and/or alternative forms of knowledge representation.

At this point, knowledge is sustainably secured in CogNIAM Studio, which serves as a single point of definition.

By applying the CogNIAM method, inconsistencies and incomplete knowledge are systematically located and all parts of knowledge are assigned to classes. Relevant concepts are unambiguously described and the process model and data model are engineered in an integrated manner, creating a complete knowledge model that includes all business rules that apply in an organization.

The methodical approach that underlies the CogNIAM approach is symbolized by the CogNIAM Triangle and its various knowledge classes

Correct, Consistent, Complete, Clear

Goal of the conceptual model is to be Correct, Consistent, Complete, Clear:

• Correct—because errors are eliminated by means of the structured protocol and the validation steps, as well as the quality checks by the use of concrete business examples
• Consistent—because inconsistencies are eliminated through the structured and integrated protocol.
• Complete—processes, data, business rules and semantics are at all times in sync because by using the protocol, the business analyst discovers all the relevant knowledge in the selected knowledge domain.
• Clear—because for communication with the business, (structured) natural language and real life examples are used and stakeholder-dependent languages for the different stakeholders are derived

Sources

• http://www.smashingmagazine.com/2014/10/20/improving-information-architecture-card-sorting-beginners-guide/
• information architecture
• http://www.orm.net/pdf/orm-jcm4.pdf
• http://www.orm.net/pdf/orm-jcm5.pdf
• http://www.orm.net/pdf/orm-jcm6.pdf
• http://www.orm.net/pdf/orm-jcm7.pdf
• http://www.orm.net/pdf/orm-jcm8.pdf
• http://www.orm.net/pdf/orm-jcm9.pdf

Terry Halpin is very active on the topic of ORM and NIAM.

• See Martien's copy of ORM_Presentation_by_Terry_Halpin.pdf Object-Role Modeling An Overview including Temporal Aspects, Terry Halpin.
• Business Rule Modality
• Business Rule Verbalization
• Temporal Modeling and ORM
• http://starlab.vub.ac.be/website/files/Infosys%20Ch1.pdf
• http://www.orm.net/pdf/springer.pdf
• http://www.orm.net/pdf/orm-emm98.pdf
• http://www.orm.net/pdf/orm-emm99.pdf

• http://www.infoq.com/news/2013/07/architecture_intent_frameworks for the core importance of the domain model.
• Radboud University Nijmegen » Computer Science Department » Collegedictaat IS0-cursus: Informatiesystemen in hun context.

Conceptual schema design

The information systems life cycle typically involves several stages: feasibility study; requirements analysis; conceptual design of data and operations; logical design; external design; prototyping; internal design and implementation; testing and validation; and maintenance. ORM's conceptual schema design procedure focuses on the analysis and design of data.

The conceptual schema specifies the information structure of the application:

• types of fact that are of interest;
• constraints on these; and perhaps
• derivation rules for deriving some facts from others.

1. Transform familiar information examples into elementary facts, and apply quality checks.
2. Draw the fact types, and apply a population check.
3. Check for entity types that should be combined, and note any arithmetic derivations.
4. Add uniqueness constraints, and check arity of fact types.
5. Add mandatory role constraints, and check for logical derivations.
6. Add value, set comparison and subtyping constraints.
7. Add other constraints and perform final checks.

For existing application:

• reverse engineer the existing models into a conceptual model; and
• refine the model to fit business needs.

To create a domain model:

1. Collect samples of:
   • use case processes;
   • reports;
   • input forms; and
   • queries
2. To create the domain model from the data use case
   1. Verbalize the data in natural language.
   2. Populate the model with positive and negative examples.
   3. Rephrase this as unambiguous, elementary facts.
   4. Add and validate the business rules constraining the data.

Agile Modelling

• http://www.agilemodeling.com/artifacts/ormDiagram.htm
• http://www.flexiblesoftwaresolutions.co.uk/content/capturing-software-requirements-user-stories-user-interface-and-entities-agile-approach

User Stories

• user story
• must comply with zero or more business rules
• list business rule
• ask business rules to show synopsis in US (a bit like in Logo?)

Business Rule or Policy

• is implemented by one or more User Stories
• ask compliant user stories to list their title

Writing User Stories

1. Define Product Vision
2. Define and describe Roles
3. Write scenarios for roles (a day in the life of, kruip in de huid van)
4. Highlight all nouns (== entities or objects in ORM) and verbs (actions users perform on objects).
5. Distill user stories, each user story has one or more objects and at least one verb. Stories with two objects denote relationships.