As Enterprise Architects we talk a lot about the mythical target state.  But do we ever get to this target state, and would we actually want to be there if we did.  Perhaps nature can teach us much about how we ought to think about the target state.  We return to the ancient Chinese philosophical text called the Tao Te Ching written by Lao Tzu 2500 years ago for one of its most profoundly deep quotes.

“Nature does not hurry, yet everything is accomplished.” ― Lao Tzu, Tao Te Ching

I wrote about one reading of this quote in wu wei – effortless action for enterprise architecture.   Wu Wei is related to flow, or effortless flow.  This reading of the quote is about not forcing and not hurrying, and for a long time I thought that was the whole point of the quote.  However Lao Tzu liked to focus on multiple layers of meaning in simple statements that you had to unpack carefully over time, and lately I’ve been thinking about the second half of the quote “… everything is accomplished”.  This part is doing a lot in the quote.  What actually is everything?  Is everything the target, or in our terms, the target state.

evolution to target
So lets consider the evolution of the Giraffe.  Was there a explicit or implicit target state?  Just set assign the idea of a designer, and consider if there was a correct way the Giraffe had to end up being.  OK we’ve all heard about the Giraffe evolving to reach tree leaves, but there are a whole lot of trees around the world and only the Giraffe is Giraffe-like.  If you think about it the Giraffe is a strange looking thing.    

We are told, and it seems reasonable, that evolution is driven by environmental adaptation.  Does this explain the Giraffe?  Is the Giraffe now at target state, or does it like all living things, continues to adapt and evolve? If so what is it evolving to?  Apparently the Giraffe mostly evolved about 7.5 million years ago, and like all living things, it is still in a transitional state, so that is a long road-map.  I want to see the cost vs benefit analysis and assumptions made during the business case. 

“Nature does not make mistakes. Right and wrong are human categories.”

Frank Herbert Jr. – Author of Dune

the errors of nature
Does nature makes mistakes? I’m inclined to align to Frank Herbert Jr’s view that right and wrong a human constructions, and that nature just does its thing without judgement. The same natural process that created the Giraffe created the Bat, the Shark, and Tick. What principles was its Architectural Review Board using when it endorsed all these designs.

However we do understand that the basic principle of evolution, and adaptive design, is based on gene mutations that are carried forward due to adaptive advantage. Effectively nature is running a series of experiments, and selecting the most advantageous adaptations to carry forward, and therefore build on for the next generation. The direction things end up going are somewhat random with regards to what adaptations can rise to the surface.

So the concept of a target state in nature is not relevant because living things don’t stop evolving and therefore don’t reach a target, and any steps forward have their origin in randomness.

what if Lao Tzu was an enterprise architect
I’m not so sure that Lao Tzu would tackle enterprise architecture even if he walked the earth today, but I’m fairly sure he’d smile about our ideas around target architectures and road-maps. What are your observations on these? How often have you seen a target state come to fruition at a large complex organisation? How many road-maps worked out the way they were envisioned? There are always a lot of things to blame for this, like funding, lack of understanding, inadequate support from above, poor execution etc. But perhaps Lao Tzu would say that it is because road-maps are self deceptions, and the target state is a mirage.

can evolutionary architecture help us?
Our architectures evolve due to both business drivers, and technology drivers, and typically well before we arrive at any target state. We are expected to know what is needed in 3-5 years time but we cannot possibly know this from an epistemological viewpoint, such as a justified – true belief.

There are emerging concepts like evolutionary architecture that have got some attention in recent years. Lets face it, our enterprise architectures just will evolve, and in ways we cannot anticipate. So leveraging the principles of evolutionary architecture might makes sense, but I think of the concept as a counter-measure to what is a reality. We don’t do evolutionary architecture, as that will happen regardless, but we are using the concept called evolutionary architecture as a measure to response to, or counter, any adverse impacts.

An evolvable architecture supports guided incremental change across multiple dimensions

Building Evolutionary Architectures

In Building Evolutionary Architectures by Rebecca Parsons , Neal Ford and Patrick Kua, out of the ThoughtWorks stable, they state that the first principle of evolutionary architecture is to enable incremental change in an architecture over time. This makes a lot of sense, and it aligns to the whole concept of DNA and its ability to adapt. They define evolvability as an an additional ‘ility to all the usual non functional like scalability and maintainability. Evolvability is defined in Wikipedia as “the capacity of a system for adaptive evolution”.

The authors leverage something they call a fitness functions, which is a term used in genetic programming and genetic algorithms to guide simulations towards optimal design solutions. These fitness functions are intended to evaluate how well the solution fits the various ‘ilities; which is to say the characteristics of the architecture. Preferably these are automatically executed (e.g. coded in Java) but in some cases they could be manual or semi-automated. A nice example they talk about is a legal department needing to know if open source licences have changed, and the company writing a fitness function that is hashing the licence files and comparing them to detect a change to the file. Another example might be checking that software versions are upgraded as necessary. These are intended to be implemented within a CI/CD pipeline, which is key to an evolvable architecture.

Fitness functions have a couple of effects on architects, firstly architects need to be specific about defining ‘illities that can be deterministically tested, and secondly, architects have more time to focus on the issues where their skills are most valuable to the organisation, such as ensuring we preserve optionality, which if you think about it is the ability to evolve. So there is work in defining these fitness functions, but unlike our mostly ignored standards, these functions, particularly if automated, are actually used and benefit the organisation. These become new guardrails, and inherently focus more on outcomes than implementations, giving teams more freedom to make decisions closer to the real place of work.

So under this concept the target would become a combination of the fitness functions and platform/modular boundaries, using the best appropriate technologies at the time. This is particularly well suited to PaaS and FaaS based micro-service implementations, while still be applicable to other styles. Often people ask about COTS packages, and in this case the focus is more on the integrations points, fitness functions, and making the package work with CI/CD pipelines. From personal observation we often see packages having certain key capabilities we want, then other functionality that is more there as a presales filler, and we need to take care about leveraging these. I tend to favor applying the strangler pattern to COTS up front, or ASAP by swapping out generic functionality to specific where it is important to the business.

Your architecture will evolve, and although it is far from certain that the concept of evolutionary architecture has solved it, you need to determine some practical way to managed it beyond just ignoring it or hoping. Hope is not a strategy.

onward to target
So you will get to target, of a sorts, but it likely won’t be the one you expected it to be. Nevermind. Just make sure that whatever the target is it has evolved to a point that supports the business evolution. The best possible architecture under the conditions as they are, and anyway it isn’t really the target state, it is still evolving.