Modelling fundamentals

I once mentioned, that follow the essential systems modeling (esm) principles. As not everybody necessarily will be aware of what this term is about I feel obliged to explain it here.

The Essential Systems Modeling Methodology was defined and applied by Stephen M. McMenamin and John F. Palmer back in the year 1984. It was published in a book surprisingly called essential systems analysis (McMenamin, S. & Palmer, J., Essential Systems Analysis, Yourdon Press Prentice Hall, Englewood Cliffs, NJ, 1984.).

McMenamin & Palmer use an event-oriented approach to process modelling. Their purpose is to identify the "essential (elementary or atomic) processes" being performed and their relationships to the events that drive the business. According to Steve McMenamin and John Palmer essential systems can be detected by the following gedankenexperiment
  • "If we had perfect implementation technology (e.g., a computer with infinite speed, unlimited memory, transparent interface, no failures, and no cost), which of the requirements would still need to be stated?"
  • Every requirement that is still necessary in spite perfect technology is an essential requirement.
The prime purpose of esm is to remove legacy implementation artifacts from the model in order to prevent them from influencing future models. And this ability is exactly my motivation why I want to present this methodology here. In the 1st attempt of the GenericIAM community to derive a generic process model from existing implemented physical models turned out to be surprisingly difficult; in fact it terribly failed. Or as I stated earlier: In fact it turned out, that especially the most experienced practitioners faced difficulties in getting to the next layer of abstraction.

How to derive the target implementation model in a 4-step Process

McMenamin and Palmer recommend to follow a 4-step specification process:
  1. Analysis of the current system
    • build a model of the actual implementation of the current system.
    • This is the physical system like it is implemented in reality - the current physical system.
  2. Analysis of the fundamental concepts of the current system:
    • Deriving of the essence out of the current system.
    • All implementation specific artifacts are removed in this step.
    • Using "perfect technology" as the guiding principle.
    • The result is the current essential system.
  3. Include new requirements into the essential model:
    • Build the new essential model by adding new requirements.
    • This model represents all functional requirements.
    • Ideally it is still free of any design- and implementation consideration.
    • The result is the new essential system.
  4. Design the new physical model:
    • Build the implementation model of the new system.
    • The result is the new physical system.
Finding the essence by this modelling cycle removes implementation artifacts leaving us with the pure functional essence.

The 3rd step in this approach is represents the core of the requirements definition. Here the essential business requirements are documented stating what has to be implemented without defining how it will be done.

This separation enables us to implement the same unchanged essential system using different target technologies. Even when using the same technology maintaining the essential model may turn out to be very helpful. When significant changed are applied to the essential (=functional) model the optimal new physical model may be implemented by a considerably different design that the current physical model.

Avoiding technical "folklore" by assuming "perfect technology"

The assumption of perfect technology leads to the following model characteristics:
  • Inside the system there are neither errors nor processing or waiting times.
  • No audit-, translation- or transport processes are necessary.
  • But the environment of the system is considered as imperfect - as is.
  • Along the systems boundary a ring of audit-, translation- and transport processes connects to this real world - the physical ring.

There are more rules, which help us composing the essential systems model, are:
  • Essential Processes may be triggered by an external or a time event.
  • Fundamental essential processes yield an externally useful result.
  • Administrative essential Processes store their results in an essential store to be used by a fundamental essential process.
  • Essential Processes communicate asynchronously via essential stores - they are time decoupled.
  • Essential processes may be expanded to form nested essential models on a lower layer; essential models in turn may be collapsed to serve as essential processes on a higher level.
  • At the lowest level the essential processes represent elementary activities.
  • The elementary activities can be found by discovering state transitions of the fundamental (persistent) business objects.
  • Elementary activities typically bundle all actions, which are done by one processor without a necessary interruption.
In order to form business processes elementary activities are grouped by their inherent business relationship.

The business relationship is expressed in the value chain and can be taken from there.

Business processes behave like travelling guests
  • they are created by an event,
  • they are themselves transient objects.
  • they undergo several state transitions.
  • they change their state by elementary activities.
  • they carry along their local knowledge about triggering events, acting processor, affected business objects.
  • after delivery they terminate their active life by may be archived.
Equipped with this methodology and keeping these rules in mind in my next post I try to do my first cautious steps to derive essential IAM processes - which hopefully will turn out to be truly generic.

No comments:

Post a Comment