A great tale on the value of Enterprise Architecture

The Great Master Lea had spent more than a cup full of time gazing into the cloud like leafs at the bottom. Now, as time had come and gone with no apparent effect on the outcome of the day he caught hold of the thought that had eluded him for so long. This was his thought: “How can I explain the value of architecture to those who are not blessed with an intuitive appreciation of the subject”. Like a nail being driven into a board by a directed blow from a hammer in the hands of a master carpenter his mind came up with the answer: “If you don’t control your architecture it controls you“.

An epic tale about Enterprises and Architects

The Great Master Lea was sitting in his favorite chair, gazing at this odd looking fruit in his hand. Just as he was about to bite in to a specifically delicious looking piece of the fruit something hit him on the head. It was the Enterprise Janitor throwing tiny seeds of the fruit on him. Once again the Enterprise Janitor and his crew was after the great master for not planting the seeds of the fruit he ate. This is what the Great Master Lea said: “Oh grand Enterprise Janitor man, is not the seeds I leave lying firmly on the ground?” The grand EJ looked at the seeds in his hand and then turned his head towards the sky and said: “Beware the leprechauns they always chase the gold at the end of the rainbow!”

A great tale on Enterprise Architecture and Frameworks

The Great Master Lea had left the cold on the outside and sat by the warm fire sipping on an excellent glass of wine. He remembered what several people had told him last year: “Oh great master Lea, Framework A sucks and this other framework is better because… Or Framework A sucks you should not use any single framework… Or Framework A sucks Framework Beer is better!” The great master Lea pondered the idea of Frameworks sucking, and then turned his lips to the glass of wine and sipped some more of that deep, dark ruby colored liquid and said: “The best thing with any good EA Framework is if it has its focus on building the capability to create architecture.“

A great tale on good and bad Enterprise Architecture

The Great Master Lea had spent a week educating acolytes on one way of doing EA. Now, at the end of the week he had taken to his favorite corner of the world and had hoped to be at full rest when a question had come his way. This was the question: “Oh Great Master Lea, what is the difference between good and bad architecture?” The great master Lea had pondered the question and then turned his head towards the sky and said: “Good architecture exist outside the control of the template that created it but still within the same context as both the template and the creator.“

Possible tactics of TOGAF Building Blocks

In the ”Stable area” we aim for: (”future proofing the situation”)

1. Stable architecture building blocks so we ease change management by the use of target architectures that span years and multiple initiatives. This enables us to be in control of an agile future.
2. Stable solutions building blocks so we can assure that the solutions build upon the SBB we have decided. This enables us to run many solution projects concurrently and still be able to have complete control over the outcome.

In the ”Dynamic area” we aim for: (”adaptability to any situation”)

1. Dynamic behaviour in our architecture buildingblocks so that we easily can reconcider the use and re-use of our ABBs to match the needs of the business.
2. Dynamic behaviour in our solution buildningblocks so that we easily can bundle SBBs in innovative ways that maximize the potentials within our Enterprise architecture and Business situation

In the ”Agile area” we aim for: (”simple to work with”)

1. Agility in the selection, configuration and lifecycle of ABBs such that the design of composite ABBs can be done as fast as possible
2. Agility in the SBBs such that the design of SBBs from the specification of ABBs can be done as fast as possible

A great tale on Enterprise Architecture and monkeys

The Great Master Lea had spent most of the day on his mountain top educating acolytes on the importance of being human. Now, late in the evening he had moved into his tree hut and he reminisced over what one of the older and wiser acolytes had said. This is what he had said: “Oh great master Lea, I suggest that we implement Enterprise Architecture as a practice in our house!” The great master Lea had looked at the acolyte and then turned his head towards the sky and said: “Like trained monkeys you attempt to implement what should be a transformation guided by reward, attitude, behavior and culture.“

A great tale on the dynamics of Enterprise Architecture

The Great Master Lea had an awesome day on his sunny but slightly cold mountain top. He prepared himself to navigate the winding trails of hard labour and the master knew he would enjoy the hours to come. Crawling up the mountain side came what appeared to be a team of hockey players, but alas it was not so. Once again the Great Master had been approached by business people, this time though they had all been attending match when they realised that they had a need, an urge, a craving to ask the Great Master a question. This is what they asked: “Oh great master Lea, why is our expertly architected game strategy not actionable?” The great master Lea looked at the team then turned his head towards the sky and just as he was about to utter his words of wisdom a would be hockey manager appeared as an apparition before him. Trembling with anxiety the manager roared out an answer to the question: “THERE IS NOTHING WRONG WITH THE ENTERPRISE ARCHITECTURE IT IS YOU GUYS WHO DOES NOT EXECUTE THE PLAY ACCORDINGLY TO STRATEGY!!!”.  The Great Master who was great in many ways beyond the field of Enterprise Architecture waved his hands and thus the apparition dispersed like a cloud on the computing heaven. Then he turned towards the business people looking like hockey players and said: “You have to move all of your architecture from fixed to dynamic behaviour.“

Real time Enterprise Architecting

To much time and effort is spent on looking far in to the future. Often enough fixated on a single target architecture, a to-be state that has little to do with the way business is actually being done. It’s time we start utilizing the tools we’ve got to work with rolling architectures. The dynamics of business and supporting structures like IT are well able to get to grips with an ever changing market.

We can make a serious impact on the strategic outcome by acknowledging the fact that the enterprise clocks all work at different speeds, resulting in at least eleven intertwined life cycles that need to be aligned. The skills and tools of the architects is well attuned with aligning all the little pieces and all the big pieces into a continuous transition plan.

Good things that we all do

• Application life cycle management
• Portfolio and project management
• Enterprise Architecture
• Product life cycle management
• Strategic planning

Good things that we can do

• Enterprise continuous life cycle alignment
• Enterprise continuous transition plan

Ways of executing

John Boyds event loop named the OODA loop is a thinking model well adapted to handle the overall problem of intertwined life cycles.

Note that the cycles of the loop is not single instances. There are infinite cycles going on at every time.

If we where to try the OODA loop on our work it might look something like below. To make it a bit easier on the people we could assume that the loop speed would start with monthly iterations, then we could go down to every fortnight and after that every week and after that every other day ending with every day. The aim would off course be to do the loop instantaneously.

Observation
As part of our normal work routine we should enter data, updating the organizations repository with information about every change we came into contact with. The “All” in this case is all levels in the organization, definitely not just architects.

Orientation
Continuously the data in the repository would be analyzed, by the architects

Decision
Each cycle a decision to create new releases of the repository matching the outcome of the orientation would be taken.

Action
Each cycle, programs and projects would be handed updated directives with detailed instructions.

Notes

Many may say that this is all a state of nirvana. It does not have to be. If we combine the best we have in people, knowledge, information and tools then it can be achieved. Remember that some companies have thrown out their budget work and use rolling quarters instead, no one thought that would be easy either.

Near instantaneous loops demand a responsive organization, so if you’re doing projects and programs with steering groups and committees then you’d probably have to rethink your method.