A sisyphean profession

Gerben Wierda wrote “Don’t be an Enterprise Architect” on LinkedIn. I understand his thinking as what we do is a sisyfos task.

Don’t get me wrong, I love what I do, but you need both patience and passion to be an Enterprise Architect.

During tweenty years, there has been only a few home runs with client projects.

The biggest challenges is as always the resistance to change in the organisation and different priorities between business units.

Technology is not the problem. With the caveat that you need to understand it to know what is possible, how long time it takes and the cost.

As people in general want to do as they always done, you will not win the popular vote as you question their ways of working. This is why you need a skin thick as an elephant when it comes to critique.

If you instead take the approach to be popular, then your challenge is to get changes done, that are aligned within the company.

-Det ska fan vara teaterdirektör, skrev August Blanche i sin komedi "Ett resande teatersällskap" - 1848.

Dissolve the EA team

To dissolve the EA team, is that a good idea?

Marc Thomas asked on LinkedIn what you would do if you had unlimited resources.

My suggestion was to remove the architecture team but I only gave a partial answer of why.

First of all, the value of Enterprise Architecture is zero if there is no change, thus no need for EA.

Second, if you have unlimited resources, the need from savings using enterprise architecture to govern a transformation is null.

Third, if the organization doesn’t understand the value of architecture and more see the architects as a hurdle, then we can dissolve the EA team.

But, and this is a huge one.

You can’t throw more people and money on problems that comes from complexity. Not even the biggest software companies in the world succeed with that, without a long term architecture thinking.

Not to forget the pipe dream of unlimited resources in a world where most companies struggles with margins below 10%.

The bottom line is if your EA team doesn’t provide any value to the organization, then you should dissolve it. But don’t expect your problems to vanish in the air.

Enterprise architect vs. actor

Photo from the short film-series Seven Deadly Sins of IT

What is the difference between an actor and enterprise architect?

In my view, an EA tells facts and his belieifs of what should be done and what would work, based on his experience.

An actor says what’s written in the script.

Another difference is that the day rate for an A-list actor is much higher than for an A-list architect.

What role do you need?

What is your plan B?

The sun is shining and everything works as it’s supposed to be, but what is your plan B when it’s windy and rainy and things not working?

Photo: Adobe Stock Library

We have a good example from the latest IT-attack last Friday when the Swedish grocery and department chain Coop got their IT-systems hacked. In most stores, there was no plan B, so they have to close the stores, and most of them are still closed a week later.

Another example is when you plan to implement a brand new IT-solution for a new business. What happens if the system doesn’t deliver the promised functionality and/or get seriously delayed?

In Coops case, they could not even go back to manual routines with pen and paper.

What is your plan B?

No documentation

Don’t make any documention as it’s waste is sometimes said in agile projects.

The question is then how far we can go with this principle while not breaking the law.

The first step is easiest, don’t document what you are doing and have done.

The second step would then be to scrap the source code after we put it in production, as we don’t need it after compilation. It’s easier to rewrite in a new language compare to fix undocumented code.

Third step is to get rid of the developers from the files as they still may waste their brain with memories of what they have done. 

Fourth step definitely over the limit, and that is assure no living witnesses from your projects. However, natural death gives the same result, but takes longer time.

The alternative is to think of what you need to document, for whom and why.