Although I have been practicing enterprise architecture for more than 10 years, I still find it challenging for me to explain to others what exactly I do.   I am a systems designer and engineer at heart, but not necessarily in the way in which a typical IT function defines “systems.”    I feel what I do is an amalgamation of engineering, design, science, psychology, economics, physics, biology and philosophy.  Once in a while I throw some quantum and statistical mechanics just for fun on the days where I perform some deep thinking.   Then it comes to mind, if I have trouble communicating what I do, then how the heck am I going to represent myself to a client and offer my services?   Which then forces me to ask the larger question.   How do we as enterprise architects effectively communicate to business management and leadership?   Many business managers or leaders perhaps have not studied those disciplines, or if they did they have long forgotten them as they have been bogged down by short term focused metrics and day-to-day or quarter-by-quarter objectives.

While it may be difficult for us to describe enterprise architecture, many of us including myself do not have any trouble defining why it is valuable.     The business climate is changing rapidly, thoughtful business leaders are starting to recognize that there are some deep persistent problems that are not being addressed or solved.   Often in our attempts to solve or govern them, we are actually causing more harm than good.   Also when business managers believe problems are not-solvable, they actually fall back on what they know how to do:  govern through policy, procedure, and politics.    This resistance and tension is common where leaders desire to do the right things and managers desire to do things right.

The root of the problem is that business managers are very tactical and focused on keeping “the wheels on the bus.”  They are event-driven and may react quickly based on the reductionist, cause-effect worldview that most business people comprehend.   What is surprising to me is that business managers tend to treat negative events as something that just happened, and were completely out of their control.   This in fact in many cases is just not true.    Many so called black swan events were actually triggered by siloed and narrow minded thinking of a few individuals, without regard to the whole.   This has lead to a series of small negative events which occur in a narrow window of time, which serves as fuel for a sudden catastrophe.  Often, when looking back, one may have be able to stop or dampen one of the negative events, if they saw the larger picture.  They may have been able to absorb some small pain as a trade off.   A catastrophe is avoided but there will be someone has to be held accountable.   Obviously, no business manager of a particular business function unit will say, “I am going to take one for the team for the greater good of the enterprise.”      

Most business managers feel that they have the right mental model for running their business, within their context.    They often can say:  "everything is great!  My scorecard is green this quarter, and the numbers are trending up, so why do I should I listen to you?  You  <insert personal derogatory insult here>."    Well unfortunately I have heard that logic before, then when things suddenly go red, the blame game starts.   What is surprising, many holistic systems thinkers were able to foresee the consequences of black swan events before they occur.    In many cases when the black swan event does occur, there is either an over or under reaction both either by tactical tool fixes or throwing by up their hands and saying “Sh*t happens!” or my personal recent favorite “It is what it is.”    Perhaps there is no such thing as side effects, just effects?    Admittedly there is a paradox.  A complex dynamical system is difficult to predict by its very nature, but perhaps they can be more deterministic if one has a more holistic view and a better understanding of the system and its behavior over time.    

Systems modeling is a technique that can make a system more deterministic.    There has been a lot of talk about models recently by very well-respected practitioners of Enterprise Architecture including Nick Malik, Tom Graves, and Richard Veryard in the #entarch Twitterverse and Blogosphere.   There is general consensus that there are good models and bad models.   All models are imitations of the real thing, therefore as with anything it has limits.   What makes a model useful is the level of approximation on how it reflects reality and how it is communicated.    The mapping of equivalence classes between structural elements (information) and the mapping of functional transitions between behavior elements (algorithmic/computational) must result in useful homomorphism.    Homomorphism is required to map the space of the real world and the space of the model world in way that can be communicated.  The language and grammar that I am using for this blog is in my native tongue English.   You can judge whether these words are useful or not to your reality, and if you understand English; all the better.    If you do not understand English, then this blog is not useful for you.   But perhaps if I translated it into a different language or grammar, it would be more useful to a different audience.    Articulation of language and grammar are critical to model usefulness. 

 

Models obviously will never have perfect fidelity to the real thing, but they do attempt to establish some boundaries on what structural variables and behavioral algorithms are exogenous versus endogenous to the system.    This is not always easy to do.   Some factors that are exogenous often influence the system, even though the system has no control over that variable or algorithm.   One can make an argument that almost nothing is exogenous.  Although it is very useful to determine eliminate extraneous variable.      Endogenous variables may also produce their own phenomenon which can produce feedback, both positive and negative from within the system.     Often model boundaries (or frameworks) can get us into trouble as they artificially limit thinking, or as I recently read “places invisible fences in the mind.”   Unfortunately our brains have been trained to see cause and effect in relation to space time.   The challenge is sometimes it is very hard to wrap our minds around things that we cannot correlate and infer.    Cause and effect can be difficult to see within the narrow window of space time in which we view the world.    System dynamics teaches us to expand the boundaries of our mental models and broaden the horizon of space and time.   This can allow for us to see patterns of behavior and phenomenon that are created by in many cases simple structures and feedback.   For those of you who are interested in this, I would recommend Binging “cellular automata” and “The Game of Life” simulation for examples to see how a system can evolve with simple rules in ways that surprise us. 

This brings me to the next topic of simulation.     Simulation is a very powerful tool for enterprise architects to help communicate and reach business managers to help them foresee the consequences of action or inaction before a new solution or policy gets implemented.     It is also useful when it is difficult to articulate a complex problem, and why action is necessary.     As mentioned earlier, it is next to impossible to comprehend and mentally derive conclusions on systems that exhibit complex, dynamic, non-linear behavior.     Even very simple simulations can validate or invalidate models based on how they approximate the real world or produce surprises.   The beauty of using computation and information with simulation is that you can expand time in interesting ways.   Situation tools all for us to “guide thought” and “provide reasoning” on how the feedback of soft variables influences the system in question.    Feedback is essential to learning and experimentation.   Simulation allows for the model to evolve over time more rapidly, especially when experimentation in the real world is slow, too risky, and not cost effective.    It allows for us to examine the world in which is highly interconnected whose dynamics are growing.   

If enterprise architecture wishes to fulfill its promise of delivering value-oriented business outcomes, a different approach to how we use models and frameworks is needed.   Models and frameworks fail when we DO NOT ask the right questions on the suitability to purpose or we eliminate variables that we feel are irrelevant, or we do not have the data.  We as enterprise architects often use models to prove that we are CORRECT or to generate acceptance and build consensus with various business constituencies.    This is not a path to success.    What does work is when models are shared and co-developed with your clients.   Your constituencies will discover flaws, inject their own mental and formal models, and will work with you to improve them.  Perhaps via simulation as mentioned above.   Shortcomings in models are good things, they provide more opportunity to learn and improve model fidelity which increases chances for successful and beneficial outcomes for the clients we are paid to serve.

When we work together with business leaders, we as enterprise architects are better equipped to understand business phenomenon and how the dynamic and complex nature of people, processes, and technologies actually can be harnessed and embraced rather than viewed as something to manage, govern, and control.   Our business clients want to better understand their process flow and information.   They need our help, to help maximize value.   Obviously the nature of dynamical systems are complex and very difficult to predict, and yet the business has a desire for resiliency.  Co-engagement with your clients will allow for balanced conversation around agile delivery of improved business capability with modern technology functionality and predictable operational discipline.

We as a profession have to look forward and think on how we evolve our existing frameworks and models beyond what we use them for today.  We must strive to make our thinking visible, so that it is accessible to a wider array of people, not just other architects.  It is time for us enterprise architects to get out of our boxes in our cushy offices and work alongside with our clients.  To open our minds and discover how they prefer to work and conduct business.    This mindset has completely changed my perspective and outlook on how I approach my beloved craft of enterprise architecture.   

If you have thoughts on systems thinking and modeling enterprises for a complex world, I would love to hear from you.