Evolutionary and Structured

One enduring problem of architects, and enterprise architects in particular, is we tend to perceive our enterprise (cfr. TOGAF for a definition) as something we can/must structure to optimize it. Using an enterprise architecture framework, for example.

Time to look around: most of the things you will see around you have been improved by evolution, i.e. successive generations of selection, recombination and mutation. Seriously, look around. This blogging application. Your workstation. The chair you are sitting on. Your keyboard evolved from the typewriter. Also, there were many lesser designs on the way.

Which designs survive, is sometimes determined by great ideas, sometimes by pure coincidence. A bit of marketing may help, also.

Lately, I tend to take the view that filling up an enterprise framework can be done really, really shallow, then select a few (max. 3) focus areas for being inspired by evolution. It is enough to find a few champions, coordinate their work just enough, realize a few designs that you can breed with. Changing surroundings may do the rest, and weed out some competing organisms. If you pick the right genes to start with, of course.

What is really shallow ? 2 levels of business process, 2 levels of roles, without sequencing and only the most important business documents = a business architecture. An application list with a few features and interfaces for each application = an application architecture. A technical components list and a preferred technology list = a technical architecture. A list of infrastructure platforms and databases = an infrastructure architecture. You can't do a thorough impact analysis on that, or present an architectural business case with several solution scenarios, but it may be enough to build a common understanding and get evolution going. Then, structure only the parts where this brings a real advantage to the development process itself.

How come ? It's important to be understood by most colleagues. It's not important to have everything documented. It's important to be fast. It's important to have essential things documented. It's not important to be rigidly structured (forget large-scale reuse first). It's important to adapt to what happens around you. As an enterprise and as an architect within it. Especially if it's chaotic. It's important to tell a story. Of just a few essential projects that worked. It's important to have essential team discipline. It's important to open freedom of imagination. It's important to feed ownership. It's important to have just enough common reference to communicate.

Keeping the right balance depends on the wind strength, but also on its variability.