Skip to content
Agile Enterprise Architecture
  • Home
  • Services
    • Remote Services
      • Looking for EA modelling?
      • Why Arch-as-a-Service?
      • Modelling-as-a-Service
      • Assess Arch Maturity Free
      • Arch Modelling Notations
        • Archimate model types
        • Quadrant model types
        • Canvas model types
        • UML model types
        • BPMN Model types
        • DMN Model types
        • ERD Model types
        • Structured Info types
        • Cisco model types
      • Arch Modelling tools
    • Consultancy Services
      • Digital Integration Services
      • Business Architecture
      • Health check services
        • Arch Risk Assessment
        • Arch Governance checkup
        • Arch Models health check
        • Arch Content health check
    • Cloud Hosting services
      • EA SaaS – Orbus iServer
      • EA SaaS – EVA Netmodeler
      • EA SaaS – Dragon1
      • Meta-Model Structuring
  • Blogs
  • About
    • Our AgileEA Business Model
    • Our AgileEA Principles
      • Open & Transparent
      • Value for money
      • Keep it simple
      • Love what we do
      • Efficient & effective
    • Location

Blogs

Modelling

Thinking through EA Modelling

  • 2008-09-222018-05-08
  • by Charles

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.
AgileEA Process

Agile Enterprise Architecture – Part 1

  • 2006-12-142018-05-08
  • by Charles

Abstract

This series of papers considers the case for enhancing the good work the Open Group contributors have already produced in TOGAF 8.1 [1], by defining an lean and mean Enterprise Architecture (EA) Practice Process that can be picked up and used with minimal tailoring to get an EA Practice started quickly. Enhancements to the TOGAF process are to be based primarily on the newer and beneficial thinking Agile and Adaptive [10] principles, but on other influences as well. The goal of this first paper is to look at the Concern Viewpoints that an Agile EA would potentially solve. Future papers will look into the potential solutions options. The paper assumes a little knowledge of TOGAF.

Download

Access the PDF here: Agile Enterprise Architecture – Part 1

Posts navigation

1 … 7 8 9

Categories

Tags

Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

Recent Posts

  • Announcing Our Train44Ir.org charity 2020-04-24
  • Data Fabric Framework – Archimate 3.0 model 2018-05-10
  • OpenStack Cloud Metering in Archimate – Part 10 2017-04-28
  • OpenStack Cloud Orchestration in Archimate – Part 9 2017-04-28
  • OpenStack Cloud Identity in Archimate – Part 8 2017-04-28
  • OpenStack Cloud Object Storage in Archimate – Part 7 2017-04-28
  • OpenStack Cloud Images in Archimate – Part 6 2017-04-28
  • OpenStack Cloud Block Storage in Archimate – Part 5 2017-04-27
  • OpenStack Cloud Compute in Archimate – Part 4 2017-04-27
  • OpenStack Cloud Networking in Archimate – Part 3 2017-04-27
  • OpenStack Cloud Dashboard in Archimate – Part 2 2017-04-27
  • OpenStack Cloud in Archimate – Part 1 2017-04-27
  • Hosting and Cloud Software Delivery modelled in Archimate 2017-04-19
  • Why do Architecture Maturity Assessments regularly? 2017-03-22
  • Archimate 3.0 introductory basics videos 2017-02-28
  • Example Services and Capabilities with Meta-Model 2014-11-09
  • Why a CV in Archmate? 2014-07-14
  • Charles Edwards Archimate CV 2014-07-10
  • EA Conference 2009 – Agile EA: A Step change is required 2009-06-13
  • Who should own Enterprise Architecture? 2009-03-28

Previous Posts

Our Twitter Feed

My Tweets

Recent Comments

    Translate site

    Tag Cloud

    Agile AgileEA-Process archimate architecture practice business-arch Business Uses cases Capabilities cloud culture Data Architecture Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt train44ir Use Cases Values visual models

    Blogs about

    AgileEA Process Blogs Charity Cloud Openstack Enterprise Architecture Health checks Information & Data Modelling Strategy Technical Debt Thoughts Use Cases
    Copyright: Time 2 Talk CC T/A AgileEa.com, 2006 - 2023.
    Theme by Colorlib Powered by WordPress
     

    Loading Comments...
     

    You must be logged in to post a comment.