Saturday 2 June 2018

Architectology Update

Some time ago I wrote a post on this site about architectology. I have had a lot of time to think further about the subject since my original post, which I have just read again. I didn't really have a conclusion or a solution in that original post. It seems that I was saying that the notion of a person who spends their time navigating legacy code feels wrong but I had no better way of dealing with the silos and extracting value from them.

From talking to a lot of software professionals over the past year I have discovered that many large businesses (and public sector bodies) have their own word for architectologists, it seems that many of them widely refer to such people as "enterprise architects".

I've recently completed a 10 month engagement with a public sector client and although they didn't call them enterprise architects they had plenty of architectologists. I now believe I have seen enough to propose that architectology is an anti pattern. According to Wikipedia, an anti patter is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. To distinguish a genuine anti-pattern from a simple bad habit, the following 2 conditions must be met:

1. A commonly used process, structure, or pattern of action that despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones.

2. Another solution exists that is documented, repeatable, and proven to be effective.

Firstly, is architectology a common response to a recurring problem? I would argue that it is. The problem is how to extract value from silos of legacy systems. The response is to task some people (architectologists) with drawing pictures of the legacy with lots of arrows on it to show a software team how they might get stuff done.

Secondly, does it have more bad consequences than good ones? I think so. Among other things it prolongs the lifetime of the legacy, couples it more strongly to more processes and makes it successively harder to add new value to the enterprise.

Finally, what is the better solution? Last summer we had a good deal of success in the client we were working at in persuading them to create cross functional teams that own the entirety of a customer facing outcome. Having made that step, the logical next step was to repurpose their architectologists (IIRC they were called enterprise architects) as architects working more closely with software teams delivering those outcomes. As the teams that previously owned the legacy pieces were broken up, nobody was left illogically defending the existence of various pieces and the client was able to start sensibly decoupling the systems and strangling parts out of existence.

So it is therefore my conclusion that architecology (or enterprise architects if you prefer) fulfils the criteria to be regarded as an anti-pattern.

I recently gave a short talk postulating that architectology is an anti pattern at Devoxx UK in London.