Wednesday, June 19, 2013

GOMA Modeling

The first step in working with any system is to understand it by starting with its description, which can be expressed in a formal or informal manner. A model, which is an abstract formal definition of a system, can be very helpful. It describes a system’s structure and behavior and can be represented by several interrelated views. In this post, we will look at a general approach to modeling goal-oriented systems and the reasons behind doing so.

Below are two of the most typical methods of modeling and improving models: the reengineering of business processes, and comprehensive management automation.

In both cases the process starts when a business analyst looks at a real or planned system, and then creates a formal model of the system’s structure and its behavior. This initial model is called the domain or business model. After that, the next steps are significantly different:

  • Process Reengineering procedure:
    • The original model is improved to solve particular business problems--to optimize management processes, to minimize resource utilization, to maximize productivity, etc.
    • The improved model is deployed and then transforms the management system.
  • Management Automation procedure:
    • Similar to reengineering, the original model is improved since automation may significantly change various management processes (and there is no reason to drag the rudiments of manual management into the new world).
    • Next, the new automation system is added to the business model and linked to its functions, information flows, and other elements that will be automated--and their quantitative and qualitative characteristics are elaborated. The new model is called requirements as it defines what the automation system will require.
    • Based on these requirements an architecture is created, which is also a model. It describes the structure of new automated solutions, the system’s decomposition into subsystems and components, the component’s functions, and processed information.
      • The requirements can also be used to generate test cases to verify that the automated solutions do what they were intended to.
    • Based on the architecture model, automated solutions are then implemented and finally deployed throughout the organization.

The modeling of Management Automation leads into GOMA Models. In order to understand GOMA Models, it is good to know about the modeling elements that may be contained in them:

  • First, there are Systems (S) and Environments (E) that are broken down into Subsystems (SU) and Subenvironments (EU), which can all be called Contexts (C). Contexts allow designers to split a large model into smaller logical parts, which can be defined separately without losing connections with the whole.
  • Then there are Elements (E), which compose the system and environment, their relations (ER), and the parameters (EP) that define their state.
  • Next, there are the Roles (R) that elements play in a management process. There are 4 key roles plus one group role:
    • Active element (RA) or Decision Maker (DM) - An element role that is actively involved in management. It is able to perform management functions, receive and reach goals, make decisions, and take actions to change a system and/or environmental state. For example, a digger, a driver, and their customers and supervisors are all active elements.
    • Resource (RR) - An element role that required for specific management functions, but is not able to perform functions by itself. For example, a shovel is resource for a digger, and fuel and vehicles are resources for a driver.
    • Subject (RS) - An element role on which the actions of active elements are directed. For example, a piece of land is a subject for a digger, and loaded vehicle is a subject for a driver.
    • Observable element (RO) - An element role that supplies information used in a management process. For example, weather is an observable element for a digger, and the road and other vehicles on the road are observable elements for a driver. (Here I must note that the other roles may also supply information and can be considered as observable elements, too.)
    • Group (composite) element (RG) - A group element role. Such a role is useful for the recursive decomposition of a management system. It may represent a division, department, or group as a single super-element and can be broken down into smaller and more specific roles.
  • Now come the Management Functions (F), which are performed by active elements to process information and achieve their management goals. Functions, following the OODA Loop model, can be subdivided into these areas:
    • Observe (FB) - Functions that obtain initial data (basic facts and observations).
    • Orient (FO) - Functions that interpret the obtained data to generate facts useful for decision making.
    • Decide (FD) - Functions that make decisions based on higher-level goals, current situational information, and knowledge about the system structure.
    • Act (FA) - Functions that perform actions to change a system and/or environmental state, or that delegate actions to subordinate active elements at lower management levels.
    • Finally, it is also good to consider Functional Groups (FG), which can be repeatedly broken down into lower-level and more specific functions.
  • Next are the Information Flows (I) that are transmitted between system elements and processed by management functions. They can be divided into:
    • Goals (IG) - what must be achieved in the management process by active elements.
    • Actions (IA) - information on what has to be performed to execute set goals/plans and to change the system and/or environmental state. Based on principles of dualism, actions represent an elementary goal at a certain abstraction level. They show an endpoint in the management flow. Also, they cannot be broken down into smaller goals, while goals can be.
    • Escalations (IE) - signals alerting that set goals cannot be reached in the way they were defined. Escalations are typically transmitted in the opposite direction of their related goals.
    • Interpretations (II) - various facts required for decision making. Interpretations represent the most common form of analytical information.
    • Observations (IO) - initial basic analytical data. Based on principles of dualism, an observation represents an elementary interpretation at a certain abstraction level. They show a starting point in the analytical flow. Additionally, as they’re based on initial data, they cannot be broken down into simpler interpretations, while regular interpretations could be.
    • Results (IR) -  interpretations (including observations) which can be directly linked to specific management goals. Results are used in the feedback loop of a management system.
    • Information about System Structure (IS) - represents information about the structure of a system and environment.
  • Finally, we come to Automations (А), which are various technological tools used to automate management systems. They can be divided into:
    • Automated Systems (AS) - automation solutions which are separately developed, purchased, and installed.
    • Automated Subsystems (AU) - parts of larger automation systems which could be broken down into smaller components.
    • Automated Components (AC) - elementary, indivisible parts of automation systems.

All of these modeling elements have many complex relationships with each other. When not put into a GOMA model, these relationships might look similar to the following semantic map:



It looks like a big mess, doesn’t it? Ideally, a GOMA model will be defined with extremely high precision and details, so it can be sufficient for the design of comprehensive automation solutions--solutions that will completely replace humans in management systems. Obviously, if such complex models are visualized in a single plane, it will be practically impossible to read and understand them. That’s why GOMA models use a number of interrelated graphical views (diagrams).

I’d like to emphasize that the diagrams in GOMA are not models. They are just views of a model to visualize it from a specific angle. Any change in a model shall trigger changes in the diagrams, which will contain the updated elements and relations between them. I’ll give you more details about different types of diagrams in my later posts.

Lastly, I’d like to mention the possibility of formally transitioning between different types of models. In the figure below, we can see the evolution of a model from a Domain/Business model to a Requirements model and finally to an Architecture model.

  • The Domain / Business model defines a system before automation. It describes the system’s structure, element roles, management functions, information flows, and the relationships between them.
  • During the Requirements elicitation, a domain model is extended with automation systems and information about:
    • Active elements to be automated
    • Management functions to be implemented
    • Information flows to be produced or consumed by automation
    • Interfaces with other management systems, and
    • The quantitative and qualitative model characteristics, required for automation, are elaborated.
  • Then, to move to the Architecture model, a requirement model is further elaborated:
    • Each automation system is broken down into subsystems and individual components
    • For each component, the implemented management functions and input and output information flows are defined to outline their interfaces (contacts or surface areas)
    • The technological characteristics of implementation are elaborated
If the resulting architectural model is detailed enough, it can be used to generate code (similar to an MDA - Model Driven Architecture)

With all this information, it is clear that the complexity of GOMA models is usually high. It makes it very hard to create and maintain models without special tools. Thankfully though, the diagrams presented above help to understand them, and additional instrumentation tools are already being developed. (I will discuss these tools in a future post.)

Hopefully, this article has helped you to see the better benefits of GOMA modeling. Though complex, it is much easier to understand than the other typical methods of modeling. It helps us to better understand management automation systems.

No comments:

Post a Comment