Enterprise Architecture: From Incite comes Insight...

For the past couple of months, several agilists within our enterprise have been figuring out how to sell agile approaches to a larger audience. We met on Wednesday for our usual passionate lunch discussions and several thoughts emerged that I started to think deeper about. Originally, I wanted to make this blog on the methodology paradox but instead decided to talk about what agile approaches and enterprise architecture both have in common...



The vast majority of large enterprises suffer from the lack of Strong Technical Leadership which causes folks to think that they can methodology their way through complex issues ignoring the fact that maybe they really shouldn't be participating but simply facilitating so that folks who have the right abilities are put into situations where the best architectures can emerge.

Many of these same shops have adopted in-house methodologies many of which are rooted in some form of Rational Unified Process. The notion that one can buy a methodology and customize it so that it fits their needs on the surface is appealing but without any set of guiding principles one can get lost in the wilderness. Agile Manifesto unlike RUP starts with a base set of principles which allow one to detect when one has gone off-course.



Lack of strong technical leadership within enterprises and the folks who have never written software yet lead software projects also tend to be somewhat delusional in their abilities and devise methodologies that support this notion. Many even stray from the line of confidence to blatant arrogance. Most continue to ignore the real root cause for any failures that have preceeded them and of course can rationalize any past mistake made by them. In order to understand the problem, lets enumerate some of their practices:

• For the requirements phase, under their leadership, the team will identify all relevant requirements and correctly document them such that there is no ambiguity.


• For the Analysis and Design phases, the team will interpret all requirements correctly and produce an implementable architecture that mets not only all functional requirements but also every possible system quality. The design will be 100% correct the first time and will not need changes.


• For the development phase, we will take our design and hand it off (I really wanted to say throw it over the wall) to the offshore development staff (I really wanted to say low pay peon scriptmonkeys) who will interpret the design correctly and make no significant mistakes (We can expect a few spelling errors).


• For the quality assurance phase, we will test exhaustively by throwing lots of resources (all hands) and it will be 100% successful (except of course for those spelling errors).

Agilists understand that this is not only not reality but that the odds are better in using a metal detector to find a unicorn in your sockdrawer is higher than being wildly successful with this approach. Maybe enterprise architects should be busy introducing the notion of humility to the enterprise. Actually, maybe they should be busy introducing the notion of humility to themselves...

With this thought in mind, here are some things that architects can do to adopt humility within their shops:

• Acknowledge that it is futile to think you can gather all the requirements upfront. Instead gather what you know and reserve the right down the road to make changes as new requirements emerge.


• Design will never be right the first time, so don't be dumb enough to set this expectation. Teams should get signoff on direction not specification.


• Unless the problem is commodity in nature, acknowledge that you probably don't understand the problem well enough to predict what you will need later, so don't commit to fixed resources, buy expensive infrastructure or other promises that you cannot fulfill.


• Acknowledge that hindsight is always 20/20 and use this to your advantage. Get the business community to acknowledge that there should always be at least three different releases at the bare minimal and two of them will contain changes that make the architecture better.


• If you work in a culture where business people prioritize technical issues, help them see the error of their ways. If they still don't get it, convince them that you would like to remodel their kitchen based on everything you learned by watching Bob the Builder with your kids...

In the meantime, I suggest everyone that wants to understand humility start with the roots. Check out a paper by Edsger Dijkstra entitled the Humble Programmer...