Paradigm Shift To Goal-Orientation

If we look back twenty or thirty years, we can see that processes were not as common as they are today. People did similar things as they do today, but interactions within organizations were pretty chaotic. One day things could go well, and another day they may not. To keep running, organizations relied a lot on specific individuals, who knew what they were doing and who could lead others. Automation just reflected the realities in the organizational management style. It didn’t try to formalize interactions. It just helped people to perform pieces of their individual work.

In those days the sustainability of management was questionable. Then automatic processes arrived and offered a few things that decision makers could not refuse:

• They put fuzzy interactions under control
• They reinforced important behaviors
• They made management less dependent on individual art and made workers easily replaceable
• They made functions reusable and less dependent on a specific context, and
• They made management more predictable and sustainable over time

With these obvious benefits, organizations started introducing and reinforcing processes. Management automation then responded with the shift to process-orientation automation, which used SOA architectures and technologies along with Business-Process Management.

Of course, all of that was a positive change from what it was before. Today, however, we can often hear the complaint that we have too many processes, and we immediately visualize suppressed people acting like screws in a bigger machine. They do their steps, but have fuzzy ideas as to why they are needed. Known actions often become over complicated and move far out of reach due to all the dances and maneuvers that have to happen. Then, if somebody attempts to cut corners to do things differently, he or she is immediately bitten by the manager’s stick. Also, in this picture, managers are not happy themselves. They are constrained almost as much as their subordinates, and they can’t use their knowledge, experience, and power to make things better. Processes starts popping up to organize other processes and eventually consume all in their way. Does this look familiar to you?

It is clear today that processes have problems.They are inflexible and cannot quickly respond to changing situations; though designed to be universal, they are inefficient due to their many steps and cannot be applied to unique situations; they have problems dealing with other conflicting processes; and, most importantly, many processes are not scalable.

This last issue is a huge problem with processes. A small number of processes is relatively easy to be understood by the average human mind. But, when the number and complexity of processes grow things quickly get out of control. All the processes starts to twist and wrap each other, and more processes are created to govern other processes. Even worse, having all of these processes sometimes create a false feeling that everything is under control--that having these processes keep everything running smoothly when, in fact, they are losing people within their twists and gaps. Thus, any attempt to create comprehensive automation using just processes across an entire organization is set for failure. In the best case possible, it will become a Frankenstein monster that consumes large amounts of money and gives few results.

Some people have already begun to see these problems. They say things like, “this must be made simpler,” “employees have to be empowered to make better decisions,” that “success has to be measured by results, not by having a large amount of actions,” and so on. Agile and lean management practices have started to undermine rigid processes. Management is becoming more concerned about what and why and less with how. We can conclude then that a paradigm shift has begun. Right now, however, it’s happening mostly at an organizational management level and is only starting to affect how automation is being done.

Together with Maxim Privalov, I analyzed trends and made a prediction that the next logical step in management automation will be toward goals. The research we performed indicated that goal-oriented management automation will be better able to address the current problems and future needs of management automation because of the following facts:

• Goals are easier to define than processes
• Goals are more flexible and can be achieved through multiple methods
• Unlike processes, goals are more resistant to situational changes and are able to adapt
• Goal interdependencies are easier to discover and manage
• Goals are more efficient since they represent and work towards an end result, and
• Goals naturally scale by breaking it into sub-goals

It is important to note, though, that the transition from the process-oriented paradigm to a goal-oriented paradigm will be a slow evolution. Companies have already spent billions of dollars in automation. They will not want to lose their investments. Thus, every change will most likely happen gradually over a period of time in order to not cause major disruptions. If we look at the past paradigms, we can see how the transitions happened before:

• Centralized Paradigm
• Primary focus: critical organization-wide management functions
• Transition: none - it arrived with the arrival of computers
• Function-oriented Paradigm
• Primary focus: individual management functions
• Transition: revolutionary - new systems were built from scratch while old systems were kept in service
• Process-oriented Paradigm
• Primary focus: business processes to formalize inter-individual and group-to-group interactions
• Transition: evolutionary - previously developed individual functions were exposed via business services and orchestrated into business processes

The new paradigm will continue that pattern:

• Goal-oriented Paradigm
• Primary focus on: business goals that drive interactions or functions
• Transition: evolutionary - previously developed business processes will remain as prescribed patterns to achieve business goals

With this next paradigm shift towards goal-orientation, comprehensive management automation will eliminate the fuzzy and confusing ways of the process-oriented paradigm.

C2/GOMA is the way to do this. Keep reading!

Why C2?

Why do we need C2? What does it do for us? How is it different from what is already there? When first exposed to C2, many people ask questions like that. And that’s absolutely right--concepts just for the sake of concepts are pretty useless things. If you are willing to invest time to learn something new you should have clear expectations of what will be learned. In this post, I offer an explanation.

What does C2 do?

C2 gives you a theoretical foundation to create a very comprehensive management automation, much better than the vast majority of systems today. It shows you a scientific way to eliminate automation gaps and gradually increase the level of management automation to the highest level possible.

Can this be done without C2? Yes, it can be. However, if you are looking at a sustainable, scientific way of dealing with management automation you will be disappointed. Today’s science will cover only low-level control systems (e.g., Cybernetics, Theory of Control). The automation of management at higher organizational levels is problematic. Science fields like Systems Theory and Organizational Management explore problems at a much broader level and do not give specific instructions on how to build automation. If you need to do that, you have to rely more on art rather than science. And that means reinventing wheels and using a “try and fail” approach.

Thus, if you want to create a SkyNet, a fully automated mine on mars, or if you just want to improve your existing management automation system, C2’s comprehensive automation may show you the way.

But, what does C2 not do?

C2 will only do what was stated above. It is theoretical foundation used to create comprehensive management automation. It is not a magic optimization tool. C2 will not do coding for you. It won’t make screens look better. If you need those, you will have to try something else. What C2 will do is help your organization to be as efficient and productive as possible.

Goals

Goals are a central concept in C2/GOMA and, even at its most basic level, one must have a deep understanding of goals. Furthermore, while there are many definitions of what a goal is--from idealistic and philosophical to narrow and specialized--most of them are pretty useless for automation. We need something concrete and universal at the same time. For C2/GOMA I use the following definition:

“A goal is a projected state of affairs that a person or a system plans or intends to achieve.”

Let’s analyze that definition very carefully, word by word:

• “Goal is a … state.” - Read it again with “goal” meaning same as “state.” What kind of state? - A state of a system, an environment, or both. How is that state defined? - Through a set of characteristics/parameters of elements that compose the system or environment. (This moment is crucial to all our future efforts to formalize goals and goal management!)
• “A projected state” - A future, possible, probable, or predicted state.
• “Of affairs” - Actions, efforts, or changes.
• “A person or a system.” “A person” means humans. “A system” can mean anything. It can be an automated system, a robot, a microcontroller, a human body, or a molecular structure.
• “Plans” - Goals that can be set and managed explicitly by a person or system.
• “Or intends” - Goals of a person or system that may only be implicit.
• “To achieve” - The state is a desired end result. This last phrase also means that the actions or changes performed by a person or system are not chaotic, but are instead directed and acted upon.

As you can see, this definition is highly universal. It can be applied anywhere, to any directed actions or targeted changes. It is not specific to only humans, and it doesn’t say if goals must be set consciously or unconsciously at a behavioral, preset, or hardwired level.

At the same time, this definition is quite concrete. It says that goal is a projected and desired state, which we can read as “a set of desired characteristics/parameters of a system and/or environment elements that is reached with targeted activities and changes.” A goal with this definition is something we can formalize and use to create automation.

Now, if you look around, you can see goals everywhere. They are just called by different terms:

Objectives, missions, strategies, policies, initiatives, projects, commands, orders, tasks, jobs, activities, actions, control signals, etc....

But in every case there is a future and desired state. That state can be big (organizational/departmental) or small (personal/individual). It can be in the near future (immediate/short-term) or far future (mid- to long-term). And people, organizations, or automated systems have to do something to achieve it.

Of course, we have not invented goals. They are everywhere, and they have been there forever. We just found that, whether its acknowledged or not, goals stand behind all directed activities and non-chaotic changes. If we assume that most changes in an organization are non-chaotic, then they must be goal-driven. With our concrete and universal definition of goals, C2/GOMA goals can be formally stated and used for automation.

What Makes C2/GOMA Special

C2/GOMA is an attempt to create a theoretical foundation for a broad range of automation problems. It allows us to take any organization and gradually increase its automation from a level of zero to the absolute maximum--the complete replacement of humans with machines.

So, what makes C2/GOMA different from other similar theories and concepts? Here are five reasons:

1. A holistic / system view of the organization and its surroundings

Modeling large organizations operating in real world conditions is an extremely complex task, and people often do various simplifications to make their life easier. They may consider only a small part of the organization or try to minimize its internal details by applying a cybernetic black-box. Although such methods may give positive results in specific situations, they are usually proven to be wrong.

C2/GOMA takes a holistic / system approach to look at an organization. In doing so, it makes a few important assumptions:

1. The organization is an open system. It operates within its environment and cannot be detached from it.
2. Every element is a part of this system. They are interconnected and interdependent with the other system elements and serve the overall purpose of the organization.
3. The organization contains active elements (also called decision makers) with their own will, which are able to change the course of actions by themselves. This means an outcome cannot be predicted based upon its related inputs. But it also requires an understanding of internal organization dynamics.

2. The acceptance of fuzzy and irrational human interactions

By definition C2/GOMA must cover the human aspect of organizations. Human interactions are known to be fuzzy and irrational. Rather than fighting and trying to squeeze it into a well understood but useless model, C2/GOMA recognizes and accepts that fact. Moreover, a certain amount of chaos or entropy is taken to be an indicator of a healthy dynamic organization.

3. A broad view of management processes

C2/GOMA does not look at management as the work performed exclusively by people with the title of “manager.” Instead, it considers any type of directed activity--strategic management, physical labor, or even interactions at a cellular level--to be a management process. That approach allows the application of common consistent models at any organizational level, and ultimately describes multi-level management systems.

4. A broad view of decision makers

In C2/GOMA an active element--a decision maker that performs management functions--can be an individual or group of individuals, an AI system, a robot, or a primitive microcontroller . That fact is abstracted and does not change the way how management is carried out. An organization’s initial management can be a group of human managers, change to be just one man or woman, and finally its management might be replaced by a fully automated computerized system. All those changes do not change the nature of its management processes. This allows C2/GOMA to stay agnostic from automation and gradually change the automation level without breaking the model.

5. A broad view of element responsibilities

Many concepts used in automation today have a pretty rigid model. They define controlled elements and state that the delegation of responsibilities does not change. However, life brings constant changes. A person could be a resource controlled by somebody else’s actions, be promoted to become a powerful decision maker, and then get sick and take a personal leave. Finally, employees may be fired, quit the organization, or even pass away. Realizing the possibility of such changes, elements in C2/GOMA can play different roles in management at different points of time depending on context. That flexibility allows us to describe realistic scenarios in evolving systems.

Hopefully, these five examples have helped you to see how C2/GOMA is special compared to its similar theories and concepts. Next up, I will be talking about Goals in relation to C2/GOMA. Keep reading!

Comparison Analysis of Automation Paradigms

In the previous post, “Paradigms in Management Automation”, I defined four distinct automation paradigms in the past, current, and possible future. Here, I wanted to explain them further by comparing them to each other with a few criteria:

• Industry trends - hardware and software technologies that were available at time of the paradigm shift
• Business demands - emerging business demands that triggered the paradigm shift
• Automation focus - a primary idea or key guiding principle behind the automation practices
• Dominating architecture - the most common architectural style or framework used to develop the automation practices
• Integration model - a way multiple systems were integrated with each other
• Standards - widely used standards that the automation practices comply to, and

Concepts and theories - theoretical principles used to build the automation practices

1. Center-oriented Paradigm

 

Industry trends	Mainframes, machine codes, assemblers, procedural programming
Business demands	Store and process large amounts of data in shorter time, share key information among people of organization
Automation focus	Critical narrow organization-wide problems
Dominated achitecture	Monolithic Architecture
Integration model	None
Standards	None
Concepts and theories	Information theory, theory of control, cybernetics

2. Function-Oriented Paradigm

Industry trends	Personal Computers, LANs, WANs, RDBMS, object-oriented programming, component-oriented programming
Business demands	Lower cost of automation, addressing unique needs of particular users
Automation focus	Individual functions of users and groups
Dominated achitecture	Database-Centric (Two- or Multi-tier) Architecture
Integration model	Transfering data between databases, RPCs
Standards	Ethernet, TCP/IP, SQL
Concepts and theories	Functional decomposition, UML

3. Process-Oriented Paradigm

 

Industry trends	Wide spread of automation, Globalization, Internet, service-oriented programming, Wireless networks
Business demands	More sustainable integration, higher reuse
Automation focus	Business processes within organization
Dominated achitecture	Service-Oriented Architecture (SOA)
Integration model	Orchestration of business processes by middleware
Standards	HTTP, Web Services, BPML
Concepts and theories	Business process modeling, Organization theory

4. Goal-Oriented Paradigm

Industry trends	Wide use of sensor technologies, Mobile devices, Virtual Reality, Artificial Intelligence and Robots
Business demands	Lower integration cost, higher efficiency and transparency, better flexibility, more comprehensive automation
Automation focus	Organization-wide goals broken down into subgoals of individual groups and users
Dominated achitecture	Multi-agent Architecture (?), Model-Oriented Architecture (?)
Integration model	Natural gapless integration based on common principles and standards
Standards	??
Concepts and theories	Theory of Management Automation (?)

As you can see from this analysis, management automation has actually come full circle. It started with the organization in a small-scale, jumped to the individual user/group level, rose to the cross-user/cross-group level, and finally returned to the organization level in a comprehensive wide-scale way.

Hopefully, this comparison helped to better explain the four paradigm shifts.

In my next post, I will be further explaining the OODA Loop concept that C2/GOMA rests on. Stay tuned!