Model-Based Business Engineering, Blog by Dr. Juergen Pitschke, +49 351 30935193 This email address is being protected from spambots. You need JavaScript enabled to view it.g

Stucture, Structure, Structure, ...

In the post "Styleguide and Architecture Principles" I pointed to the fact that finding aggod structure for our  model repository is essential for finding informations, to formalize them into models and to create reports and analize our models. To define a good structure I use "Zachman™-Framework for Enterprise-Architecture" (see zachman.com). Other frameworks follow similar principles (e.g. the Archimate Framework). Often you can map the frameworks to each other.

Unfortunately the Frameworks define only the abstractions interesting for us. In practive userss ask not only about the used abstractions but also the levels of abstractions. Processes are described very globally, but also very detailed from the point of view of an Operator (see "Complex vs. Complicated").

We structure Business Processes also internally by content reasons. Think of the element "Milestone" in CMMN. We structure the business process (the Case) by the information about the Case (stored in the Case Fil). To achieve maintainable and good models, finding a good structure is more important compared to excellent knowledge of the used notation (BPMN, CMMN, DMN, others).

 

Styleguide and Architecture Principles

Some time ago style guides were popular. In the Internet you can still find some of this offers. Users ask today about it.

We offer three documents for help and Guidance.

  • The Style Guide
  • Modeling Guidelines
  • Governance Rules

All three documents help to model and ensure consistency in modeling. The first prerequisite for it is an understanding of the roles of the involved project staff. Not every rule in the documents addresses every project member

  • The Style Guide regulates how we use notations and descriptive means. We restrict standard notations. It gives examples and defines modeling patterns. But it regulates simple facts, such as the color scheme too.
  • The Modeling Guidelines give guidance on what to do, explain working techniques and apply soft skills.
  • The Governance Rules ensure conformity and timeliness of the models. Many games and "ceremonies" play a role here.

Continue Reading

Agile Modelling, Diciplined Agile Delivery, Roles in the Modeling Process

"Agility" is an often used Buzz Word. Whether in connection with agile development, agile companies or agile modeling. The slogan expresses that organizations are able to respond quickly to changing conditions. Agile approaches - Scrum, XP, SAFe - do not favor role definitions. However, the skills and knowledge in the model development process are so diverse today (process modeling and analysis, decision modeling and analysis, risk assessments, etc.). It is not possible to master all skills equally well. But we still expect employees to keep track of everything and have a holistic understanding. Scott Ambler speaks of "Generalizing Specialists." in this context

"Disciplined Agile Delivery" defines various roles in the team (Mark Lines, Scott Ambler: Introduction to Disciplined Agile Delivery) (a hybrid framework that incorporates various agile approaches) defines different roles. The framework differentiates between "Primary Roles" (necessary in every project) and "Secondary Roles" (depending on the project). See "Roles on DAD Teams".

Continue Reading