The Systems Thinking Architect

I was recently visiting a client and presenting a case study on the value of architecture. As I glanced across the room, I had noticed the “business guy” look at me inquisitively and said something similar to the following:

“We do not need architects, they spend too much time pontificating and telling us that we are not in compliance.”   

Then one of the software developers chimed in and said:

“We are an agile shop. We cannot afford spending valuable time on developing architecture.”

We in architecture profession have a great deal of work ahead of us to undo the perception and stigma that architects have been given. You guys are the "gatekeepers of technology, and ivory tower model builders." Ack!

For the past six years, I have been researching and advocating how “systems thinking” is the new essential competency around architecture. After one of my last Zen and the Art of Architecture “talks” at Microsoft, I received some strong feedback from someone who was a long time enterprise architect and said that system thinking was useless and had no “engineering” behind it.

I do understand these reactions because it goes counter to how many of us have learned to view the world. So how are we taught to understand the world? As a kid, I tried to figure out how something works by taking it apart or in some cases… smash things to pieces. This is no different to how the CERN research center's Large Hadron Collider (LHC) is attempting to find out what matter is really made of. How do they do it? By smashing particles together in order to find the most elementary particles of matter, perhaps to discover the ever allusive G-d Particle (Higgs Boson). So we break things up to determine the essential structure (particles) of matter, but there are behaviors (forces) that go with that structure that have to be also observed. But the even the most elementary understanding of matter, it cannot describe how we humans that consist of trillions of atoms behave as a whole. We are clearly more than the sum of our parts. Even our own subsystems: nervous, circulatory, skeletal, immune, etc. do not adquately define us humans as a whole. We as a system consist of several subsystems that are intergated. When they all function well together, we are capable of amazing things. The fact that I am typing this blog is an extraordinary event that requires the function of many systems working together... but that is for another blog.

So we are enamored with structures. The structures of business, the structures of IT, the structure of projects, etc. We manage the performance of structures. But do we really measure the performance of behaviors? If the average business person is interested in results, and the architect is overly focused on the beauty of his/her structures. We have a problem.

The late Dr. Russell Ackoff understood this very well. He was a pioneer in systems thinking and organizational theory. Here is an article from him that you may find useful:  https://www.pegasuscom.com/levpoints/ackoff_a-lifetime-of-systems-thinking.html

To summarize Dr. Ackoff brought clarity to the following:

• Each element of the system can affect the behavior or the properties of the whole. The behaviors of these elements may or may not be synchronized. The behavior of the system as a whole evolves through emergence.
• The way each element affects the whole depends what the other elements are doing. All structural elements aren’t completely independent; there is an element of connectedness. 
• Grouping elements of the system into sub-systems, they have the same properties as the elements. The collection of elements and its structure can affect the whole.
• The performance of a system is never a sum of the performance of its parts taken separately; it’s the product of its interactions. The performance of a system is based upon how the parts interact and fit, never on how they act separately.

We all too often solely rely on the analytical and engineering methods of the manufacturing era of Henry Ford’s mass production systems. The prevailing mindset comes from bringing efficiency by the optimization of parts and labor. My architect colleagues have been discovering that we are not making a measurable improvement on the performance as a whole if we use this approach. Mature architects know that there is a balance to the system, and in order to understand balance one has to see the context and the whole. An architect will optimize an element only if it improves the whole, and will sacrifice an element if the whole benefits. The objective here is to design the best system given all the constraints, not engineering the best elements. 

In studying “Eastern Philosophy”, one may notice that this goes counter to Western thought. Western thought is overly focused on the engineering of structures and in order to understand the structures we break them up and divide and conquer. We focus on the current answer, the subjects and objects.   The Zen philosophy focuses on harmony. Harmony of structure and behavior. This notion is completely counterintuitive in today’s business, we have managers that govern the behaviors and actions of the various elements within their organization by scorecards that are unidisciplinary and tend to ignore interaction or transdisciplinary aspects between other organizational elements.  

In what may seem a paradox, bringing “agility” to projects requires breaking down the problem into semi-autonomous modular chunks or work. By doing so, one can minimize risk and add value incrementally over time. In this new world, incremental change will be the norm projects may evolve into containers of work, that have bounded goal and objectives for the proposed transformation without getting determining people, process, and technology required to execute these modular units of work.

So in this world of constant change and managing against scorecards, who is looking out for the whole to ensure that interactions of the organization (people, process, and technology) to ensure continuous improvement and performance? How does one manage towards the end game? Management squeezes efficiency through optimization of parts? But the real issue is that is the organization effective?

The work culture today is based on analytical thinking. We analyze structures and how they work, but we never seek to understand why things behave in manner the do?

Analysis has been the heart of classical science. The scientific method assumes that whole is nothing put the sum or the parts, and thus understanding the structure is both necessary and sufficient to understand the whole. Efficiency through analysis.

Synthesis is about understanding the behaviors by examining functions and process. By defining the system by outcomes, synthesis puts the “subject” or “active structure” in the context of the larger system of which it is an element or part, and the examining the effect it produces in the environment. By examining functions and processes together, we can answer how things get done in order to understand the whole. Effectiveness through synthesis.

The pure ontological approach which we architects have invested so much in has set us back with our endless models and classification of structures. With John Zachman's most recent release of the the Zachman Framework, he now calls it the "Enterprise Ontology." But what is more interesting to me is how Zachman's cells work together and are related. It not only about data, information, or knowledge. It is about business understanding and wisdom. These are far more valuable to a business today. They need to make effective decision based on information and knowledge in order to promote understanding and organization wisdom (a.k.a. intellectual property). Therefore there is an epistemological approach that is also necessary, where one seeks to understand why something is the way it is, and how knowledge and eventually wisdom is obtained.

Therefore if you want to understand what something is and how something works you use analysis/ontological methods, if you want to understand why it works and who/where it impacts you use synthesis/epistemological approach. To be effective we should be using a combination of both. See the duality here and the harmony? 

We clearly need to move away from the architectural style that suffers from analysis paralysis and the ivory tower mentality godlike attitudes where this only one way to get the job done. We have to comfortable with concepts of complex adaptive systems like self-organization and emergence by understanding the whole. An architect has to be viewed as the additional stakeholder by all those who manage and create the elements/parts of the organization.

At Microsoft we have been contemplating modern architecture, and understanding what are the competencies of the modern Zen-like architect. Here is what she will be doing in the future:

• Leader of an integrated team of business visionaries, designers, operators, and, most important, a wide variety of points of views and opinions.
• She thinks broadly, integrates details of her solution with well-understood outcomes, and moves fluidly between realms.
• She sees connections and solutions between cross-cutting issues, synthesizing answers that rely on the knowledge and experience of her collaborators, but catalyzed by her multi-dimensional view of the business problem.
• She shifts easily from the contextual to physical, from the building of business models, to the dynamic data center, guiding her project toward well-defined, well-understood, and innovative results.
• She designs process as well as built structure and objects, and understands the behaviors of not just software and information, but organizations and teams. She has been educated to see the result of design as not just a solution, but a series of outcomes. 

Our goal as architects is to bring harmony to the enterprise by allowing businesses, customer, and partners to use systems beyond what we as designers have envisioned. We accomplish this by being more effective; and finding the balance of the discpline operational excellence and giving users the freedom to accomplish their goals. That is required to keep the next generation of business/user systems vibrant and efficient.

Happy architecting.

Comments

• Anonymous
  February 12, 2013
  Alan, I believe that the perception and the stigma are fully deserved. Some of the reasons I explained in these two posts: a recent www.strategicstructures.com and a two-year old one www.strategicstructures.com. "I received some strong feedback from someone who was a long time enterprise architect and said that system thinking was useless and had no “engineering” behind it." That's veeeery strange! Normally the systems thinking, with the exclusion of SSM, is attacked for being "too engineering", not organic enough. And indeed, when one sees Systems Dynamics stock-and-flow diagrams or cybernetic models, one can notice a lot of symbols borrowed from pneumatic- for the former and electronic engineering for the latter (notably filters and amplifiers). But with so many usage in biology, ecology in economics, one can easily see that these models are equally applicable to both the born and the made and systems mixing the two. Now, an opposite statement that systems thinking has no "engineering" behind it reveals no knowledge about either systems thinking or engineering. And if that's coming from somebody in IT, that's really a shame as IT owns everything to people like John von Newmann and Claude Shannon and they are real system thinkers, just not being called so for the phrase was coined later. "The late Dr. Russell Ackoff understood this very well.  He was a pioneer in systems thinking". With all respect to Ackoff, systems thinking started much earlier, before even he worked in operations research, which by the way is quite reductionist. "The pure ontological approach which we architects have invested so much in has set us back with our endless models and classification of structures." Ontological approach, in both philosophical and semantic-web sense is a very valuable one. However, it is not truly practised by Enterprise Architects. What some frameworks offer are classifications, which could be called 'taxonomies', and others - meta-models that have some pretence of rigour. But they use expressions like UML class diagrams where there is no way to check for semantic consistency. There are of course checks called "semantic" but hey only test again the rules of UML, not the logic of the assertions.