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.

Cost of legacy

Why is Hollywood substantially better at running large projects than your IT-department?

First of all, my experience is that IT-projects are started on a whim, without proper scope, estimates, funding and stakeholder commitments, e.g. business as usual. To have a green light for a feature film, you need to have your ducks in order. You will end up with an indie film that will fail if you don’t do your homework. One 3% of them are profitable and more or less in the same grassroots league as a large IT project.

Second, a new feature film is often a greenfield endeavor and the director doesn’t need to think of the past, unless you are doing a sequel or two with you godfather. But we have TV-series that have been running for ages, they have their legacy. But they also have a production bible and a show runner. The production bible describes what have happened in previous episodes and the show runner is responsible for over arching story and that things fits together. Do you recognize the role in business and IT?

IT-project are very very seldom greenfield projects and the legacy we have is mostly not documented. Think of making the last episode of Game of Thrones without knowing what happened in previous episodes. 

Third, humans and film critics (in you think the are human) define if they think it’s good enough, not yet machines, which means there is a softer success criteria’s for movies. Compare this with two different IT systems, that have different integration concepts, will not work together. IT-systems on the other hand can ship updates afterwards. So far only one Hollywood film got a major update after release. 

My take on this is that within IT, we are more sloppy because we can fix things afterwards. We don’t need to get it the first time, unless it’s a spaceship, nuclear power plant or a self driving car.