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.

Recently I have started using yEd, a free (not Open Source) graph editor, to produce IT Architecture diagrams.

It is written in Java and runs on many platforms: Linux, Mac OS, Windows… It supports a the graphml file format describing graphs. It provides the most essential visualisation features including

• Boxes
• Arrows between boxes
• Boxes in boxes

The real highlight of the product is the sophisticated layout algorithms it offers. The other key feature is the export of graphs in a variety of formats including: SVG, PDF, JPG, etc

What is it good for?

I am planning to automate the production of diagrams for IT Architectures. This application will not replace sophisticated drawing tools due to the limited graphics capabilities, but the plan is to use it for generated diagrams anyway. Where the tool excels is the variety of layout strategies and algorithms it offers to arrange the diagram elements on the canvas, and it can deal with a large number of elements and produces impressive results.

Why not use Visio?

Although it does not offer the same level of sophistication and representation as Visio, it has the advantage of automating the production of diagrams. I am looking at a variety of input sources and driving those through “good old” XSLT to get the result – graphml file. In fairness Visio also supports XML, however the graphml format (including the yWorks extensions) is far less complicated to process. A big advantage over Visio is the support for ‘box in a box’ structures, in other words containment. Visio can only support ‘box over a box’ which is just an imitation of the structure.