The Enterprise Architect as Enterprise Ecologist


The increasingly complex systems nature of enterprise organizational and information technology design is creating an interesting disruption — and opportunity — for the role traditionally known as the “enterprise architect.” And it is a shift that, by its very nature, puts the very use of the term “architect” in question.

In the past, I’ve suggested the term “enterprise product manager” to describe what the enterprise architect is really being asked to do, but I now think there is a better term that explains this complex (and, quite honestly, complicated) role. This term is born from the observation that those responsible for the overall business systems now have to act more like scientists than like architects. There are certain “systems” sciences that their field now most resembles, and my personal favorite is ecology. Thus, I like the term “enterprise ecologist”.

The enterprise as ecology

Let’s explore the most important way that enterprise design is like the science of ecology. The use of systems science and practical offshoots, such as systems thinking is increasingly imperative. While so-called reductionist thinking–breaking a complicated problem down into its component parts and studying how each one specifically acts within the whole — is invaluable at certain scales, such as individual deployable components, it falls apart as one studies complicated systems as a whole.

The alternative, expansionist thinking, is more “up-and-out” in nature; start with a component within the system and work “outwards” from there. One way to do this is to build a graph of such interactions for each component, and use those graphs to understand the larger system. Where the boundaries of the system exist is entirely arbitrary and up to those doing the measuring, based on what is being measured. Unsurprisingly, natural ecologists do this all the time.

Also, while the goal of measuring is to visualize the system as a whole (again, to some arbitrary boundary), action can only be taken at the individual component level, or in the way a small number of component types are organized to interact with each other. One cannot “program” the system itself, as its organization is the result of hundreds–or thousands, or even millions–of individual decisions and designs. So, new techniques to affect the behavior of the system have to be available, such as injecting a new agent into a feedback loop to change its behavior, or reorganizing the relationship of certain components to alter the flow of information within the system.

This is similar to the way ecologists work to evaluate and assist natural ecosystems. The goal is to understand the ways in which elements of the ecosystem interact. Should an ecosystem need intervention, the typical approach is to attempt to direct these ecosystems by either introducing or removing elements that affect negative feedback loops–e.g. introducing laws that remove predatory danger from humans or introducing new members of species that are important to the health of the ecosystem as a whole.

The enterprise ecologist is, in a sense, cultivating the business ecology–working with specific “species” (e.g. business teams or software services) to either strengthen their place in the ecosystem, increase their survivability, or to–in some cases–identify them as being unfit. Complex systems are often simple in makeup, but almost always messy in action, which means someone responsible for cultivating such an ecology has to be ready to prune and weed.

Why not “architect?”

Why not use the term architect? Well, when I wrote about the role of the enterprise architect in that previous post, I described where the term “architect” comes from with respect to business, and how the idea of top-down systems design was applied (or, at least, attempted):

The use of the term “architecture” in this context comes, in part, from the idea that one can create a “blueprint” for how a business can run on technology. The “architect” is someone who looks at the materials available, interviews the “client” (aka the business) about desired form and functional outcomes, and engineers solutions to meet those needs.

As the corporation is a multi-”client” entity, the enterprise architect has been increasingly tasked with reconciling competing requirements to efficiently achieve form and function across the enterprise as a whole. To do this, enterprise architects were (and are) often granted control over large parts of how data, software and infrastructure are organized to efficiently address the greater good.

Of course, this attempt to elicit such centralized control has had, at the very least, mixed results. I’ve noticed some shift in the enterprise architect’s role from absolute control to informed guidance, but nonetheless the concept of top-down design has stuck at a number or organizations.

There are problems with that approach, however. As I had previously noted:

There is no way to precisely specify the design, implementation and integration of complex cloud-based application systems. So the role of the enterprise architect is no longer building and maintaining a stable computing model for the enterprise. In the age of computing as a single, global, complex system, that role has to shift.

To what? Clearly, there is the need for someone to watch over how individual applications, data sets and services evolve within the new world. There is a need for someone to guide the alignment of those software components with business needs.

In businesses that are themselves complex, there are tremendous efficiencies to be gained by the smart application of IT. That element of the enterprise architect’s role doesn’t go away.

What does change are the skills needed to evaluate how business applications, data sets and services are going to interact—and survive—in a complex, adaptive systems environment. If developers are the DNA of software in the cloud, the enterprise architect becomes the immune system, encouraging the growth of systems that help the business thrive, and killing those that would cost the business.

So, the term “architect” really falls short of describing the complex systems nature of the modern enterprise and its information technology.

In reality, I’m not advocating that we suddenly change all enterprise architect business cards to read some specific term, like enterprise ecologist, but I am asking everyone to question whether the term architect is appropriate at the scale at which an enterprise architect works.

The days of the plotter diagrams showing exactly how everyone (and everything) should work together and dictating how information should flow within an organization are, in a real sense, over. I contend we have long since entered the era of measuring and influencing the way a system evolves on its own.

Do you agree? Let me know your thoughts in the comments below, or on Twitter, where I am @jamesurquhart.



The term architect describes the role that has to describe the enterprise and apply architecture principles to its transformation. The EA role does not even design, not yet, the enterprise. EA, usually does not even include interaction between “people” and environment.
So I do not think the comparison is apt.

A couple of observations:
While the sub-title is “enterprise as ecology” the content is about “enterprise design is like the science of ecology”. “Enterprise” and “enterprise design are quite different”

The “term “architect” really falls short of describing the complex systems nature of the modern enterprise and its information technology”.
Perhaps the word was “architecture” rather than “architect”


This is all well and good, but none of it works — not the application transformation, not the IT process re-engineering or infrastructure transformation — unless you are running IT like a business and someone internally who provides executive governance. Good blog that looks at this idea here:

In addition, you need to have someone who understands the fundamental shift going on and how that shift affects all the other pieces in the puzzle. Not sure if that’s happening yet.

— KB


“The days of diagrams showing exactly how everyone (and everything) should work together are… in a real sense, over.”

The days have not even started yet because we have not succeeded to put together that integrated, navigable picture of the enterprise in which each stakeholder finds his piece in context. We are still producing disjoint diagrams that disappoint our stakeholders.
We are still struggling to agree what EA is and how do document the EA. While there are ontologies, development processes, languages… there are hardly any modelling frameworks that show what artefacts and how they link together.

“There is no way to precisely specify the design, implementation and integration of complex cloud-based application systems”.
There are ways. You just have to want to find them.


With respect to the original comment from ptr above. The comment, thinking, approach and ability to drag everything down to theory has to your point, stopped us from moving forward. Ptr’s response is typical of the EAs I have met and worked with. We need to move forward with less talk and more action.


It’s ridiculous calling someone who works IT an “Architect” of any sort, why not call them enterprise “Doctors” or enterprise “Lawyers” for that matter? All three are professions with rigorous training, lots of schooling and strict liability and licensure requirements, and you can get arrested for practicing any of those without having a license, but sure, lets just call anyone “architect.”


The models governing Social Institutions tend to lag a decade or two, and sometimes even a generation or two, behind changes in our understanding of the underpinning principles that support them. This only becomes apparent during periods of fundamental change.

Industrial culture, based on linear methods of Reduction and reassembly is the direct outgrowth of the clean, uncluttered, clockwork of the Newtonian model of the Universe.

A few decades back or so, we discovered Nature is far more complex. Even in a simple system with only three variables where all the parameters are known and precisely controlled, it’s literally impossible to predict the exact outcome.

Instead of linearity, or even circularity, self-adjusting natural systems rely on spiralling interactions curtailing one other in a complex that averages out to stability.

The problem with Newton and Physics more generally, is that it only considers the interaction of two components at a time. Yet in reality, everything is connected systemically in a complex of adaptive systems, to maintain a potentially constantly shifting balance of dynamic equilibrium. As a result, even the most simple systems change in completely unpredictable ways to even the most minor of variations.

This is bad news for those who like to directly control things and it will still be some time before the truth really sinks in. For the present, most of our systems are designed to function in a universe that doesn’t really exist.

Yet as fundamental social change/disruption occurs via the personalisation of Technology, and social systems adapt to them independent of the traditional social control-structure, social management at every scale, is forced to play bewildered catchup, vainly trying to keep its death-grip on the traditional reins of control.

These are no longer appropriate. As you’ve rightly deduced, we need to understand how systems work and plan to manage, by tweaking minor inputs to sustain desired equilibria.


Very interesting post.

While I think your observations are often correct, they are mostly limited to private sector organizations, especially in tech organizations that have been influenced by internet and open source culture.

Meanwhile, the public sector has been moving rapidly in the opposite direction, in favor of less transparency, less public accountability, the handover of policy development to corporate interests, and considerably greater control over public discourse and the press. The reins have probably not been tighter in many decades. The government has not gotten your memo.

So for most of the things that really matter — and Silicon Valley is not one of them except to the extent that technology contributes to changes in voter attitudes and behavior — the changes you describe will be illusory.

Comments are closed.