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.

Nearly all the banks I worked with treat IT as a second class citizen in their organisation. Some have developed this culture further than others. This would be an ancient method of doing business in any industry, it is even more so in the banking industry.

Why?
The financial services sector has been through some interesting changes and transformations over time.
Take money as an example which has taken forms of golden bars, silver coins and paper notes, plastic cards and most recently just information (bits and bytes).
Similar changes have taken part in the customer basis as in focus and in size, risk management as well as fraud and crime, and many more areas.

In an industry where information became the spinning ball and handling information is the game, how long can the player survive who is failing to recognise the role of Information Technology (IT)?

It seems there is a chance that the behemots and clumsy can survive pretty long and stay in the game, but not without risks:

• economies of scale is on their side – although when things go bad, they go bad big time
• risk averse behavior is a safe play – not a winner against competition especially when the economy is up
• creative practices – try that trick when regulation is closing in, and it always does

What if there is a player in the arena who recognises that business is about managing information, information is best placed with IT, and business better leave information management to IT?
As it happens, there is an expression out there for such synergy – business and IT alignment – often taken lightly and hardly anything more than a wordy item on the list of marketing promises, missing the catchy buzzwords and lacking of elegant phrases like “the art of the possible”.
Despite its shortcomings and the slim chances of making it on the list of promises for Web 4.0, it could have some substance to it when it is played well:

• business will get an answer to their questions; and maybe even get the right and honest answer
• IT will know how to answer and will answer fast as they should without costing an arm and a leg

The banking industry must try – IT may get it right.

A good definition for Ontology (in computer science) is available from Wikipedia.

An ontology … is a formal representation of a set of concepts within a domain and the relationships between those concepts. It is used to reason about the properties of that domain, and may be used to define the domain.

The tool of choice

Protégé Ontology Editor and Knowledge Acquisition System has its root in Medical Informatics, it was made to capture medical information in a structured manner to form a basis for medical knowledge that can be processed, searched, queried later.

My intent of using an ontology was quite similar, but I targetted a different domain: Enterprise Architecture.

A few pointers that supported the idea:

• Using ontology to support development of software architectures
• Enterprise Architecture Model and Repository
• Federal Enterprise Architecture Reference Model Ontology (FEA-RMO)
• Building Internet Distributed Computing Applications, Knowledge mining at the enterprise level

There are articles also available on the Web arguing the use of ontologies and Protege as a tool for supporting Enterprise Architecture.

More links for research the use of ontology:

• Ontology Building: A Survey of Editing Tools
• Ontology Tools Survey, Revisited
• An older (2002) comparison table for Ontology editors

OK, it is Protege, now which version?

Protege offers two versions – V3 and V4 – of the tool, where the new major version is significantly different from the previous. The Protege Web site also offers a side-by-side comparison helping with the decision.

My take on deciding which version to use:

• OWL is not made for human consumption and at this point in the tool’s life too much OWL is exposed in the interface
• No Frames support means no interface to populate the meta-model (ontology) with instances – another reminder that OWL is not designed for human consumption
• V4 is beta at this moment, while V3 is a mature ironed out version
• There is already a tool to help migrating Frames to OWL, once V4 has the functionality and stability of V3 then moving to the new version should be relatively straight-forward
• If you do not need OWL, just use Frames – V3!

There is more coming on how to use Protege to support Enterprise Architectures.

…That is the question.

I have recently earned my TOGAF Certification after following the certification course from the Architecting the Enterprise folks.
More and more of the projects dealing with Enterprise Architecture (EA) demand the knowledge of some EA framework and method. TOGAF is one of them and the demand is increasing.

While it is great to see the increasing need for EA, it is worth noting that TOGAF is not the final answer. TOGAF is a framework (there might be a clue in the name) and it hardly provides any further detail as to how to perform an EA engagement, how to develop EA, how to govern the EA…
It is a great place to start enlisting the high-level concepts [of EA] and their relationships. However, breaking down those concepts to a finer grain, discovering the relationships and concerns between them, making archiectural decisions or providing guidelines for decision making (and more) is still left to the Business and IT Architects.

A particularly interesting area for me is the tooling support for Enterprise Architectures. There are a few products already available on the market offering tooling support for different domains in EA.
I strongly believe that Domain Specific Languages (DSL) and Domain Specific Modeling (DSM) tools have a great advantage and use for the purpose of supporting EA. I will be investigating this area more in the future.

If you are registered in LinkedIn, I would recommend to join the TOGAF Certified Architects Group by following this link.

The picture used in this blog entry is originally from Cartoon Stock…