Blogs

Thinking through EA Modelling

A chap from Troux technologies made some very interesting and enlightening points about Enterprise Architecture Modelling at a seminar in London recently. For me it was one of those Eureka moments, but also one of those things you’ve sort of known all the time but couldn’t put your finger on it and pin point exactly.

He was saying that historically software developers have seen the benefits in visually modelling the designs of software. We all know the old adage “A picture paints a 1000 words” that led to a proliferation in Modelling and Diagramming Applications (or are they called Tools? Why are we obsessed with calling Business software ‘Applications’ and IT software ‘Tools’? The subject of a separate blog no doubt.)

Visual modelling has grown organically from software development projects in IT outwards towards Enterprise Architecture in visually modelling and diagramming the various aspects of the organisation.Essentially a “model” captures entities and relationships and this information can be shown either visually in some notation or textually in lists of information based on some query. Intuitively though, the term “Model” implies “Visual Diagram” to most people; more than what it actually is “a well defined rigorous interconnected structure”. He also mentioned the other obvious meaning of Model such as those in London Fashion week, etc. Model can be a weather prediction system, Model can be a version of Car, or small plastic aeroplane stuck together using superglue.

The logic has been something along the lines of:

• We need to capture information about the enterprise rigorously.
• Rigorous information is made up of Things (Entities) and various types of relationships between the things (Associations).
• We could do this in a relational database or in a visual modelling tool – ideally something that has both elements.
• Database – We don’t have the time to design and write a whole database with associated visual modelling in order to do this properly.
• Visual Modelling – We could make use of a Visual Modelling tool, which by nature allows us to diagram and model rigorously.
• We also need to be able to store this information in a central or federated database.
• We also need to be able to change the terms and relationships and icons in the underlying meta-model.
• We also need to be able to report on this information. Oh great this modelling software allows that (well – sort of – I did a whole talk on this at the IBM Rational Conference in 2007)
• We also want to publish all of this to the web for easy distribution.
• Oh great this modelling software XYZ allows all that.
• Or much worse. Let’s use Visio! (I have nothing against Visio actually it’s a damn fine product, just does not enforce rigour and store things once in a database)
• Ok, so off we go…

Then some time later (months or years if we have managed to survive the politics of non-delivery that long):

• Well we managed to build a meta-model which took us some time.
• Well we’ve managed to get all this information into the Modelling tool, now lets query it.
• Whoops not very easy to extract and report on information easily.
• Whoops we have to buy an add-on to get it published to the web.
• Whoops its not in real time, we have to manually generate output to the web.
• It is a little difficult and time consuming to do impact analysis.
• It is a little difficult and time consuming to do web publishing.
• We’ve got too many visual models and not enough database manipulation ability.
• Its not easy to navigate these visual models on the web, they don’t zoom and scoll easily, etc.

This is where Troux have made great strides technically I believe (and in some cases other vendors):

• What we really need is a Web portal based tool that allows input and output from the web directly. Always up to date information.
• What we really need is some sort of BI tool at the reporting and output end to optimise the queryability.
• So lets look for a tool that not only has a visual capture and DB capture mechanism but also one with a Data warehouse and BI output.

But even Troux have issues, because guess what? BI tools are weak in the Visual output of information.

• BI and reporting tools tend to be more Textual than Visual.
• So now Troux have generated reports using the BI tool, but make up for certain Visual Querying where BI tools fall short until the BI tools catch up. Good on them.

So what is the upshot of all this? He was saying, if we think about what we mean by Model, then we will realise its more than just a set of Visual diagrams. It’s more about a well defined and interconnected System of Virtual Information about the Enterprise from which you can derive IT wide Decision Support. Actually I prefer to think of it as the missing piece in the overall Knowledge management of the whole Enterprise, IT just happens to be one of the users of this information, and it has stemmed out of IT by necessity.To me it’s about:

• Being able to split the concepts of Visual Models and Database textual information up into Input, Processing, Interfacing and Output.
• Input – How do we capture the Entities and their Relationships? Ideally though using both Textual or Visual Modelling input.
• Processing
  • Views and Viewpoints – The ability to take one of many dimensions, e.g a Cost view and see all models (diagram and text) though this filter. Or a Strategy View, or a Policies View, or one of potentially hundreds of definable Views, etc.
  • Motion – Animation on models, to turn 3D into 4D over time. e.g. Visual As-Is to one or many To-Be alternatives.
  • Better Config Management. e.g only Publish everything that conforms to a baseline as at the end of last week, even though we are working on new changes to the central model which we will release next week. So this means version control, Version-of-collections of versions etc.
  • Non-rigour Capability. Ability to contain, store and preserve not only Rigour and Predictable process type information, but also the less mechanistic and highly valuable un-predicatable, changing and loosely connected information in something along the lines of a wiki. (Subject of a separate blog later.)
• Interfacing – Control in both directions (inward and outward) of feeds into and out of the model. Into using fancy ETL controls to ensure the Model integrity. Outward in terms of exposing the Data and Visual Query Services on an ESB for the rest of the enterprise to access where necessary in their applications.
• Output – How do we report on extract information from our Entities and their Relationships? Ideally though Database and Visual Modelling output. Some things are better understood in a textual form, and others in a Visual form. Ideally both mixed.