Header image large new logo

EAWheel

Share this blog

Untangle complexity using Enterprise Architecture

Post date:

We have all had to deal with a difficult business related issue at one time or another. One that made us think: how are we going to tackle and solve this? To be honest, I think that we adults are used to seeing things as too difficult. That it is in our nature to overanalyse.

You can see this reflected in one of the most common activities in team building. I am of course talking about building a marshmallow tower with uncooked spaghetti noodles.

Building a marshmallow tower with uncooked spaghetti noodles

It is striking that adults who are given this task (build a tower as tall as possible within a given time) spend a great deal of the available time discussing the approach, the method, the construction, etc. However, if you set a group of children to the same task, they not only build a tower well within the allotted time, they even build a higher tower than most adults.

For those of you who are interested and have not yet seen the video, please follow this link to view “Build a tower, build a team” by Tom Wujec.

As I said, I am convinced that we adults see things too difficult

When we are faced with a challenging issue, we tend to get a bit carried away. We switch to the mode of vaguely formulating solutions in order to present them as non-measurable as possible. This is exactly the kind of behaviour you see when it comes to translating business strategy into departmental and annual plans: a fitting and concrete translation of the organisation’s vision and mission into drivers and (measurable!) goals and objectives is missing. 

Enterprise architecture can be of assistance. It can help to unravel the tangled web of difficult issues. Here’s how.

The dialogue

First of all, it starts with entering the dialogue. This dialogue should take place between the business and the people responsible for architecture. During this dialogue, the wishes and demands of the organisation are mapped out. It is determined what motivates the organisation to do what it does (drivers) and this motivation is then captured in concrete (preferably as SMART as possible) goals and objectives. We call this the organisation’s strategic course.

A strategic framework is then drawn up based on the aforementioned strategic course. From an architectural perspective, we talk about principles and corresponding requirements. Also, when drawing up the strategic framework, it is important to keep the dialogue with the organisation going. For the application of a framework to succeed, there must be adoption by the organisation. This can only be achieved by involving the organisation. Imposing frameworks without organisational involvement will lead to resistance.

Relation between drivers, goals, principles, requirements and standards

The principles must be kept as short and concise as possible and the number kept to a minimum. What does not work at all is having a laundry list of principles, causing the organisation to no longer see the proverbial forest for the trees. For each principle (I like to call them basic principles as this indicates that they must be taken into account in everything an organisation does), requirements are drawn up. Requirements provide further detail to the more abstract framework provided by the basic principles.

If necessary, an additional step can be taken by defining standards, which are a further specialisation of the requirements.

Colouring page

The strategic framework can be seen as a colouring page. They are the lines within which you can colour. The requirements indicate the right colours to be used. It is up to the organisation to choose dark or light colours, or even pastel shades.

The colouring sheet described above forms the basis for the departmental and annual plans to be drawn up. A finished coloured sheet ensures that the organisation has a balanced set of activities to carry out to support the realisation of the previously defined goals and objectives. 

Using a uniform language and well formulated definitions really helps in getting a mutual understanding of the tasks at hand.

At the end of the day, it is the architects who beat the children at building that marshmallow tower. Enterprise Architecture can help to unravel complexity

Share this blog

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to the newsletter

Want to be notified the minute a new blog is posted? Then subscribe to the newsletter.

You will only receive an email whenever a new blog gets posted.


Popular posts

Architecture Roadmapping header

Architecture Roadmapping

(3.6k views | 0 comments)

Architecture Roadmapping is an important part of Enterprise Architecture. The creation of a roadmap enables an organization to develop initiatives that are in line with defined goals and corresponding objectives. In effect, a roadmap represents … (Read more)

The Misplaced Enterprise Architect header

The Misplaced Enterprise Architect

(2.7k views | 3 comments)

The role of the Enterprise Architect is misplaced in many organizations. In nine out of ten cases, the Enterprise Architect is portrayed as an IT Architect. This misalignment has significant consequences for an organization. The … (Read more)

The TOGAF Standard is Awesome header

The TOGAF Standard is Awesome

(0.9k views | 0 comments)

We are probably all familiar with the TOGAF® Standard. Or just TOGAF, for friends and foes. An Enterprise Architecture framework pur sang and a very complete one if you ask me. The framework covers all … (Read more)