The Rise and Fall to Growth

Don’t select a solution, select problems the solution will bring in.

[part 5: how]

source: designed by DCStudio — Freepik.com

And you can fly
High as a kite, if you want to
Faster than light, if you want to
Speeding through the universe
…
The Moody Blues

When preparing for a journey, you don’t just throw random items into your suitcase. Instead, you think about the weather, activities, and potential events. To do that you need a clear understanding of what is the trip for, with whom you are going to make it, are you planning to enjoy the trip or only the final destination is the matter.

Without a clearly defined strategy for your upcoming trip, the preparation will not happen or will not serve the goal. You pack versatile clothing, essentials, and maybe a few extras just in case. Similarly, thinking ahead involves considering different “weather conditions”, planning for various activities, and preparing for unexpected events. It’s about being ready for the journey ahead with a well-thought-out and adaptable plan.

The most reasonable question is how much preparation you will need when considering possible scenarios. The number of scenarios is limited only by your imagination. Will you end up with an unmanageable number of suitcases or will you rely on fortune and the wallet in the pocket? There are no right or wrong approaches here. Just two considerations: is it in line with your trip strategy? and how much risk/expense are you ready to tolerate?

Each type of trip requires its unique preparation, much like different situations in business. Will it be possible to define a framework with an acceptable abstraction level, which could help with addressing the preparation for the upcoming trip and handling expected ups and downs during the trip? How should that framework work?

To model the organization’s growth(lifecycle) continuity, we already scoped “what” and “why”, and also defined “who” and “when”. It is the right time to understand “how”.

What is a Framework?

All available dictionaries are in sync that the Framework is:

• a supporting structure around which something can be built
• a system of rules, ideas, or beliefs that are used to plan or decide something.
• the ideas, information, and principles that form the structure of an organization or plan

Let’s dive a little deeper. The term “framework” has been used in various contexts for a long time, and its usage in different fields has evolved over the years. The concept of frameworks in software development can be traced back to the 1960s and 1970s. Early programming languages and systems provided required abstraction, but the formalization of frameworks as we understand them today took time to evolve. As software development became more complex, developers sought ways to streamline the process and improve efficiency. Frameworks were introduced to provide a set of tools, rules, and conventions that could be followed to simplify and accelerate software development.

The use of frameworks has since expanded beyond software development to fields like project management, legal systems, and more, where the concept of a foundational structure that supports various activities or processes is applicable. The term has become a symbolic way of describing an underlying structure or system that supports and shapes something more complex. But anyway, until now the IT industry remains the mainstream driver of the framework concept.

The critical part here is to understand when the system of rules could be identified as a framework. I was not able to find a single source with the required characteristics definition. All available references are only Software engineering related. So let’s try to compile a list of important characteristics of a usable business framework ourselves:

Distinct: Framework should not be a general tool. It has to have a specific use and organize information around one topic or question. The set of concepts or ideas that form the basis for understanding and approaching a particular domain or issue.

Holistic: Support holistic view where necessary. A framework should encourage a holistic view, considering various factors and their interrelations within a system or context.

Safeguard: A well-thought-out framework should save time and reduce the risk of errors in decision-making and execution. You don’t need to develop everything from the ground up, so there’s less chance of introducing errors. Plus, frameworks should have been tested, so there’s less to worry about.

Guidance: The framework should offer methodological guidance, suggesting a systematic way to approach tasks or challenges. Providing a structured way to analyze and address issues.

Focus: The framework should help to identify the necessary information and filter out the unnecessary one. What is the minimum that you need to know to make a good decision? It should supply this easily and without interference.

Simplicity: The framework should simplify the systems handling by making management processes more efficient and straightforward. Speeds up analysis and decision-making process. The faster we can grasp a situation and how it is changing, the faster we can act and react.

Adaptability: It’s all about rolling with the punches and adjusting to whatever comes its way. A system with high adaptability can handle changes, challenges, and surprises without breaking a sweat. It’s like having a toolkit full of solutions for any problem that might pop up. Whether it’s a sudden shift in requirements, a new technology trend, or an unexpected hiccup, an adaptable system can bend and flex to keep things running smoothly.

Predictability: There is a clear and consistent relationship between cause and effect, making it easier to foresee how changes in one aspect will affect the overall system. Based on that a well-designed framework should be able to anticipate and forecast outcomes or behaviors based on certain inputs or conditions.
Here it is important to note that achieving a balance between the mentioned two factors, predictability and adaptability will be essential. We would deal with dynamic and continuously changing environments where the systems that are too rigid may fail to adapt to new conditions. At the same time, overly flexible systems may become too unpredictable to be reliable.

Conductivity: It encourages more effective information flow, including feedback loops. A framework should organize information in a way that the relationships are clear. This facilitates smooth communication by removing unnecessary friction. A good framework can also introduce a common language and those who share it can understand each other and a situation even more rapidly.

Scalability: To stay relevant and effective in the long run a good framework should be designed with scalability in mind. There should be no limitations for the system to grow and evolve. It’s about future-proofing and ensuring that the system can easily acquire new features, technologies, or expanding needs. Imagine it as a building with expandable rooms — you can keep adding more without tearing down walls.

That sounds good for now. Let’s call this the Ten Commandments of ODC.

Having the targeted domain as organization dynamics control(ODC), continuous growth as the expected outcome, and the Ten Commandments of ODC we could start with the ODC framework architecture design.

So How?

Modern flight control systems evolved significantly, with sophisticated technologies ensuring precise control and stability during the flight, which practically could be considered almost “continuous” with in-flight refueling, repairing, and pilot changeover.

Many modern aircraft use a fly-by-wire system, where traditional mechanical control systems (cables and pulleys) are replaced by electronic signals, considerably reducing the friction of parts and extending reliability.

They are equipped with advanced internal and external sensors, and redundant computer systems to interpret pilot inputs, evaluate environmental conditions, maintain stability, control the aircraft’s movements throughout the flight, and last but not least they help pilots in decision-making to keep control over complicated situations.

The computers in modern aircraft continuously analyze the aircraft’s current state and make adjustments to control surfaces for stability and maneuverability. Various sensors collect data on the aircraft’s orientation, speed, altitude, and other parameters. Gyroscopes, accelerometers, and air data sensors provide real-time information to the flight control computers.

The flight control computers send commands to actuators that control the movement of the aircraft’s control surfaces, including ailerons, elevators, and rudders. These control surfaces adjust the aircraft’s pitch, roll, and yaw based on the computer’s calculations.

Automatic flight control systems like autopilot navigation, stability augmentation system, systems that automatically adjust control inputs to keep the aircraft within its designed performance envelope, etc. are all common integral parts of modern aircraft or spacecraft. Add the prioritized redundancy to ensure continued operation in the event of a failure and we will get a “continuous” system reflecting the genius of modern engineering and science.

With such progress, it seems only the absence of a use case, cost considerations and solutions like low orbital space stations are keeping us away from continuous flights.

All this sounds like a good starting model for a framework that will support the continuous growth of the organization. Is it within our defined Ten Commandments? Certainly not. But most of the logic for architecture design is already there and tested. So definitely could be used as a starting point.

Replace the engines with critical factors of organizational success, each with an appropriate acceleration vector control. Define the fuel types the engines will be using to run, as the modern organization just could not run on a single engine or on several engines with the same fuel type. Replace the sensors to read the market signals and internal data. Evaluate already defined internal and external impact vectors and frictions influencing organization flight stability within the context of the framework. Adjust the algorithms behind the automatic control systems, triggers, and alarms to be able to process the new type of data. Create a control dashboard to oversee the organization’s state and provide manual inputs. Assess each change against the Ten Commandments and the final result should be an architecture of the ODC framework. That will stand in the core of organization dynamics control for continuous growth.

Conclusion

There is a common belief that an effective problem-solving strategy often involves breaking down the problem into smaller, more manageable parts. It’s like disassembling a complicated puzzle and you tackle one piece at a time. This approach helps you understand the problem more deeply and allows for systematic problem-solving. But as with any other strategy you will need to be careful with drawbacks.

For each manageable problem on the table, there are certainly several solutions. Mastering the art of picking the right solution among available options involves considering various factors and weighing the pros and cons of each option. When prioritizing the criteria or factors that are important for your decision, when evaluating potential risks associated with each option, and even when testing possible outcomes, all the involved steps should keep a holistic consideration of the global problem you are targeting.

That is where the shifted complications are coming from. When solving each disassembled part of the problem you should never lose the holistic view of the problem you have disassembled. Otherwise, the series of solutions you will have will never target the main problem you have in front. So with that strategy, you are shifting the complications to another stage and it is your choice on the type of complication you would like to deal with. If you think that you have a solution without complications, then try to dive deeper and spend more time to have a better understanding of your problem and solution.

To make the growth continuous, don’t just select a solution based on its pros, select also the cons a particular solution will bring in. As there is no solution without drawbacks, select only the problems you would like and could be ready to tackle.

Thank you for reading the series. This is the final article of it. The next series will be devoted to the actual architecture and prototyping of the ODC framework. It will be published right after proper empirical analysis. Hope to see you there. Stay calm.