ArchOps


I keep being told how Digital Innovation and DevOps are going to save the world. Unfortunately for the salesmen I’ve been around long enough to have seen a magazine full of silver bullets, think Distributed Computing, PCs, Information Centers, Fourth Generation Languages, End User Computing, Object Orientation, ESBs, SOA, BPM and even Java to name a few. These were all going to solve all my problems. Mostly these ideas just moved things around a bit. Mostly money, it seems, from one bunch of share holders to another, and that while the names changed the problems basically didn’t.

Another observation I’ll  make is, that when the latest wave of newbie techies get control of your IT agenda the the result is always the same. Business thinks my God these people are clever! Why can’t our IT guys be like them! Then there’s an initial excitement and burst of enthusiasm from the naive evangelists that belittles all that went before and stupefyingly simplifies anything they don’t understand. Which actually turns out to be rather a lot. Then after the frantic and often mindless pursuit of the latest shinny thing fails. Typically on same stupefyingly simple obstacle as the previous technology, the new technology with all its technical debt (remember that term?) is assimilated in to the legacy. The uber intelligent evangelists are off on the next cloud (no pun intended) and the executives responsible for moving all that money around sheepishly retreat into the woodwork leaving the clean up to the IT guys.

To speak plainly Enterprise Architecture has a poor reputation in many organizations and rightly so. One of the problems is that many EA programmes are stuck doing what I call EA2000; using ideas and concepts that were common about 2000. Indeed, many programmes are worse, practicing a degenerate form of EA2000 (Template2000) in which filling out documentation templates has been substituted for actually doing architecture.

So, rather than having to deal with EA programmes that simply aren’t fit for purpose and perhaps having learned from the past. But, more likely as an expediency to reduce over-site and allow the rivers of money to flow (usually out of the organization). We see the idea of  two speed IT or Bimodal architecture rear there heads.  The problem with these approaches is that they undermine the legitimacy of the EA programme. We’ve seen this before. The hose pipe cannot be serviced so some “guidelines” are put in place typically they say something like, projects under $100K don’t need architecture approval. Next thing you know every project is $99K! And the disasters flow unabated.

The correct response is to increase the capacity of the EA programme. Typically, this is interpreted as get more EAs. Something that’s just not going to get up in a lot of organizations. The other option, that I don’t see very often, is to make the EA programme more efficient. What that means is that the programme has to move beyond EA2000 and develop a methodology that is actually appropriate to the organization. It’s time to blend architecture and operations, even Zachman has a Function Enterprise perspective, with operations. It’s time to adapt, to create ArchOps and stop all this nonsense about architecture being old and slow.

Now, that sounds simple, but for a discipline that has no universally accepted body of knowledge and even struggles with concepts like definition it is not easy. But that’s why we like doing architecture. What’s more EAs have the advantage, they understand patterns, they have seen it all before. They are are the smartest guys in the room.

  1. No comments yet.
(will not be published)