The Antifragile Enterprise: Complexity Exists, but Let's Not Overcomplicate it or IT.

The Enterprise is a complex system. I have accepted that fact. I think many of us in the enterprise architecture profession have also accepted this fact as well, or at least I hope we have. But then again there is natural response to things in which we do in order to address "complexity." There is a tendancy to build over-governed solutions that try to “manage” complexity or uncertainty. In addition an architect can design an overly complicated solution through “best of breed” components cobbled together from various vendors in order to make it resilient, or provide the “ultimate set of functionality” that their constituencies would surely love. My clients have been frustrated by the lack of understanding and awareness that IT professionals and IT vendors (including Microsoft) have been with respect to understanding of how business gets done.   

The result has been to plan, design, build, implement, deploy, and operate these complicated silo-ed solutions that deliver a set of functionality that may or may not be aligned to business capabilities. How often do we understand how our solutions directly effect the throughput of our own organizations products and services? As we enter the modern computing age of big data, cloud, business analytics, consumerization, disruptive technology, volitale marketplaces, etc; information is becoming the new currency on how the enterprise conducts its business. The reality is that there is a significant amount of “value” of information that largely remains untapped and underutilized the enterprise. Alas, the opportunity for modern enterprise architect!

This siloed approach has brought with it a rigid solution that cannot be easily adapted to changing processes or whose information cannot be easily integrated with other systems. There is a good chance that it was architected perfectly, but perhaps the value of the solution was transient or minimal because no one could figure out how to leverage it to its maximum potential.

As I just finished the book Antifragile by Nassim Nicolas Taleb. What he characterizes as “antifragile” is that category of systems that not only gain from chaos and entropy but require it in order to survive and flourish. This has again reaffirmed by belief that these siloed solutions that enterprise architects and other IT domain architects have built over the last 10 years are very “fragile.” They do not thrive in an environment that has entropy or stress. They are designed to minimize “agents” that will be stressors to the system. The end result is a solution/system that is temporarily “fit for purpose" where the end users are treated like a transactional component of the solution rather than an entity that actually engages the users of the solution in meaningful ways. So how can we think approach the topic of building an “antifragile” enterprise? First we have to accept Mr. Taleb's assertion that this notion goes beyond building as system for resiliency. The system has to be built to accept micro amounts of stress or entropy in order to thrive. This is akin to how systems in nature thrive. Therefore stress should be treated as a positive event, not one that an architect should shy away from. But there is a second aspect of this stress. There has to be amount of observation and feedback into the system/solution in order to “comprehend” the stress. The capture of these events allows for the modern enterprise to incorporate the experience into the collective knowledge or the “muscle memory” or the organization. The learning organization comes directly from the practice of systems thinking. Therefore, I am making my own assertion that building an “antifragile” enterprise is one that knows how to exploit information effectively through the application of modern technology.

One of the beautiful aspects of nature and complex systems is the notion of a loosely coupled-layered architecture. Layering provides autonomy of certain “processes” or “activities” than can conducted with a degree of isolation from other layers. Each layer can tolerate an amount of entropy or micro-stresses. I have referred to these layers in previous blog entries as fabrics. These fabrics have elasticity and have highly interconnected nodes. By layering these fabrics, one can build more “rich” experiences, especially for those who are consuming those fabrics at the very top. This builds antifragility.  

So for the moment permit me to focus the business layer and how information is critical to this fabric. In order to design and model the enterprise effectively, the enterprise architect has to understand the set of “operations” that can be against information. How is information acquired, manipulated, disseminated, reported, acted upon, stored, etc. The information flow within the enterprise is aligned directly to business process. Information is the lubricant to business processes. If information is available and can be readily exploited by the “actor” that is associated with that process, then the execution of the process can be done with speed, better accuracy, and the right impact. So the question that naturally comes to mind for the enterprise architect how to align business capability to solution functionality. Whether your business is IT, or your business is to support other core business functions is irrelevant, each business function within an organization provides a set of capabilities to support a consumable product or service either for consumption by an external or internal entity. So another assertion here is that, one has to understand HOW INFORMATION is consumed, rather than obsessing on how INFORMATION is provided. By examining the lifecycle of information, and treating as valued asset can bring with it the desired effects of innovation, aligned products to marketplace, quality of service, and a more happy workforce.

I do not want to paint this as something that is easy to accomplish. It is not….we has enterprise architects live in a world where most organizations have the design paradox of complicated bureaucratic governance structure while balancing the diverse set of functionality required to conduct business. These are competing forces which requires management leadership to understand this tension on how to balance centralized control yet give freedom and autonomy to the actors of the business. Culture is a huge part of this. (That perhaps is for another blog.) In the meantime I hope that we as enterprise architects can be more advocates on the study of the enterprise as an antifragile complex system. I do believe this requires us to apply the modern architecture style where form follows function, and bring organizational harmony by balancing governance and improving capability though the use of information.  

As always I am interested in your thoughts. Happy architecting…