The Enterprise Architect as Enterprise Ecologist

tech blueprint

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.

loading

Comments have been disabled for this post