Question everything?

If you work as a Enterprise Architect, part of your job is to question how things are done today and make analysis of the findings.

But if you question everything, you will get in trouble regardless if your are an employer or contractor.

Don’t try to persuade your company that the world is flat when making a supply chain architecture.

If you question the latest presidential election results in US, the question is more if your analytical skills are tainted or your paid by some one else.

If you think Covid is caused by 5G networks and the vaccine contains microships, your future is probably more in narrative writing then in Enterprise Architecture.

If your client is a firm beliver in conspiracy theories, you don’t have a chance in hell yo make a proper analytic work.

On the other hand, if you question existing vendors and their solutions, this is often part of your job. If you have a new business model, it may be good to evaluate the options. A least to get a better deal from the existing vendor.

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?