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!

Eras of Automation Evolution - The Transition to Comprehensive Automation

The history of automation is a very interesting topic, being a history that has spanned thousands of years. However, in that amount of time, there have been very few people who have studied it. This is very unfortunate, because, without understanding our past, it’s hard to look into the future. I’d now like to take a minute to look at the known historical facts of automation with you and try to put them together into a system.

To focus specifically on automation, let’s remember the definition: “The use of technology (machines, control systems, and information technologies) to enhance or completely replace manual human operations.”

That is very a broad definition with many things that may fall into it. Even in a primitive society a human used sticks, stones, and bones as tools to increase the efficiency of his work. He also domesticated animals like dogs, cats, and horses, which expanded his abilities even more. But all those objects cannot quite be considered as automation, because they are not created technologies. Those things were borrowed from nature and used with minimal changes. Technology, on the other hand, assumes something non-trivial, which is created by humans themselves. It can be defined as a product of human work, which can then be used to create other products.

The first automations used by humans were technologies such as the bow, wheel, mill, and blast furnace. These are objects that appeared thousands years ago, and we could call this first period of technology the 1st Era of Automation. Many of those automations were so primitive that several people would not agree to call them as such. However, let’s look at little closer...

First of all, automation can be done in two different ways--by usage or delegation. In the case of usage automation a function cannot produce a solution by itself. A human operator must be involved throughout the entire process from the beginning to the end. Such a function is more correct to be called a “tool” or “passive resource” (or sometimes just a “resource”). In the case of delegation automation, a human is able to set a specific function to carry out a task, leave, and then come only at the end to obtain the produced results. The automation in this case must be able to perform a sequence of operations by itself. Those functions we can call “active elements” or “active resources.”

Looking at these two types of automation, we find that the early primitive tools of the 1st Era of Automation were passive resources and can be claimed as automations. The bow, wheel, mill, and blast furnace were tools used to bring about solutions for their operators, and thus, for this reason, we can say that the 1st Era of Automation began with these inventions.

Initially, technologies of the 1st Era of Automation were used only for the Act functions of the OODA loop and included actions such as “lift”, “move”, “put down”, “kill”, and “cut.” Later, with the progression of human knowledge, we then began to see the automation of Observe functions. This included passive tools such as magnifying glasses to look at fine details, sand and sun clocks to measure time, and flags to determine the speed and direction of wind. Centuries then passed before humans approached the automation of Orient functions. That happened, perhaps, with only with the invention of the mechanical calculator by Blaise Pascal in 1642. Finally, the automation of the Decide function has only come in the last hundred years with the invention of computers during World War II.

By looking at this evolution, the 1st Era of Automation, which I call “primitive automation,” lasted for thousands of years and ended only in the 40s of the previous 20th century. That era is characterised by the automation of individual management functions performed by individual people.

It was only with the the invention of the computer that we began to see a change.

The invention of computer technologies allowed humans to master all functions of the OODA loop and start the implementation of the first autonomous, intellectual active elements. However, management systems still relied mostly on manual work and automation was used only in isolated islands. The majority of functions remained non-automated and were performed manually by human workers. This marks the beginning of the 2nd Era of Automation, and it includes fragmentary, partial, or narrow automation. That era ended not so long ago--just at the end of the last century. However, that’s completely true only for developed western countries, where computer technologies sneak into almost every area of human life. There are many other places in the world where that is still not the case.

Today, developed countries have transitioned into the 3rd Era of Automation, which includes complete or wide automation. In most organizations it is now very hard to find a person who does not use automation of some sort somewhere. Even workers such as janitors, porters, or plumbers more often than not use computers and other automated tools in their work, at least to keep track of their orders and communicate with customers. In this 3rd Era of Automation, with automation at such a high level, almost all active elements in organizations have become more or less covered by automation. Most interactions have started going through computer systems. The total number of workers in organizations decreased and their productivity significantly went up. Finally, some professions disappeared completely, as they were replaced by technologies. With so much automation, there are only a few functions today that could not be automated as they heavily depend on advanced cognitive or creative human abilities.

Today the main barriers for further automation are caused by a few key factors:

1. Technical complexity, or total inability to automate at the current level of technologies. Typically, this problem exists in areas with high uncertainty/variability and the absence of clear standard solution patterns--areas such as research, the development of new technologies, business management, and work in uncontrollable, chaotic environments such as a modern metropolis.
2. Economical rationale. Some jobs, such as cleaning houses or cooking and selling hamburgers are relatively cheap for businesses because of low-paid workers and it could be quite expensive to introduce replacement technologies.
3. Human interactions. Modern systems still experience troubles communicating with humans using human languages (and not all the people are comfortable to speak with computers through a technical language). This causes mistrust toward computers. Because of that, in the areas of human interactions, such as HR management and customer service, human workers are still widely used as mediators between other humans and computerized business systems.

However, we can see how those barriers are quickly disappearing right in front of us. Advances in robotics, Artificial Intelligence, and the massive introduction of complex sensing technologies have increased automation capabilities exponentially. Cost of automation systems is rapidly going down. Human-Machine Interfaces have become more sophisticated, and people are more computer savvy today than yesterday. The level of trust toward computers is constantly increasing.

Today the human society stays at the doorstep of the 4th and, possibly, last automation era: the era of comprehensive or total automation. In this coming era, automation technologies will replace humans in most areas of production and services, and only a few areas may still remain under human control. However, as natural barriers for further automation disappear, other artificial barriers could be introduced using political means. People would still need jobs. What can be done to employ jobless workers? How can they support themselves? Those may become very tough questions. But this is not in the area of my expertise, so I’m not able to give any meaningful comments.

On the other hand, I’m very lucky (from an automation specialist point of view, of course) to work in the industry, which very soon won’t be able to sustain itself without comprehensive automation. And because of that, it doesn’t and won’t have any strong political barriers. I’m talking here about the Mining industry. Natural resources in easily accessible locations on Earth are being depleted, but the demand keeps growing. In order to keep mining, mining corporations must start operations in deep mines and underwater on the ocean floor in the next two to three decades. After that, in the not so distant future, mining shall be done on other planets and asteroids in space. Creating comfortable and safe working environments for humans there will be extremely complex and expensive. And, believe me, there won’t be too many volunteers to spend their lives in places like that. Thus, there won’t be any viable alternatives to comprehensive automation in mining. We are talking here not just about simple operations. Imagine mining on a remote asteroid at the edge of solar system. To operate, automated mining machines shall do construction, mining operations, processing, transportation, and equipment maintenance. That will also require long-term planning and crisis management tasks. In order to do this, we are looking to automate all horizontal areas as well as all vertical management levels up to the strategic level. Searching for solutions to solve that problem became a starting point for my research on goal-oriented management and comprehensive automation.

To compare the different eras of automation I composed the table below:

Characteristics to compare	Primitive Automation	Partial Automation	Complete Automation	Comprehensive Automation
Approximate end time:	40s of 20th century	80-90s of 20th century	20-30s of 21st century??	-------
Key differentiation factors:	Manual work with automation of individual management functions	Automation islands, domination of manual work	Domination of automation, islands of manual work	Complete replacement of routine manual work by automation
Typical examples:	Machine-tools, simple sensors, arithmometers	Automated conveyors, SCADA, Management information systems, remote control systems	Integrated enterprise management systems, autonomous robots	Completely automated production and service organizations
“Anti-patterns”:	Workers, bookkeeper	Paper workflow, office clerks, controllers	Customer service, strategic planning, low-paid jobs	Art, research & development organizations

We are about to transition into the comprehensive automation era. Social needs and the critical mass of technologies are already getting close to that level. I just worry about the lack of fundamental understanding of how all of it shall work. There is still no theory to support everything.

During my short lifetime I witnessed the transition from the partial to the complete automation era. And, I have to say, that the chaos in the heads of automation specialists caused a lot of negative results. I’m afraid that the chaos will remain. Only God knows what could happen when humans decide to completely trust their lives to machines. I think it makes sense to figure it out before jumping there.

That shall be all for today. In my next posts I’m going to discuss in detail a few aspects of comprehensive automation, starting from the new modeling methodologies.

Back to Basics: What is Management Automation?

From time to time in my training sessions I have to go back to basics and explain the meaning of the terms “management” and “automation,” and how they relate to each other. To save time, I decided to write a separate post to review a few fundamental principles. These are principles we use a lot in GOMA. They are not invented by us, and generally they match to commonly used terms. You can read more about them in special literature, and I’ve included a few references at the end of this post.

Let’s start with management. Our definition says that management is “the act of conducting efforts to accomplish desired goals by using available resources efficiently and effectively.” In other words, management represents any goal-oriented activity. From the standard definition we removed the reference to people to make it more generic and applicable to management in socio-economical and  technical systems. The ending, “using available resources efficiently and effectively” states that management is rationally justified and is not a random process.

Automation is defined the following way: “The use of technology (machines, control systems and information technology) to enhance or completely eliminate manual operations.” The meaning of “automation” generally matches the meaning of “technology.” It just puts an extra focus on the partial or full elimination of manual work, and its replacement with work performed by machines.

From those two definitions we can describe management automation as “the use of technology to partially or completely remove people from management.”

There are couple other principles we often use in our work.

Comprehensive (full) automation is automation which completely eliminates people from the management process--like Skynet, but a positive and good one. The creation of comprehensive automation systems is the ultimate goal of our GOMA research. We are working towards that vision. Though it may not be possible today, it could become quite possible in the future.

Conceptually complete MAS is a management automation system (MAS), which supports the entire management process from beginning to end. It is able to obtain, process, transmit, and present all required management information. For example, if person is taken away from all tools, locked in an empty room, and given a computer with only one application to interface with the MAS, he will be able to perform all his work at a reasonable level.

The creation of conceptually complete MAS is also researched in detail in GOMA. It is quite obvious, that in order to do his job, a person must know what is required from him (he must see the upper-level goals) and be able to perform all functions in his OODA loop: observe, analyze, make decisions, and act on them. The actions can be delegated to lower management levels, or be performed directly by the system.

Here it is important to understand the difference between a management system and a management automation system (MAS). While a management system performs management, a management automation system is only able to support the management and automate management functions. The MAS is not able to manage by itself without a human, unless it is a comprehensive system.

For instance, let’s look at a cargo movement system. A person, who carries cargo around, is a management system based exclusively on manual operations. That person can perform management on his or her own. A driver with a truck (loader) represents a similar system, but with different quantitative and qualitative characteristics. The truck is an automated part of the system or MAS, but it is not able to act on its own without its driver. Only a fully autonomous truck-robot is a MAS and a management system at the same time--or, in other words, a comprehensive system.

To finish, let’s look at what a GOMA system is. In our interpretation a GOMA system is “a management automation system based on explicitly defined and interconnected goals, achieved by the joint efforts of elements at different management levels, operating in their individual OODA loops.”

In other words, any GOMA system must have:

• Explicitly defined management goals
• Reason-consequence links between goals
• Support for all OODA loop functions performed by automated active elements--i.e. observation and analysis of information, and planning and execution of decisions made based on set goals and analyzed information
• Execution results linked to back set goals at all management levels

There are other principles and terms we use in GOMA, but these are the basic ones. It is good to have a firm understanding of these principles when studying GOMA.

References:

• Wikipedia. Management
• Wikipedia. Automation