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.

Overall, a _really_ useful post. A few things I'd add to this, though, some of which I may blog about later….

First is that in most cases these aren't true 'black swans' – something never known before. More often, they're what's known as a 'kurtosis risk' – a low-probability _yet known_ risk that has the potential to wipe out all of the apparent gains made from (deliberately) ignoring them. They're very common in bad customer-service, for example – sometimes as an industry-wide risk I sometimes as 'pass-the-grenade', because when (not 'if') it explodes, whoever's holding it at the time gets the whole of the pent-up anger from bad customer-service etc from across the _entire_ industry, not just their own little bit of it.

Next, "Systems modeling is a technique that can make a system more deterministic", you say. Well, yes, that's sort-of true for 'hard-systems' theory; but it's rarely so for 'soft-systems', in the kind of complex social contexts that we invariably hit at larger-scope EA, beyond IT alone. For the latter, we're well aware that _nothing_ will make the system "more deterministic" as such: instead, the role of modelling is more to develop _shared-understanding_, bring hidden-assumptions to the surface, and suchlike, such that people do start to have real choices.

"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." Again, that's a 'Yes, sort-of…'. There are huge dangers from over-simplification and, again, hidden or unaddressed assumptions, leading to models that don't actually match up with the _real_ context. The modelling needs to take explicit account of the fact that the model is, at best, only an approximation, and that we need to be careful to allow for that inherent-uncertainty in every way that we use the model.

This _especially_ applies to simulation. Personally, I'm really wary about use of simulation in anything other than strictly physics-based context, and even there I have my doubts for _real-world_ use. To me, the main use of simulation is not to try to 'predict' the system, but to use it to elicit 'What's missing?' discussion – particularly around use of stories and anecdotes, which tend to be far better than simulation itself at finding the things that _don't_ fit, and that therefore could invalidate the assumptions on which the simulation is based.

Enough for now: hope that's useful, anyway? And more to talk about somewhen, perhaps?

Wholeheartedly agree on the point of going closer to our customers. Nobody likes a nerd who cannot get his point across. Thus mastering the art of compassion, understanding, while retaining patience is a must.

You made a great point about a language and the fences on the mind. Being fluent in 3 and understanding other two, I can attest that these fences do exist. That is evident when you try to translate something difficult, like an idiom. That requires a mapping between two complex phenomena, involving hundreds or thousands of neurons. Easy for the brain, hard for a model.

Tom, I agree with a limited application of a simulation and usefulness of anecdotes. It broadens the number of factors and uncovers the assumptions, which rarely can be achieved by a formal analysis session.

Some points of clarification. Systems modeling works for both hard and soft systems, although there are some differences in their techniques. From my experience, using agent based approaches typically works from the bottom up, modeling hard systems are typically are decomposed from the top down. I do agree that models are approximations, and their limits must be known and understood. The idea of determinism is around the probability of outcomes, typically around a distribution curve.

Not all models have to be simple, although some simple models even yield very surprising and complex results. (See Game of Life, Cellular Automation.) Models do at come level have to be understood, and if it is overly complicated, one can break into smaller models and aggregate them together and use computation as a method. This gets me to simulation.

Simulation is a very powerful tool when used in the context of business dynamics and enterprise architecture. My colleagues and I have been using simulation very successfully to help understand what is working, what is missing, and to plot a course of action. I am happy to have a deeper discussion on this.

A very useful and interesting post – thanks for taking the time to write it.

Like you, I've been involved in systems design and enterprise architecture for many years now. The real challenge that I've witnessed over the years (on many projects in many different industries) has been 'how to ensure that technology delivers *value* to the business and doesn't actually make things worse ! Many times I've witnessed large scale, expensive Programmes being launched -with no baseline understanding of what the current business performance actually is and thus no way of knowing whether the all the changes, technology and money has actually improved things !

Shewart charts can help here – but equally important is the ability to have an awareness of the concept of a wider system and to adopt different perspectives – such as the customer viewpoint – when trying to understand how well the system (business environment) goes about achieving its purpose. Bear in mind of course that different business have varying purposes. – a manufacturing plant is very different to a call centre !

Your point about getting closer to the customer is really important and reflects a statement made by Tachi Ohno (designer of the Toyota Production System) – who, when speaking to new managers said, "If you're not washing your hands six times a day you're in the wrong place" – by which of course he meant, to really help and improve the business, you need to understand first hand how it works (goes about its purpose). You'll get the best view of this on the factory floor, not in your office !

The elements of perspective and purpose are critical to creating an effective architecture. Note I used the word 'effective' where the current trend in business seems to be to use the word 'efficient'. There is a world of difference between these two. A business can very efficient bit also very ineffective (in achieving its purpose).

To put it crudely, many business do the wrong thing but very smoothly (efficiently) , using technology to automate the inefficiency, speed the whole process up so more inefficiencies can be delivered within a shorter period of time !

Many people say that the IT industry is mature. I disagree. Perhaps the tools used to create the technologies have matured, but how we actually use technology in business and how we measure its effectiveness lead a lot to be desired. Too many silos still exist in companies; with accounts separate from IT in turn separate from manufactureing, purchasing etc. The poor old customer is generally kept in their own silo ! Until we break these down and start to try and understand the connected picture – IT will struggle to provide tangible value and business will struggle to understand whether it is helping or hindering them in their efforts.