Special Features of GOMA Modeling

In my previous posts I mentioned a new methodology to model goal-oriented management systems. It is being actively developed today. The reasons to start creating it became the new goal-oriented approach, and, consequently, the new demands that appeared in front of us. As we can see, the focus of modern automation is moving from the simple execution of a sequence of functions toward the achievement of non-trivial business goals. There are needs for wider, more comprehensive automation. Of course, all classical modeling methods can still be applied, but our small experience shows that the modeling of goal-oriented systems using classical methods can be quite hard.

Problems start immediately with the goal meaning, which in many classic methodologies is missing completely. For GOMA it is absolutely crucial and, to work around this problem, we have to introduce special tweaks and bend standard notation to correctly describe a system in our desired terms. Such work looks more like torture than modeling.

It became clear that the requirements for modern modeling methodologies are significantly higher today than a decade ago. The Systems scale of comprehensive automation increases the complexity of models a lot. Today, the size of models is reaching thousands of elements with tens of thousands of relations. Modeling complexity increases exponentially. And, if yesterday modeling using classical methods was not an easy task, tomorrow it may become completely impossible.

Besides the presence of explicit goals, GOMA modeling differs from classical methods in many other ways. Here are just few of those:

• Specialization in automation of multi-level socio-economical management systems. Many methodologies used today were created to solve specific problems. IDEF/SADT, for instance, was created for the functional analysis of large business systems. RUP/UML initially was focused on the design of object-oriented software. That is a more general problem than management automation. A computer game, for example, is a piece of software that can be described using UML, but it is not a management automation system. There is also SysML, a slightly twisted version of UML, which is marketed as a system analysis tool. However, it didn’t go far from it’s predecessor. BPML is focused on business processes and is almost entirely ignorant about goals, which the processes shall achieve. There are methodologies created to model automation in technical systems like SCADA, but they are too low-level to describe multi-level socio-economical systems full of fuzzy human interactions. The list goes on and on.

The key differentiator of GOMA modeling is in its focus on management automation. The terms used in GOMA models are management automation terms. They naturally fit the problem domain and were not pulled from other areas. In GOMA modeling, the world consists of Elements that are in Relations to each other (system theory approach). Elements can form a management System and start playing specific management Roles (human--a worker, client, or supplier; Hummer--a product or tool; and so on). System management is done via execution of management Functions. The work of the functions is determined by input and output Information Flows (or just Information). Automation is done by the integration of various Components into Management Automation Systems. The Components are responsible for the execution of Management Functions and the enhancement or replacement of manual work of Decision Makers. As you can see, there are no such abstract things like classes, actors, use cases, and other abstractions, which are quite far from real life.

• Scaling. Scaling is the ability to change the level of abstractions from a higher-level description of entire organization down to a low-level description of individual workers and elements. To scale up, models shall become more inclusive and minor details shall disappear. To scale down, models shall be restricted to a smaller area and show it with fine-granular details. While changing abstraction levels, all external relations between a scaled part of the model and the rest shall be preserved.

In existing methodologies scaling is either not possible, or supported only by one main dimension. For instance, the IDEF0 model is focused on functional description and allows to easily enlarge or break down functional blocks. UML is focused on software and allows to enlarge or break down software implementation using packages and components. However, scaling by other modeling dimensions is nearly possible.

In GOMA, modeling scalability is possible by the following supported modeling dimensions:

• Scaling of system and environment structure is supported via context hierarchy.
• Scaling of element roles is done via hierarchical group roles. One such role represents a “superhuman” who can do the work of an entire organization, department or group, depending on selected abstraction level.
• Functional scaling is done via functional groups, which represent coarse-granular functional blocks, similar to IDEF0.
• Information scaling is done through information hierarchies. Goals are broken down into subgoals. Basic facts (observations) are aggregated into higher-level facts (interpretations).
• And, finally, scaling of automation, similar to the real world, is done as a hierarchical decomposition of automation systems into subsystems and then down to elementary components.

• Synthesis - matching the model to the real world. Analysis, performed in system modeling, forces us to simplify and break down complex things into much smaller and simpler abstractions. However, with that simplification we can often miss something important or unintentionally distort the reality. If an incorrect model goes into development it results in a poor automation system. We can constantly see many big or small failures that have their root cause in poor models. To avoid that, before developing something we shall take our model and recreate a whole from abstract pieces. Then we shall see how it matches the reality. If there is a discrepancy, we shall fix it and try it again. That operation is called Synthesis and is the opposite to Analysis. To do that, GOMA modeling has few interesting capabilities:
• Synthesis of system structure is performed through assignment of responsibilities/roles to elements in a real system. That way we can show how one logical system structure can accommodate multiple physical structures.
• Synthesis of management functions can be done using the OODA Loop model. Work of any Active Element can be considered as information processing in 4 distinct states: Observe, Orient, Decide, Act.
• Synthesis of management goals is performed through linking individual goals to their higher-level organization goals. Then we can match higher-level goals in our model to the real business goals and objectives of the modeled organization.

• Verification. The larger and more complex a model, the more important it is to verify and easily correct it. If the verification is not supported by the methodology, then automation can’t help. In that case the verification process depends entirely on human skills and judgement. This is the main factor of fast growth in modeling complexity. When the number of model elements is within a few tens, manual verification is quite simple. When numbers go up to a few hundreds, that work requires a significant amount of effort. For models with thousands of elements, manual verification within a practical time-frame is nearly possible, and there is a big chance of critical mistakes.

Unfortunately, classical methodologies have serious issues with verifications. In many cases it is limited to simple checks for cycle references and the presence or absence of specific references or properties. There are nearly no formal ways to verify models from a meaning/semantic point of view.

In GOMA modeling, besides simple structural checks, there are many semantic verifications. Here are just few of those:

• Verification of goal breakdown completeness, performed top-to-bottom -- check all subgoals listed for a goal
• Verification of goal breakdown completeness, performed bottom-up -- check all super-goals mentioned for a specific goal
• Verification of function breakdown completeness, performed top-to-bottom and bottom-up
• Verification of function breakdown completeness, performed using OODA Loop -- check planned actions, check interpretation facts that are required to formulate goals and plans, check elementary observations used to formulate interpretations
• Verification of correspondence between information flows and functions and vis versa -- check that each function (except Act) produces at least 1 information flow, check that each function (except observation) consumes at least 1 information flow, check that each information flow is consumed and produced by at least 1 function
• Verification of information interdependencies -- to formulate goals there must be super-goals and facts, facts must be based on elementary observations, goals must lead to actions
• Active elements must be responsible for reaching specific goals -- must contribute to overall organization achievements, perform their OODA Loop and all functions associated with it, obtain and generate all necessary information flows, and so on

• Completeness. If we list everything that a real management system consists of, we can get the following:
• Elements to compose a system and environment (The elements can produce and consume information, act as destinations for actions, and may have relations with each other.)
• Functions executed by management system in order to perform its work and achieve organizational goals
• Data, or information, used by a management system to function, and…
• Automations required to enhance or replace manual work of human decision makers (The automations can represent a newly developed management automation system, or existing systems which our system shall integrate with.)

If we compare existing methodologies by their completeness, we can see that not all of them are able to represent the entire system. For example, the popular SADT includes only two models -- one for activity (functions) and one for data (information). In the world structure, automation tools are not completely represented . Only few methodologies, mostly those which are based on UML, can considered as “complete.”

GOMA models contain not only all required elements but also all possible relations between them--links between elements, data, functions, elements and data, data and functions, and so on.

• Clarity. As it was mentioned above, GOMA uses terminology that naturally represents the management automation. The modeler doesn’t need to think hard to figure out what class, object, actor, or use case, for example, shall be used in his model. Information, element, function, automation--that’s the list of key terms used in GOMA models. As we can see, they perfectly match everything that automation specialists have to deal with. The naturalness of GOMA concepts is the key to clarity and ease of understanding not just for analysts but, especially, for model users.

On the other hand, there is a modeled domain with its own special terminology. Sometimes terms used in those domains may be unknown to automation specialists. Or even worse, they may not have a standard meaning, and can be interpreted by different people differently. Obviously, situations like that often lead to a mess. Digging through such models becomes an extremely difficult and unpleasant task. Pretty soon they turn into expensive piles of paper or garbage on a computer disk.

In GOMA modeling there is a special conceptual or semantic model, which describes all key concepts, terms, what they mean, and how they relate to each other and other model elements. In GOMA, any modeling process starts from a glossary definition and semantic structure.

• Tooling. The majority of modeling methodologies used today are relatively old. They were created primarily for manual modeling, and automation tools were developed after the fact. That approach introduced serious limitations into the modeling process. First of all, there is a practical limit that any paper model can have. Second, old modeling techniques were not optimized for computer processing. Because of that, the models tend to be small and ugly, and the computerized modeling process is inconvenient and limited. Automation of manual modeling methodology cannot solve all fundamental problems there.

Since the beginning, GOMA modeling was created for automated tooling. One GOMA modeling tool is being developed in parallel with the methodology with the methodology and tool influencing each other. It even reaches the point of being unclear with what is primary and what is secondary. Manual modeling, of course, is possible in GOMA. However, besides just academical interest, it is not considered from practical point of view.

GOMA modeling probably has more features that are worth mentioning here. If something else comes up, I will definitely write about it in my next posts. So...watch the blog and keep reading.

See you later!