Wednesday, April 20, 2011


Enterprise Architecture: Crisis as a Best Practice...

In my tenure at The Hartford, I have known of only one enterprise application that has never had an unplanned outage. Sadly, this application was rationalized away...

Let's face it, we live in a culture of perception management and in order to thrive it is best to embrace heroism over engineering. The Architect who flies in and saves the day will in most cultures be rewarded more than the one who is disciplined, doesn't partake in cargo cults and simply does his job through technical excellence and demonstrated ability.

So, I believe it is in the best interest of IT professionals to sometimes not do things right the first time! Increasingly, I believe that even if you had the foresight to prevent an enterprise application from future outages and the potential for lost revenue and otherwise sunk cost that goes with it, you should hang back a little.

Ever notice the behavior of most IT executives when an enterprise application is down for an extended period? While we can't possibly get the right resources or an appropriate budget while building an application, they somehow manage to clear all the hurdles whether it is a stifling governance process, suboptimal IT employees who are in the way or simply allowing architects and developers to practice their craft, we can pull off magic during a crisis.

Code somehow during periods of crisis seem to get written of a higher quality and at half the time than during normal periods. So, how does an enterprise leverage this simple truth? Create a few crisis and take advantage of every failure.

If IT were 100% perfect and had zero outages, someone would immediately start brainstorming ways to tamper with it. After all, perfection isn't a goal and in the minds of many may be a predictor of not enough efficiency. The process weenies love to devise schemes where people are over-utilized and chaos ensues. Many IT shops are efficient but few are effective.

In many corporations I have worked that have embarked on IT outsourcing to India, the end result has been a net reduction in the availability of enterprise applications yet outsourcing continues to thrive. The onshore model involved a few talented individuals working a problem to resolution while outsourcing has brought many best practices where we need to coordinate dozens if not hundreds of people in different timezones and skillsets to resolve a problem.

When things are broken, usually from the ashes a hero emerges where the business is happy for anyone contributing a potential solution no matter how far fetched it may be. Crisis has allowed for IT to acquire many performance testing tools that otherwise would have gotten shot down at budget time. Crisis has also allowed for many more non-technical IT employees to remain employed working on various but otherwise neboulous practices that are under the guise of reducing future events.

More importantly, crisis in many cultures allows for developers to get the opportunity to refactor code. As an Agilist, we know that time and hindsight affords us the opportunity to find better ways of developing working software. Likewise, we know that developers never get to make things better and are constantly working on the next thing. The only thing that allows most waterfall enterprises to be agile is crisis which affords the opportunity to mercilessly refactor...

Links to this post:

Create a Link

<< Home
| | View blog reactions

This page is powered by Blogger. Isn't yours?