in

The ORM Foundation

Get the facts!

Iterative modelling – how to differentiate between confirmed and drafts part of model

Last post Sat, Jan 7 2017 21:51 by JimLudden. 3 replies.
Page 1 of 1 (4 items)
Sort Posts: Previous Next
  • Thu, Feb 4 2016 10:01

    Iterative modelling – how to differentiate between confirmed and drafts part of model

     

    I am heading an initiative with a team of five colleagues from our business side (commercial, business development, operationl, business process owner guys), aiming at creating an ORM model expressing how business side percieves our business.

    We are using an iterative approach, where each cycle contains a working session (where we add on drafts of new corners of the model/business), consolidating drafts/deltas (where some of us elaborate and fine tunes drafts), review and approval of deltas and full model.

    The challenge for me (and my team) is to be able to differentiate between approved and draft parts of our model. Our more genericly: be able to differentiate between parts with different status (could e.g., be as-is part versus to-be part).

    Initially we used the Visio ORM template to model the first corners of our business. Here we utilized the layers and differently colored layers to express and visualize approved versus draft bits of the model.
    As the model is growing bigger and bigger, we have now turned to NORMA, as the (obvious) tool for capturing and holding our model – and have not yet found any way of solving above mentioned challenge.

    Any advise on how we can accomplish that using NORMA features, would be much appreciated.

    Best regards

    Kim 

    Filed under: ,
  • Thu, Feb 4 2016 11:33 In reply to

    • Ken Evans
    • Top 10 Contributor
      Male
    • Joined on Sun, Nov 18 2007
    • Stickford, UK
    • Posts 750

    Re: Iterative modelling – how to differentiate between confirmed and drafts part of model

    Hi Kim,  Here are some suggestions:

    Context
    Make sure that everyone understands that when you create a object-role model, what you are doing is :
    1: Asserting that some facts are true and then modeling the common structures as a fact type.
    2: Limiting the permissible populations of the fact types by adding constraints (also called "business rules")

    So: All that you have in your model is a set of constrained fact types.

    Process - principles
    In each working session you should aim at adding only those fact types & constraints that have been agreed by your business colleagues.
    Do this one fact type at a time.
    If they don't agree, don't put it in the model until they do.

    If you really must have a draft, (e.g. because not everybody can be in each working session) then use two models: one that is agreed and one that is a draft:
    The draft version should be the agreed version plus new pages that each contain a text annotation "DRAFT" with a creation date and the planned review date plus details of who has agreed to the draft and who has yet to agree.



    "Corners"? 
    Not sure what you mean by this - all that exists are facts - there are no corners.

    As-Is  vs To-Be
    These should be two separate models so that you can plan the transition from the as-is to the to-be.
    Having said that, there will probably be some facts that are true for both states.

    Let me know how you get on.
    Ken



      

     


      

  • Thu, Feb 4 2016 12:37 In reply to

    Re: Iterative modelling – how to differentiate between confirmed and drafts part of model

    Thanks for the advise, Ken

    I think I can make the "DRAFTs on pages"-approach work.

    Best

    /Kim 

  • Sat, Jan 7 2017 21:51 In reply to

    • JimLudden
    • Top 10 Contributor
      Male
    • Joined on Wed, Jul 16 2008
    • Seattle
    • Posts 73

    Re: Iterative modelling – how to differentiate between confirmed and drafts part of model

     I would insert a Model Note on each graphic page that shows date last saved and status.

    That is pretty naive, but works. This assumes that you print the versions. Without some sort (e.g. printed) static intermediary, the latest model will always be just the latest model.

    Alternatively, copy and paste the verbal form of the model into Word, and use the versioning or differences there to highlight what has changed. 

Page 1 of 1 (4 items)
© 2008-2018 The ORM Foundation: A UK not-for-profit organisation -------------- Terms of Service