Playing the Just Enough Game

As can be seen from the figure, I seem to love quotes starting with "Just Enough" or quotes that are in line with this paradigm. I try to behave in line with these quotes in my job although that is not always easy. In my opinion we often tend to overly complicate matters and forget to live the life of simplicity. From all the IT projects I have seen, many tend to strive for "the perfect product", "the best of breed" or a much too complicated ("best fit"?) IT solution. Why is it so difficult to harvest a "Just Enough" culture? Is it because there is not enough governance? Some people seem to think that, but how much governance is really required then? This is actually a funny paradox: on one hand, we would want to have as little governance as possible (just enough) since it can be too constraining, on the other hand, with no governance at all we will probably not be able to play the "Just Enough" game as it is meant. If we would be able to embed the just enough behavior into the culture, governance could be minimized. In reality however it seems impossible to run a (large) company only by culture. So the real game would be to find the balance between just enough (design) governance (from architectural point of view: limiting design freedom) and just enough (design) creativity. If people cannot be creative anymore because a governance structure constrains them, they probably will find ways to bypass the governance. In next posts, I plan to go into a bit more detail for each of the quotes in the figure.

The Art of Architecture?

Here are my personal quotes on the art of architecture:

“The art of Architecture Governance is in constraining (design) freedom without constraining (design) creativity”

“The art of Business Architecture is in balancing Innovation (& Diversity) with Optimization (& Uniformity)”

“The art of IT Architecture is in enabling the transformation of data into business value”

"Architects should not be control freaks but innovation freaks"

Model Value Chain

Based on my experiences with the Business Transformation Grid, the idea popped up that all artefacts that one stores inside the framework often will be models. In architecture, we often use models to communicate to stakeholders. If considered from an IT-development perspective, you could also discuss that models therefore need to add value when communicated in the development chain. A models adds value because it is a part of knowledge transfer. So the knowledge transfer inside a typical IT development organisation can be considered a Model Value Chain. The challenge now is, how can we design models that effectively add value inside such a chain, i.e. that are designed to close the competence gaps between parties involved inside the IT development chain, since that seems an important reason why we communicate using models. The picture shows a high-level (fictive) example where the arrows represents models that are designed to transfer knowledge during IT development & IT operations.

Business Transformation Grid

During my work I have encountered it is sometimes not so easy to explain to certain stakeholders exactly what the value of architecture is and why it is structured alongside some existing architecture framework. Most frameworks I know of are more or less designed to structure relative static architecture concepts. Some of them have also corresponding architecture development methods (e.g. TOGAF-ADM).

I found out that by structuring architecture artefacts in-line with examples from the construction world, the message is easier to convey to business people. Using the construction world as an example, I designed a 5x5 grid where in the horizontal direction artefacts can be stored going from left to right in increasing level of detail. In the construction world example you can compare this with a continuum that is ranging from City plan to Zoning plan, to Building plan, to Interior plan to Infrastructure plan. This can be easily compared with levels inside a business, ranging from Enterprise via Value Chain via Business Domain via Business Function to Business Infrastructure. In the vertical direction, the rows are showing the continuum of abstract to concrete. I designed this continuum ranging from Innovation via Ontology via Principles via Planning to Design & Construction. The idea is that you start in the upper left corner because some business innovation is triggering it. Then the next step is to develop a corresponding Ontology that fits with the innovation theme. An ontology is still too abstract to be used in practice so we need tools to go from ontology to a real usable model. I use the principles continuum to explain that, since by governing the transition from abstract (ontological) to concrete (planning, design & construction), you can easily tell how principles (and corresponding guidelines, standards, patterns, rules etc.) assist in making that transition. By modeling aspects as a continuum, you can easily explain that not all "continua" are linked or can be integrated easily (lot's of work ahead in this area). For example TOGAF talks about the Architecture Continuum on one hand, and the Solution continuum on the other hand. These two continua are found in my framework in the center. Then I have added some more continua that I regularly encounter during my work and tried to structure these around the center. This total framework has now become some sort of an innovation framework for me, since it helps me structure whatever is needed to innovate something from abstract to concrete, and from high-level to detail. I am planning to further develop this framework so that I can use it in addition to the more static frameworks and ADM's.