Classic case

A project ran to build a system for capturing customer details, soon after the delivery another project build the customer update system.

Now, this is just one of many ways of building technical debt, but really the culprit is the organisational thinking behind this phenomenon. What has happened?

The analysis

Ignorance is NOT a bliss – as it would turn out during the acceptance test, when customer details were captured, but they could not be modified or updated later. However, the project was coming to a close (it was already in acceptance test) and budget was running short as well. So what does one do to fix this situation? Run another project to build another system to update customer records.

Why not extend the current system on the next project, why build a new one? There could be many reasons for this. One possible reason stems from how IT projects are accounted for. New build becomes an asset (capital expense), but updates don’t (operational expense). However, this is not entirely correct. Updates that deliver new capability or functionality can become assets, but that’s too complicated to understand or to split project costs accordingly, so it is easier to launch new project for a new build and new asset.

So there you go, the organisation ended up with two systems instead of one; although it probably could have spared that single one too if the first project took the effort to look around the rest of the organisation for an existing solution.

Who cares?

Surely it is not such a big deal, it happens all the time.

Sarcasm aside, in fairness, it the big scheme to things projects are these are only a small drop. Even if the costs are doubled (two projects) and the duration has doubled (worst case) it won’t break the organisation, however this is where the spiralling starts pulled by two forces:

1. Projects running late – especially in IT – is almost the norm, so projects do not even bother with much upfront planning and preparation (called the pragmatic approach) and trying to keep scope to absolute minimum. These poorly conceived projects deliver poor systems even if execution was perfect.
2. Exceeding project costs are not a problem either because the business will “sweat” the assets anyway to recoup the loss and to squeeze as much out of it as possible. This is how those poor systems survive and stay around for long.

The result: technical debt.

Let’s hope they do not find that they need to delete customer records one day…

The book I have just finished reading – Where Good Ideas Come From by Steven Johnson – had an interesting chapter on The Slow Hunch innovation pattern.

The part in there that really caught my attention was about the common-place-book. The following historical quote from John Mason in 1745 makes the case for organised (retrievable) thoughts:

Think is not enough to furnish this Store-house of the Mind good Thoughts, but lay them up there in Order, digested or ranged under proper Subjects or Classes. That whatever Subject you have Occasion to think or talk upon you may have recourse immediately to a good Thought, which you heretofore laid up there under that Subject. So that the very Mention of the Subject may bring the Thought to hand; by which means you will carry a regular Common Place-Book in your Memory.

In the same chapter, the historian Robert Darnton is quoted on re-organising texts into fragments and removing the linearity of the text:

Unlike modern readers, who follow the flow of narrative from beginning to end, early modern Englishmen read in fits and starts and jumped from book to book. They broke texts into fragments and assembled them into new patterns by transcribing them in different sections of their notebooks. Then they reread the copies and rearranged the patterns while adding more excerpts. Reading and writing were therefore inseparable activities. They belonged to a continuous effort to make sense of things, for the world was full of signs: you could read your way through it; and by keeping an account of your readings, you made a book of your own, one stamped with your personality.

Later in the Serendipity chapter – another pattern involving accidental connections – the author mentions DEVONthink, a tool to manage and organize all those disparate pieces of information. DEVONthink features a clever algorithm that detects a subtle semantic connections between distinct passages of text.

And this is where I would make the connection with my previous post about Enterprise Architecture: A Slightly Different Approach – making the case for capturing and managing enterprise knowledge in a Semantic Wiki.

My objective as an IT Architect (ITA) is to make sure the money spent on IT delivers a good return on the investment. The variety of ITA disciplines contribute to this in different ways; and it is no different for Enterprise Architecture (EA).

So what is different about the approach, as hinted in the title?

EA is about Information – information about the enterprise, information that will help to make informed decisions at an enterprise scale. Following is a roadmap to for building up and maintaining this information about the enterprise.

Enterprise-wide initiatives require enterprise-wide tools – Excel!?!? Like it or not, Excel is the universal tool in many places to

• collect data
• share information
• organise information
• and more…

Is it a good thing, or is it curse? Most likely it is not good, but it is not going to change for a while.

But not all is lost, there are ways to leverage the content from spreadsheets and reuse them elsewhere (other than Excel) or turn them into something more informational.

1. Some of the tools provide with direct Excel import/export functionality.
2. Since the 2007 version, Microsoft (Office) Excel offers an XML import/export function (not the save as .xlsx), where a user defined XSD (Excel schema) is mapped to columns on a sheet. The XML files can subsequently be transformed through XSLT to other formats for interacting with various tools.
3. It is rather easy to extend Excel using Visual Basic scripts (macros) to generate the output that is easily or directly imported into various tools.

The next blog entry will be on this last (3) option – how to use a macro in Excel to generate content for visualisation in yEd.

Countless times the Enterprise Architecture (EA) discussions end up in debates over some analogy trying to explain what EA is. The analogy often used is traditional architecture.

I am not a great fan of the traditional architecture analogies myself, by the way I feel the same way about the use of car manufacturing. These analogies often fail to meet the level of abstraction on the two sides of the analogy, and the conversation soon becomes a debate which architect designs the brick, or the piping; which one is responsible for a specific floor of a building, or is it the whole building, maybe the whole city? and it goes on and on…

At the same time, I have to admit whatever helps to get on the same page with a team of people will just work fine. To help the situation I have looked for materials on the Web to support the analogy. I have found the following PDF (size warning: 3.7MB), which I thought was brilliant in itself – it is a great piece of work (competition entry) from a team. It also supports the breadth and depth of architecture that can be related to the various IT architecture disciplines, including EA.

The link to the document is here. Unfortunately the original document is not available at the original location anymore, which was at http://udcompetition.uli.org/ under the 2004 archives. More designs can be found in more recent archives, under the results page.