Kicking dead horses

In Dutch “kicking dead horses” means: “trying as hell to get something immobile moving”. Some people seem to really like this. Getting ECM people to talk about security or industry analyst to be open about sponsoring is kicking dead horses for sure.

This summer I was kicking some dead horses too, and did not like it at all. Two major projects asked me to create a Project Start Architecture, only to ignore it completely. In spite of my best efforts I did not get a foothold in these projects.

Of course, I could simply blame the process weenies for the ridiculous demand that every project always should have a PSA – a full blown PSA. This makes the PSA a “checklist document” for many project managers. Simply get a PSA, check it on the list, and go on with business as usual. This is not the right way to do architecture. I would rather have a discussion with the problem owner during the birth of a project. If the need for architecture is understood, it becomes part of the project assignment and the relationship with the project manager has a different starting point too.

Fortunately, one of my problems solved itself. The business also noticed the wrongs in the project and decided to completely restart it. New scope, new project manager, new planning, new everything. Of course, me and my colleagues did not protest this move and took the opportunity to reinstate the architecture. You could say this horse was brought back to live.

The other dead horse was solved differently. I even used the tools of the project weenies for this. During a big project meeting, the project owner and project managers went through the project goals, the very strict deadline and the disproportional costs of missing this deadline. Then I popped the big question, given these circumstances wouldn’t it be better to have a project without architecture? Big silence. Then I explained that this was possible in the process description with two conditions. Extreme costs when not making the deadline and a management letter stating how the solution will be recreated under architecture at a later stage.

Assisting with this management letter of course provided me with the perfect opportunity to develop a better relationship with the project leader and project owner. I could also show that if they had asked the advice of me or my colleagues at an earlier stage the project would have been under architecture immediately, with hardly any extra costs.

Two lessons for me: sometimes it is OK to bring a dead horse to the slaughter house and it is always nice to use the weapons of process weenies against themselves.

Formal and precise modelling

In his blog Nick Malik asks the question whether we should put the ruler to the blueprint. In other words, should we create models so precise that we can hand them over to the builders and simply walk away?

This question becomes even more important now we are supposed to use Archimate to create our models in. Does a formal modelling language improve our architecture?

My answer to both these questions is NO. As an architect I set guidelines for a project, create a high level design – more like a sketch – and assist the project team in designing and realising the systems.

I simply create a model as a communication tool. For the management I create completely different views than for designers and developers. For the first, I would never use Archimate. Too much technical details. For the second, Archimate actually seems to be helpful. The first results have been OK.


In other words, I use models as precise and formal as needed for the task at hand, but I don’t think I will ever create an architectural model that is like a building plan for a house. They are more like zoning plans with some regulatory guidelines.

Perhaps the scope of architecture within ICT simply is different, such that comparison is futile.

Hello,

I feel it is about time I started my own blog I have a lot of ideas bubbling around my head that need a place to materialise.

I work as an ICT architect at one of the largest insurance companies in the Netherlands. It really is a fun job! I get to discuss the future with strategist, as well as the down and dirty details with people running the projects. In short, I participate in transforming the strategy into a vision of the future and architectural guidelines, as,well as assisting projects producing within these guidelines.

This means assuming an advisor role. Towards project managers and project owners about the importance of architecture with regard to the goals they are trying to achieve. Towards designers and lead developers regarding the guidelines for their project. Towards strategist to make sure their ideas still can become reality. In my book, architecture is declarative and very much about collaboration at all levels.

Another approach would simply result in a situation where project members just ignore me. Then I would let the tactics really ruin my strategy!

Greetings for now,
Jaap