Enterprise Architecture: Why your leadership eschews real innovation

If you take a can of yellow paint and throw it at your CIO, followed by a liberal dosing of feathers doesn't result in innovation but does result in CIO feature differentiation...



Let's agree that genuine innovation is risky. I have observed that businesses often don't like "powerful" ideas because they are too risky from a business perspective. If done wrong, they can be very problematic. They also make recruiting more difficult because the ability to use and debug the powerful technique may be beyond what a manager or colleagues can test and interview for. They are sort of like the financial derivatives of software design: you can make a lot of money off them, but when things go wrong with them they really go wrong.

Businesses usually don't like that kind of risk, especially larger ones. Smaller businesses sometimes take such risks because they are willing to take a gamble to get a jump on the competition. But, larger institutions don't have the digestive system for such because managers are more often chewed out for what goes wrong stronger than they are rewarded for what goes well.

I have observed that businesses which avoid "powerful" ideas often lose competitive advantage to those which effectively leverage such ideas to improve productivity, sales, or product quality. Indeed, when things go wrong, they really go wrong, but when they go right, they really go right.

Documentation cannot compile, run or do useful work...

There are documents that aid developers in understanding the problem domain that are created by architects and business analysts and then there is documentation that developers create that are mandated by the lifecycle. Care to guess which one is backtested as having the most value...



Imagine firing up Notepad and writing a few hundred thousand lines of code in it so that managers can argue over your punctuation style and practice the fine art of word tweaking, only to months or years later try to compile and run it. What do you think the outcome will be?

Documentation is a sort of error-ridden prototype whose errors and glories are equally mysterious. Have you ever asked one of those PMP-certified Project Managers why they are passionate about documentation yet when forced to tell the truth would acknowledge that documentation is largely an unscoped effort? There is no clear indication of "done-ness." The result is the effort is largely driven by an end date and the number of bodies thrown at it.

Many people complain about the lack of documentation but never acknowledge that even if documentation existed, it would more than likely not be useful. Can we agree that good documentation requires thinking about people rather than computers, something anathema to most IT developers and architects. The vast majority of developers or IT employees at large are introverts by nature, so what do you think is the outcome of having them write documentation for others to consume?

Sometimes, the process weenies periodically move away from traditional waterfall thinking and embrace being Agile and iterative, but constrain the possibilities to documentation alone. Let's agree that if you make documentation a team sport and you do so upfront, that the majority of the team at design time doesn't understand the problem space well enough to communicate anything, as you are (by definition) still exploring it.

Consider the below scenarios and ask yourself which one would you prefer:

• A developer writes a great program. He finishes it completely and eliminates all known defects. However, he does not write any user documentation or documentation for other developers that follow him. He did however write self-documenting code.
• A developer writes a horrific application. She does not finish it and it barely works. She however thoroughly documents her approach, her assumptions and the code she already has, dead-ends and rat holes she's run into and the user requirements as to how they related to the chosen design

I am of the belief that documentation should explain decisions taken and not taken, Why an approach, architecture or algorithm was selected and what else was considered and rejected. Bet the developer in most shops wouldn't have documented this since he/she may not even have visibility into the choices made along the way. So, when you are asking for documentation, what are you really asking for...

A Developers Perspective on IT Project Management

Have you read the parable of the idiot flowers? Today, let's explore the relationship between IT developers and others IT roles...



Once upon a time, in a land far, far away there was a developer and a business customer where IT and the business were aligned. The developer and the business customer worked hand in hand to develop high quality working software. Iterations were frequent, quality was high and process was minimal.

One day, the developer was asked a strange question in which he didn't know how to answer. He knew he need some help from his peers but they didn't know the answer. The one day, out of the blue a person appeared wearing a cape. He was known as the Architect. The developer asked the architect for insight and the architect provided the answers with ease. The developer became delighted and wanted to work with him going forward.

The developer and architect were happy, they did lunch together but yet something still was missing. The developer wanted to spend more time writing higher quality code and figured it would be good if he could get some assistance in writing documentation, taking meeting minutes and being able to concentrate on things he enjoyed. Then out of the sky appeared a business analyst who came to his rescue and quality improved.

The developer, the architect and the business analyst all became happy friends and had a synergistic relationship. The three of them combined were able to do the work of five developers working solely and the business customer became even more delighted. The team wanted to improve and realized that they were close to perfection, but still wanted to get better.

The developer asked himself, is it a good practice for me to quality assurance my own code and concluded that testing before handing over to the business customer could further increase the delight of his business customer and the quality assurance engineer was born.



IT was at its peak, business aligned, delivering high quality working software in a cost effective manner. The team was whole and satisfied. Then one day, a strange person appeared on the scene carrying a checklist and a clipboard. Then team inquired as to who on the team requested this individual but no one did.

The project manager immediately started to implement requirements on the team that had absolutely nothing to do with delivery of software and instead changed the team's focus to process. Going forward, every time the developer talked with the architect, they were required to document their conversation. Over time, the team stopped talking to each other.

The project manager then introduced a methodology that was supposed to aid the developer in estimating how long something would take but over time, the estimation process started to take longer than the process of writing code and morale took a turn for the worse.

The project manager also required weekly meetings which caused everyone to wait till the meeting to discuss issues instead of talking with the frequency observed in the past. Not to be outdone, the project manager declared themselves emperor of all things IT and made the business customer talk to no one else.

Anyone care to guess why IT suffers from cost overruns, lack of business alignment or stifled innovation?