I entered the IT industry in the mid-1980s, at a time when developers were just starting to transition en masse from procedural to object-oriented languages. Some people saw the advantages immediately, but others found it hard to get their heads around the new approach. In particular, some developers found it difficult to understand what programs that were made of objects would actually do. Where did they start? Where did they end? And what happened in between? It seemed so much easier to design and maintain systems when you had a single procedural control flow.
The truth, of course, is exactly the opposite. Object-oriented programs are much easier to design and maintain, which is why very little software development, even in the small scale, is now procedural - mainly *nix shells (which haven’t changed much for decades) and a few other specialized scripting languages.
But why are OO programs easier to design and maintain? Because they separate concerns, by grouping together the code and the data that addresses a particular area of interest. You can then deal with each area in isolation - for example, you can monitor the functionality and performance of each area, and adjust it as required. For example, you can deal with exceptional cases that crop up by specializing the object’s type definition (typically by adding a sub-class) to change its actions or content in certain situations.
This is part of what Roles in a HIM process give you. Unlike swim lanes, Roles are true objects, so they can be used as templates for new objects. The last post showed how this can be used to duplicate Roles within a Plan. It can also be used to make new, customized versions of a Role to deal with special situations, either during execution of a live Plan or when preparing a template for a new Plan.
A simple and common customization is to introduce new documents or data into a Role, that can be done at any time either by the owner of the Plan or the player of the Role as part of a Stage. This information is automatically shared with everyone else in the Stage.
Another common customization is to alter the scheduling of the Role’s activities. Like Stages themselves, Activities in HIM are not one-off steps in a control flow, but have a status that is set collaboratively, and may be returned to as needed. To manage this, each Activity is given an estimated number of days effort, a start date and a deadline. This scheduling information is then used to manage the Plan.
For example, the HIMS will warn you if an input to the Activity looks unlikely to be ready in time for it to complete on schedule. The Plan can then be adjusted in various ways - to declare the input ready for use when it is only partially complete, to remove the input from the Activity altogether, or to adjust the scheduling information assigned to the Activity.
It is also common to make such adjustments when preparing to start a new Plan - for example, if the template usually used for a particular type of work process would result in a cost that in this case is too high.
By contrast, if you are using BPMN, the UML, S-BPM or any other procedural process definition technique, it is not even visible how data and documents drive the process forward, and the options for adjustment are both more limited in scope and more complex to implement.
More about OO process modelling in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.