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.

Bookmark It...

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.

Bookmark It...

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.

Bookmark It...

The Systems Ontology is composed of three distinct parts:

• SystemThing holds the core concepts of a system – not to be changed
• SystemSpace is a definition of categories applicable to different concepts describing specific systems – should change rarely as the understanding of the different types of systems evolves
• System is the place for the instances of specific systems – may change regularly as the analysis and understanding of specific systems progresses.

The following diagram is a representation of the different elements in each part.

Core concepts and Spaces
Core concepts define the fundamental building blocks for the Systems Ontology in a set of abstract classes of mainly two types: Thing and Space.
Things describe the different aspects of a system on very high abstraction level (meta-meta in this case).
Spaces provide further refinement for the different aspects of a system.

Structure
The structure of the system is described in abstract sub-classes of StructuredThing. The structure defines the relationships between concepts, it defines what form (in terms of graphs) of construct can be built. Constructs can be for example: chain, ring, tree, net, a combination of these or any other formation.

Specific structures are defined inheriting from the StructuredThing abstract class, making StructuredThing a collection, a container of various types.

An example structure: ComposableThing has two slots, has_part and is_part_of (both are each other’s inverse), since has_part is a multi-value, is_part_of a single-value slot referring to instances, the structure for ComposableThing is going to be a tree.

Category
Categories are defined in the CategorySpace, which holds a hierarchy of categories underneath. CathegoryThing enables instances of a system elements to reference multiple categories from the CategorySpace.

CategorySpace is a bit unusual as far as modelling categories goes. Usually there is a meta-model for describing the characteristics of a category on the meta-model level then each category is an instance in the model often in some form of relationship with other categories.
In this case, a different, perhaps unusual approach is taken when categories are defined as classes and sub-classes of classes. This will allows to build a hierarchy of categories and use the class name for the name of the category, which should be sufficient as no attributes are necessary.
There is one more twist, instead of assigning a class (category) as a superclass to the categorized class, the CategorizedThing defines a slot with the value type of a class, in other words the category is defined as an attribute (slot).

This approach allows to define the categories in the meta-model in a hierarchy and still use them as an attribute in the model.

Life-cycle
The notation of life-cycle makes the concepts “alive”, in other words, it represents the time factor.

Individual life-cycles are captured in the LifeCycleSpace as sub-classes. Life-cycles consist of states, these are captured as instances of a life-cycle class in the ontology. LiveThing enables the system instances to reference individual states and other related instances – behaviour and quality (details in the next section).

Note that life-cycles are not described as proper state-machines in this ontology. There is no notation of events or state transitions other than registering the preceding and following states for each state instance.

Behavior and Quality
The following assumption was made: Only “living” things (ie concepts with life-cycle) show characteristics of behavior and qualities.
Based on this assumption, behaviour and quality details can be registered to any LivingThing.

Behavior and Quality are two concepts represented in the ontology in a similar fashion.
BehaviorSpace consists of sub-classes, where sub-classes are considered as categories of behavior. These categories can serve as a mechanism to group, qualify, arrange the long list of different behaviors a system may have.
Specific behaviors are captured as instances of a Class from the BehaviorSpace.

Qualities are represented the same way, where categories are sub-classes of the QualitySpace and specific qualities are instances of a class from the QualitySpace.

System instances
The root for capturing specific system instances is SystemSpace, it inherits a set of abstract classes (LivingThing and CategorizedThing) describing a system.

Besides creating instances for system elements a few other types of instances will be created along the way including: life-cycle states, behaviors and qualities.

States
Life-cycles consist of states, individual state instances should be created under the relevant life-cycle categories.
States are later referenced from system instances, where a system can only have one state at a time in the current setup of the ontology.

Behaviours and Qualities
Behaviours and Qualities are instances of simple classes in the pertinent categories. In the current ontology each instance is represented with a name (slot) only.
The categories should be carefully chosen for both set of concepts, otherwise can be time consuming to re-factor an instance of a quality into a category in order to register finer grain qualities. Same challenge applies to registering behavior.

Topology and Systems
Systems, and sub-systems, are captured in some form of hierarchy in the ontology – the Topology. The Topology for systems is not pre-defined as it mostly depends on the method applied to systems analysis, and somewhat depends on the different types of systems as well.
Topology is withing the System ontology, it is captured together with the system instances, unlike the categories for life-cycle, behavior and quality.

System instances are created within the topology, where they automatically inherit characteristics of LivingThing and CategorizedThing.
The topology does not have a notation of structure for system elements, therefore predefined (in the SystemSpace) structures should be applied as Super-classes to specific topology classes. Note that sub-classes in the topology will inherit structures from parent classes, for that reason structures should be used sparingly in classes closer to the root and should be applied to classes closer to the instances.

Data characteristics of system elements are defined within of the Topology by adding them to specific classes. Data details are esentially attributes (slots here) on a class. One should be careful making sure that data is not confused with structure. Slots with references to other system instances are perfectly valid data elements, however these can be easily confused with structure elements also represented as slots. The success of proper separation will depend on the rigour applied to systems analysis.

Bookmark It...

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.

Bookmark It...

It is not the most advanced book on economics, but the stories and anecdotes worth every minute of reading.

The most fascinating, and revealing part for me was The world’s worst library in the chapter Why poor countries are poor. It has a brilliant quote from Napoleon:

Never ascribe to conspiracy that which is adequately explained by incompetence.

Bookmark It...

Key note: The Domain Specific IDE by Steve Cook (Microsoft)
Steve has introduced DSLs briefly, talked about various patterns of use, then the main topic of software development using DSLs and the evolution of software development. He depicted SW evolution in quadrants and highlighted the path of evolution as: craftmanship > mass production > continuous improvement > mass customization.
A few highlights from the session

It makes sense to model concerns [IT Architecture].

[DSL, code generation] the only way to get some head-way is to make it economical.

To create a language [DSL], it really means to create a tool. The language itself is pretty useless in itself.

We have recognized that Visual Studio is a platform not just an IDE.

Bran Selic: Standardization [software development] goes way beyond standardization of API. One way to do it right is to standardize on semantics.

Experience Report: Evangelizing Code Generation: A case study of incremental adoption by Brooke Hamilton (FM Global)
Brooke’s session was pleasantly different than the other sessions during the conference as he was from the customer side and not a vendor or an academic. His presentation was brilliant, well structured, pleasantly constructed. Brooke had real details of his own and his team’s experience on their project(s) from the last few years. It was definitely one of the best presentations during the conference, it sparked a lot of good discussions.

Code Generation Narcosis – you feel more powerful using code generation than you really are.

Code generation improves architecture. It makes you look for redundant parts and separate concerns.

We cannot make an application serving unknown needs, but we can generate a lot of code!

Versioning of the templates [code generation] is absolutely crucial.

Tutorial: Strategies for generating code from Microsoft DSL tools and T4 text templates by Brooke Hamilton (FM Global)
This session was more of a demo using the Microsoft DSL Tools in the Visual Studio environment. Brooke also tailored in some of his experience with the tool and how it is applicable to their projects at FM Global.

* * *

In summary, it was an excellent conference with a lot of great presentations from the top experts on this field, great discussions during panels, BoFs and Goldfish Bowls. A lot of new ideas, thoughts and questions to take away to consolidate and look for answers until next year's event.

Bookmark It...

Tutorial: Model-Driven SOA: Synchronize Business Planning with the IT Design process by Ian Barnard (Telelogic)
Telelogic, recently acquired by IBM, presented a very corporate like view of modeling, the key buzzwords of the session were: EA, BPM, SOA, ELM (Enterprise Lifecycle Management), Model-Driven SOA…

Tutorial: Implementation Techniques for Domain-Specific Languages by Markus Voelter (Independent)
Markus is an entertaining presenter, he has a broad knowledge of the various topics around code generation and DSL. His customer experience also comes across and he makes genuine remarks about IT architectures and business-IT alignment.
This particular presentation was a deep-dive on DSL and implementation, categories of DSLs and their use, DSL implementation techniques and examples including: Scala, Ruby, Converge, EMF/GMF, MetaEdit+

DSL does not have to be turing complete!

execution != precision

Experience Report: Can executable UML make it as a Mainstream Programming Paradigm? by Allan Kennedy (Kennedy Carter)
The presentation started with a fair amount of philosophical discussion, involving the audience, about software intensive systems, software engineering, and modeling. Later Allan introduced the concepts, the use and value of Executable UML (xUML).
xUML seems to have impressive customer base and references including some defense industry customers and NASA.

Tutorial: Best practices for Creating Domain-Specific Modeling Languages by Juha-Pekka Tolvanen (MetaCase)
JP has recently published a book on Domain Specific Modeling (DSM) and I was very much looking forward to hear the details from the author himself. JP gave plenty of examples and details on best practices, lessons learned from his extensive customer experience. A great value from the presentation was to hear concrete numbers for developing with DSL. The statistics included variations for language complexity (number of concepts) and the complexity of artifacts generated (number of them and types).

Panel: Flexibility in Code Generation chaired by Jos Warmer (Ordina), Sven Efftinge (itemis), Anneke Kleppe (CapGemini NL), Laurence Tratt (Uni of Bournemouth), Steven Kelly (MetaCase)
The panel has eluded into many different topics in many directions including flexibility in DSL and code generation. From the questions and comments it seems that these concepts still have a long way to go to be more mature, precise and agreed on.

Unfortunately I’ve missed the Mistery Movie of the evening – Pirates of Silicon Valley – will catch up on that one day…

Bookmark It...

The first day passed really fast with lots of great topics and presenters. Below are a few interesting quotes and thoughts from the day.

Keynote: Matching Supply and Demand: Challenges in Model-Based Code Generation for Quality of Service-Constrained Software by Bran Selic (Malina Software Corp)

Bran‘s presentation had many thought provoking statements and questions in the domain of System Engineering with Quality of Services (Non-functional) requirements. Amongst many statements, the following was maybe the strongest hit:

Platform independent != Platform ignorant

Direct Code Generation with Built-in Flexibility by Anneke Kleppe (CapGemini NL)

An interesting talk about hard-coded (programmatic) transformations. She was talking mostly about the Octopus project. She emphasized a lot the importance of decomposition on many levels including not only the target application but also the code generator.

DSL model is not a DSL! Just like a .java file is not the Java language

is a reminder of how misused terminology and jargon has polluted not only this domain [DSL] but the whole IT industry.

Panel: MDD and Software Product Lines – a marriage made in heaven? Mark Dalgarno (Software Acumen), Juha-Pekka Tolvanen (MetaCase), Ian Barnard (Telelogic), Markus Voelter (independent)

On the volatility of investment in DSL and code generators (somebody from the audience):

The value of information captured in models (instances) is orders of magnitude larger than the investment in the meta-model, transformation, tools.

Goldfish Bowl: Approaches to DSL Evolution chaired by Peter Bell

First of all the concept of a goldfish bowl discussion is brilliant! I do not know how these work generally but this instance of it went very-very well.

The discussions were mainly skirting around the situations where the DSL changes. The typical questions came up were:

• What happens to the existing model instances?
• What happens to the existing code generators?
• Is there a way to make the transition (evolution) automated?

Tutorial: Concrete Syntaxes of DSLs by Arno Haase (Haase Consulting) and Sven Effinge (itemis)

It was a fairly basic overview of various DSL and DSM approaches with a demo of openArchitectureWare‘s tools. The demo was a nice example of using textual modelers (xText) together with graphical editors (GMF).

Birds of a Feather: The Art of Abstraction

The main theme for this BoF was to list and discuss the considerations that make a DSL a good DSL.

Bookmark It...

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…

Bookmark It...