Model-Based ... Notations and Models are Means to an End
We are talking of Model-Based Business Engineerin. Models are base for many working techniques as described in the White Paper "Model-Based Business Engineering - A Positioning". Based on models we define, measure, optimize Business Processes, for development of workflow-based systems and much more. One of my favorite quotes by John Zachman is "If you can't describe it, you can't uild it".
We use different Standard Notations by the OMG for Model Development. They offer a good number of benfits: exchangeability, defined meaning of model elements, tool support, ... Sure, all notations also have shortcomings. But discussing endless abou the shortcomings is boring. Notations are a mean to an end. They are a tool. It is very important, what our goal, our end for our models is.The mean (the notation) will be determined by this.
In one of my customer projects I found a Project Charter saying that the goal of the project is to introduce BPMN 2. I don't think that this is a real goal. We want to minimise risk, improve processes, alow measuring processes and much more. To find out if BPMN supports this should be part o the project.
Belongs the notation to chose to the project charter?
Discussing this it became clear that the project sponsor was very keen to have this in the project charter. Earlier efforts in the BPM field led to a variety of presentations, every analyst and consultant chose a own presentation, different abstrations and other problems. In total the descriptions were not maintainable, not usable and didn't help to contribute to our end. In summary: Naming the notations and presentation forms can be part of the project charter or should be defined early in the project. We want to get models which are maintainable and usable long term. Our stakeholders must relate to and accept the presentations and especially the deliverables produced from it.
Standard Notation or own presentation?
Everybody knows that I'm a strong supporter of Standard notations. I don't believe that the standard notations are the only possible mean. I don't believe that the Standard notations are the best presentation form. Standard notations support us in achieving coherence. But all the standard notations are "Standard Notations". They try to adress many different use cases. For most application scenarios they contain too many elements. At the same time you miss elements or attributes for your needs.
Detail Standard Notations - Styleguides and the role "Method Author"
Using the elements of a standard notation can differ depending on the abstration level. All this requires, that we use standard notions but customize them to our needs - we add own attributes and document elements in a consitent way, Most projects or initiatives define a "Modelling Style Guide" to specify the elements used, naming onventiions and so on the achieve consisteny of the created models in the team, to help the analysts and modelers.
We name the role which is responsible for this "Method Author". Many companies see his as part of the role "Architect". In difference to the role "Architect" the "Method Author" not only defines the structur of our models (the elements and relationships between them). This role is also responsible for the specifying the method: how to create the models, which working techniques to use, how to help the analysts and modelers. This role is important ecspecially in the early phases of a project and ensure the consistency of the models not only in a single project but in the enterprise.
My summary: naming the presentation form or used notation can be part of the project charter. It must be also clear wht the purpose of the created models, which problem to solve, And we need a role to make sure we achieve both things: Consistency and solving problems.