CC BY
5DOI: 10.24412/cl-37100-2023-12-265-275
V. Petrov, P. Azaletskiy Socio-informational system contradictions and evolution laws
SUMMARY
Our lives are becoming more and more dependent on digital products. We trust autopilot systems in plain and cars, doctors rely on healthcare systems to prescribe a treatment, money gave way to cryptocurrencies, and the list can go on. An organization stands behind every digital product with its social structure, culture, and values. The understanding that a technological system does not exist independently of social systems helps us better understand the principles of system evolution, system contradictions, and possible avenues for improvement.
This paper will explore socio-informational systems through the lenses of the Theory of Innovative Problem-Solving (TRIZ). We will explore the well-known software industry laws, their intersection with TRIZ laws, and the contradictions.
Keywords: Socio-Informational, Contradictions, Evolution Laws
INTRODUCTION
The term socio-technical system was originally coined by Emery and Trist (1960) in the book describing the project undertaken by Tavistock Institute in the British coal mining industry. They created the socio-technical system term to describe systems that involve a complex interaction between humans, machines, and the environment. This interaction is true of most enterprise systems. [1] Eric designated three levels of socio-technical systems even though they are interrelated [2]:
• Primary work systems - systems are carrying out a set of activities involved in identifiable and bounded subsystems of the whole organization - such as a line department or service unit.
• The whole organization system - is a combination of all subsystems of an entire company producing the value.
• Macrosocial systems include systems in communities and industrial sectors and institutions operating at the overall level of society.
In this paper, we will focus on the primary work system level; moreover, we will devote our analysis to the specific class of technology systems, such as information systems. However, we may argue that our observations apply to the broader spectrum of technology systems.
Lehman studied information systems and discerned three types of programs with different characteristics: E-type, P-type, and S-type. [3]
• S-type systems have formally defined specifications with clear criteria of correct implementation matching results to the inputs. result
• P-type systems are more complicated; they are designed to solve real-world problems with defined rules. Even though the problem to be solved can be described, the acceptability of the solution depends on the environment/context in which it is executed. An example of such a program is a chess game algorithm.
• E-type systems are real-world systems that don't have static rules, environment, or clear specifications; We are talking about software programs working within living business organizations involving people. Given the evolving nature of the software program's environment, correctness is vaguely defined. Examples of such programs are systems automating business processes.
In our paper, we will focus primarily on the E-type of information systems developed by the correspondent social construct of the primary working system.
Socio-Informational System Definition
Figure 1. Structure of the socio-information system
Let's define the socio-informational system more precisely. Following the Lehman system classification, this is an E-type, real-world system. Systems that are intertwined with processes of real life, with business processes, with real people where there is not necessarily a specification of 100% correctness. Because the system's requirements are ever-changing, a consumer is not entirely sure what they want to have. Or even if they are sure today, tomorrow might not be the case. It's important to emphasize that that's not necessarily just because of uncertainty. That's because consumers exist in an environment that's subject to change since people's and business needs evolve. Therefore, the specification and requirements of our system are not stable.
Given that premise and the fact that digital products cannot automatically implement new requirements without people's involvement, we need to recognize additional structural elements. We call it "social," which defines a human organization as responsible for delivering new functionality and fulfilling the purpose of the system. Without human organization, no digital product can be created or abandoned after creation since it becomes misaligned with the changing environment that eventually breaks the purpose fulfillment law.
The socio system is an alive system; therefore, its construct is comprised of people and their relationship (network) that together defines the property of the socio system as a whole designed to live within the environment. [4] The social component is well recognized across fellows of the so-cio-technical system, and Badham articulated the following key characteristics of the socio-technical system, where the social component is named as a subsystem referring to people, work for context and organization.
• Systems should have interdependent parts.
• Systems should adapt to and pursue goals in external environments.
• Systems have an internal environment comprising separate but interdependent technical and social subsystems.
• Systems have equifinality. In other words, systems goals can be achieved by more than one means. This implies that there are design choices to be made during system development.
• System performance relies on the joint optimization of the technical and social subsystems. Focusing on one of these systems to the exclusion of the other is likely to lead to degraded system performance and utility. [5]
Another piece of evidence supporting the existence and importance of social elements is the Conway Law or mirroring hypothesis that was confirmed by Alan MacCormack. [6] "Products tend to "mirror" the architectures of the organizations in which they are developed. This dynamic occurs because the organization's governance structures, problem-solving routines, and communication patterns constrain the space in which it searches for new solutions. Such a relationship is important, given that product architecture has been shown to be an important predictor of product performance". Therefore, the social and information product architecture are intertwined and should be considered cohesive.
A social element should be treated as a system comprising elements (people), connections (social structures), flows, and a control system. Following the TRIZ definition of the system structure [7], the social system should have the following construct:
• Physical: teams' decomposition, distribution among physical locations and time zones.
• Energy: money, team engagement, motivation, wellness
• Information: knowledge about digital product architecture and element's structure
The efficiency of our entire socio-informational system depends on the structure and how the interactions/flows among structural elements are organized and coordinated in the physical, energy, and information realms. Moreover, the socio part of the socio-informational system should be aligned with technical architecture to be efficient. Law of completeness of system components
Our social element should have the competencies and knowledge to produce the required technical changes in the informational product; if the person/team knows how the component works gone, then the whole socio-informational system's existence might be questioned. In the organizational management research field, we found that Youndt [8] introduced the term intellectual capital, which transients the notion of the competencies described above. He defined intellectual capital as "the sum of all knowledge firms utilizes for competitive advantage. The sum of all knowledge means that the concept of intellectual capital encompasses all assets available to a company. Different divisions of intellectual capital into components exist. [8] Claes take it forward and discern three types of intellectual capital: human capital, social capital, and organizational capital. [9] Human capital is individual knowledge; social capital is the social construct that provides an infrastructure for interaction/information flows, and organizational capital refers to processes and the external organizational network with customers and partners.
From the TRIZ perspective, we can say that the social subsystem should have people with their human capital (knowledge and skills); the way it transforms information could be referred to as a part of organizational capital (processes), connections that are social capital, and management system could also be referred to the organizational capital.
Figure 2. System Structure Law of flow conductivity and Law of minimum coordination
Since systems are comprised of multiple elements, in the case of the socio-informational system, we have socio-construct and associated with it informational system architecture. Both layers have communication and coordination mechanics that sometimes intertwine.
In alignment with TRIZ, the flow conductivity of the socio-system should have informational conductivity that represents the social and organizational capital and energy conductivity in the form of financial resource distribution to keep the system alive. Henry Mintzberg proposed five coordinating mechanisms between elements to ensure coordination: mutual adjustment, direct supervision, process standardization, output standardization, and skill standardization. As organizational work becomes more complicated, the favored means of coordination continuously shift from mutual adjustment to skills standardization and back to mutual adjustment. Depending on the environment and nature, various parts of the organization will grow - operational core, technostructure, mile line, support staff, and rarely strategic apex. [10] In the case of socio-informational, the operational core, support staff, and middle manager represent the largest structural elements of the systems. The design approach for the efficient operational core of the socio-informational system proposed by Manuel Pays and Matthew Skelton defines organizational constructs, communication, and coordination patterns that depend on the human cognitive load. [11]
We can see how the coordination mechanics evolve along with the organization's growth. The competitive environment in the technology business force companies to grow to adapt the product to the changing environment; therefore, the number of informational system components and a number of people grows, increasing social interactions and cognitive load to the efficiency ceiling when adding more people doesn't add more productivity. This is when organizational transformation happens since the system wants to survive.
Following mechanistic and organic organization structure classification, we proposed a simplified representation below. [12] In small organizations starting the development of an information system, we can observe organic forms with flat and cross-functional structures that don't need additional administrative organs or support. When the number of information system components grows, the socio structure changes doubling, tripling, switching to a hierarchical structure, and becoming more mechanics. Once it reaches the ceiling of efficiency, it tends to transform into an agile, organic structure again.
From organizations as machines
To organizations as "organisms"
teams
Figure 3. Schematic diagram of organizational paradigm evolution
Evolution of the socio-informational systems
Let's take a look at the evolution of information system architecture and put it into the context of social construct producing digital/informational products of correspondent architecture.
The general pattern that the development of systems is in the direction of increasing degree of dynamicity is applicable to the socio-informational system.
Figure 4. Transition from solid to agile state
Building a parallel with information system architecture, we can highlight trends from the monolith to multilayers, microservices, and serverless architecture. This trend of system granulari-zation has one key driver - speed, the number of change implementations within a time frame. If a digital product got a market fit, then the company that satisfies the most users' needs in the fastest manner without quality tradeoffs wins the market. So, we can generalize that information system architecture is driven by the competition pressure within a specific industry/field/domain. Michel Porter conceptualized these thoughts in the five factors defining the strategy for an organization, which applies to the socio-informational systems as an example of any organization creating value for its consumers. [21]
Figure 5. Information system architecture evolution
As we laid out earlier, product architecture defines the social construct of the organization producing it; therefore, we should also adhere to the trend of organization architecture evolution. Below we schematically outlined a typical organizational structure supporting various informational system architectures.
Figure 6. Team composition associated with information systems architecture
Let's consider the beginning of product development. Usually, a small team starts a development, and often the architecture gravitates toward a monolith pattern when all layers are tied together to some extent; If any part of the system changes, the whole system should be rebuilt and deployed. And everyone knows every element of the system to make a change.
Along with product success, the demand for features is growing; therefore, the pressure to extend the engineering teams increases. At the same time, the flat structure doesn't provide efficient
coordination and scaling. Team decomposition and designated ownership become inevitable. The borderline of the team decomposition has its origin in an architectural construct and often falls into the layered pattern like client-server when data and business logic are decoupled from the user interface. To accommodate such decomposition, the social structure often fell into a functional pattern, where we have teams responsible for the change implementation at the specific layer. Once we have several teams, the coordination layer comes into play to make sure the changes are integrated properly without defects.
If the product success continues, the demand for features grows even further; therefore, the number of engineers grows, and consequently, the necessity to avoid code conflicts arises again. The solution is to add another dimension to reduce the elements' size further. The service-oriented architecture is the pattern of meeting such a need that has layers and components known as services. The social construct accommodates an additional dimension known as a matrix. We have layers grouped by architectural components (services). The growing number of components quickly leads to repeated functionality implemented in different ways, which is not an efficient time investment that has no impact on the development speed. Such an adverse effect is mitigated by standardized, reusable frameworks and shared services solving everyday tasks and reducing the duplication of efforts. On the one hand, the frameworks add productivity gain; however, they require more time to onboard a newcomer and add additional cognitive load along the way. The importance of the integration team becomes even more important since the number of moving pieces to orchestrate grows.
If an organization continues to grow in the described above paradigm, then the growing number of people reaches its productivity saturation point, followed by diminishing returns. Often the bottleneck is the coordination and integration layer as well as the disbalance of skill distribution to produce the value without waiting time. To solve the integration and dependency problem, the microservices architecture comes into play and emphasizes every component's delivery and deployment independence. To enable such autonomy, automation comes to the forefront of focus with common frameworks automating routine and enabling engineering freedom. The social construct also evolves: the integration team loses its demand, and components are managed by flat independent teams where specialization is not as important as before, eliminating the skill disbalance, and the automation team increases its power.
Organizations require a strong engineering team to build such an automation platform, though the skill is scarce, so not all engineering organizations can accommodate the required demand. The invisible hand of the market solves such a problem, and we see a growing number of cloud providers as well as serverless architecture that alleviates the necessity of a significant automation team. Until such a configuration satisfies the appetite for the speed of value delivery, we will observe the continuation of the trend in the cloud and serverless architecture.
Mapping of TRIZ laws of evolution and information systems evolution laws
Let's review the correspondence between TRIZ laws and laws of software system evolution to explore the overlap and gaps.
TRIZ articulated six laws [13]:
• Increasing degree of controllability and dynamicity
• Transition to a super system
• Transition to a macro or a micro level
• Coordination
• Convolution deployment
• Balanced development of the system
Leham articulated eight laws [14]:
• Continuing change
• Increasing complexity
• The fundamental law of program evolution
• Conservation of organizational stability
• Conservation of familiarity
• Continuing Growth [15]
• Declining Quality [15]
• Feedback system [15]
Law of increasing degree of controllability and dynamicity.
Such a law describes the combination of trends. The first one is the increasing control of elements along with the growing dynamicity of elements. Such trends reflect the increasing efficiency of managing feedback loops within the system. Often controllability improvement goes together with the reduction of human involvement in the functioning of technical systems. Below you can find the schematic representation of the trend reflecting the controllability improvement.
Figure 7. Transition from unmanageable system to manageable
Below, we outlined trends of increasing dynamicity among various dimensions such as time, space, or on condition.
Figure 8. Flow of increasing dynamicity degree
Making a parallel between TRIZ and software evolution laws, we observe the fundamental accordance in the role of the feedback loop. [16] E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base. Even though the trend of controllability and dynamicity was not articulated formally still, we can observe it in the life cycle of the software product; when the first version is always limited and doesn't provide enough flexibility, then along with time a program becomes more sophisticated, more dynamic, and configurable. In some cases, like Tesla, some program elements become self-learning due to contemporary artificial intelligence technologies.
1. ransition to supersystem
The system combines with another system, creating a new, more complex system. [17]
In the software, we see such a trend embodied in the Increasing Complexity and Continuing Growth laws. Increasing complexity was articulated as an E-type system evolves; its complexity increases unless work is done to maintain or reduce it. Continuing Growth was articulated as an E-type system that must be continually adapted, or it becomes progressively less satisfactory.
Both laws have negative implications for the speed of development. An example might be cy-clomatic complexity and its effect on engineering productivity [18]. Cyclomatic complexity is a software metric used to determine the complexity of a program. It is a count of the number of decisions in the source code. The higher the count, the more complex the code. Given the program's growing complexity and size, this metric also goes up, making it harder for engineers to implement a new change.
2. Transition to a macro or a micro level
According to TRIZ, systems tend to reduce in size their elements; at the same time, their selves often grow in size, power, efficiency, and other dimensions.
Looking at the evolution of information architecture, we can see the same trend. Components become increasingly granular until the lambda function in the cloud, where an engineer doesn't need to think about infrastructure, just define the function and deploy it to one of the cloud providers. Given the trend to reduce in size of the components of information systems, we observe the trend of the growing platforms to run such small apps in a number of functions provided, scale, availability, and other characteristics.
3. Coordination
According to TRIZ, coordination and harmonization of the internal elements of the systems require to minimize negative effects and make the system more efficient. The Lehman law of declining quality suggests that internal coordination and harmonization of elements - the quality of an E-Type system will appear to decline unless it is rigorously maintained and adapted to operational environment changes. Therefore, to avoid the quality erosion of the system, engineers undertake special techniques of various test automation.
Coordination can happen not only within the system but also between the system and the environment. This is exactly what we experience in information systems. According to the law of continuous change - E-Type of the system must be continuously adapted, or it becomes progressively less satisfactory. It is obvious that if demand from a customer is not addressed, then the customer will look for another solution.
Here is another both internal and external system coordination aspect specific to information systems known as "Conservation of Familiarity law". Leham suggests that as an E-type system evolves, all associated with it, developers, sales personnel, and users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves.
The laws of continuous change and conservation of familiarity are laws affecting qualitative attributes of the information system but can be resolved outside the information system only since they are related to people and the socio realm. Therefore, if we produce an information system to make it efficient, it is not enough to consider only the architectural characteristics of the system; it is essential to design the social construction delivering, supporting, and evolving the information
system. We assume that this observation will be relevant for other technical systems; therefore, we consider this a new element for the TRIZ system.
Given the definition of the socio-information system and empirical confirmation of Conway law, we believe it is expedient to consider an extension of the TRIZ apparatus with such a law for the scope of informational systems. And do empirical research on Conway law relevance for the broader category of technology systems.
4. Convolution deployment
Based on TRIZ, the Law of -convolution-deployment is such that any system during its development collapses or expands its functions and components.
Analogous law in software is the law of Continuing Growth that we attributed to the transition to the super system, though it is also applicable here since reflecting the notion that the system, if not appropriately evolved, losses its value for users and becomes obsolete. We can see a plethora of such cases in software. Sun Microsystems doesn't exist anymore, Yahoo lost the market of internet search, Microsoft closed its mobile department, and the list can go on.
5. Balanced development of the system
System elements' development is imbalanced, and the more complex system, the less balanced development is, TRIZ suggests. The third and fourth laws of E-Type of software systems evolution support TRIZ balanced development and suggest that there is an intrinsic system dynamic of socio-informational systems that enforce the balanced way of system evolution. Self-Regulation law says that E-type system evolution processes are self-regulating with the distribution of product and process measures close to normal; and Conservation of Organizational Stability says that the average effective global activity rate in an evolving E-type system is invariant over the product's lifetime. We could argue that these laws reflect the dynamics of growing information systems. When the stakes of success and failure go up, the social system tends to minimize large disruptive changes that could lead to instability of the informational system. Therefore, along with the growing number of engineers, the individual engineering productivity rate goes down, so the overall rate of change tends to be invariant to the number of people and defined by the informational system architecture. Changing both informational architectures as well as the architecture of a social system could yield a productivity change.
CONTRADICTIONS
As we saw above, social and technical systems are complementary, and one cannot exist without another. The information architecture might be brilliant, but its implementation will depend on the social structure that depends on the people's ability to produce the work. It is not possible to increase the number of people infinitely since they need to interact with each other. And people's capacity is limited by the number of social interactions one person can handle, known as the Dunbar number [19], and cognitive load limits [20] that restrict the ability to do the mental work that is the core of information system development. Without such limitations, any organization developing an information system, even a tightly-coupled monolith, might scale infinitely. Since we have people within the system, we cannot scale system development without addressing information architecture.
DISCUSSION FOR FURTHER RESEARCH
Exploring socio-informational systems beyond the primary work boundaries is expedient, specifically, at the whole organizational and macro-social levels. Such research might reveal laws, trends, and implications for our that established organizations and technology entrepreneurs can take into account to amplify positive effects and mitigate adviser effects.
Another consideration for further research is validating the hypothesis of whether a Conway law can be attributed to the broader category of technology systems, which will support its adoption beyond socio-information systems, as we proposed above.
We also consider validating the hypothesis that only joined and balanced changes in the informational and social systems could positively impact productivity. Whereas independent changes in an information system of a social system most likely result in a negative productivity trend.
CONCLUSION
Such research revealed the importance of new socio-considerations for analyzing and designing information systems and their delivery mechanics. That became even more actual with the growing dependency of humanity on the informational systems; therefore, we should find a way to properly balance and harmonize socio and informational systems together, minimizing adviser effects related to their evolutions. Quality degradation, growing complexity, conservation of familiarity, and implications of the team composition, these challenges related to the people aspect and without proper address could lead to an irreversible situation with mission-critical systems that empowers healthcare, self-driving algorithms, aviation, etc. We have also shown that socio-informational systems follow the TRIZ evolution laws that can inform the decision-making of people in charge to manage the end-to-end life cycle of such systems properly.
Even though the combination of socio systems and technology systems is the field with a solid research foundation, we believe there is great potential for further research on the combination of socio and informational systems across all levels of production, organizational as well as a macro social one. The authors intend to continue research in the mentioned area.
REFERENCES
1. Gordon Baxter, Ian Sommerville Socio-technical systems: From design methods to systems engineering
2. Trist, Eric L. The evolution of socio-technical systems. Vol. 2. Toronto: Ontario Quality of Working Life Centre, 1981
3. Lehman, Meir M. "Programs, life cycles, and laws of software evolution." Proceedings of the IEEE 68.9 (1980): 1060-1076.
4. Maturana, Humberto R. "The organization of the living: A theory of the living organization." International journal of man-machine studies 7.3 (1975): 313-332.
5. Baxter, Gordon, and Ian Sommerville. "Socio-technical systems: From design methods to systems engineering." Interacting with computers 23.1 (2011): 4-17.
6. MacCormack, Alan, Carliss Baldwin, and John Rusnak. "Exploring the duality between product and organizational architectures: A test of the "mirroring" hypothesis." Research Policy 41.8 (2012): 1309-1324.
7. Petrov, Vladimir. TRIZ. Theory of inventive problem solving. Springer International Publishing, 2019.
8. Youndt, Mark A., Mohan Subramaniam, and Scott A. Snell. "Intellectual capital profiles: An examination of investments and returns." Journal of Management studies 41.2 (2004): 335-361.
9. Wohlin, Claes, Darja Smite, and Nils B rede Moe. "A general theory of software engineering: Balancing human, social and organizational capitals." Journal of Systems and Software 109 (2015): 229-242.
10. Mintzberg, Henry. Structure in fives: Designing effective organizations. Prentice-Hall, Inc, 1993.
11. Skelton, Matthew, and Manuel Pais. Team topologies: organizing business and technology teams for fast flow. It Revolution, 2019.
12. Burns, Tom, and George M. Stalker. "Mechanistic and organic systems." Classics of organizational theory (1961): 209-214.
13. Petrov, Vladimir. TRIZ. Theory of inventive problem solving. Springer International Publishing, 2019.
14. Lehman, Meir M. "Programs, life cycles, and laws of software evolution." Proceedings of the IEEE 68.9 (1980): 1060-1076.
15. Lehman, Manny M. "Laws of software evolution revisited." European Workshop on Software Process Technology. Springer, Berlin, Heidelberg, 1996.
16. Lehman, Meir M. "Feedback in the software evolution process." Information and Software technology 38.11 (1996): 681-686.
17. Souchkov, Valeri. "THE LAW OF SUPERSYSTEM COMPLETENESS." TRIZfest-2017 (2017): 399.
18. Gill, Geoffrey K., and Chris F. Kemerer. "Cyclomatic complexity density and software maintenance productivity." IEEE transactions on software engineering 17.12 (1991): 1284-1288.
19. Dunbar, Robin IM. "Neocortex size as a constraint on group size in primates." Journal of human evolution 22.6 (1992): 469-493.
20. Sweller, John. "Cognitive load during problem solving: Effects on learning." Cognitive science 12.2 (1988): 257-285.Porter, Michael E. "The five competitive forces that shape strategy." Harvard business review 86.1 (2008): 25-40.
