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
      • Health check services
        • Arch Risk Assessment
        • Arch Governance checkup
        • Arch Models health check
        • Arch Content health check
      • Business Architecture
    • 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
    • Case Studies
    • Location
Site Search
Strategy

EA strategy maturity (2008)

  • 2008-10-052018-05-03
  • by Charles

I was recently asked to review an IT Strategy document and give my views on it. This document did not appear to come from what I would have called an Enterprise Architecture practice but from a typical IT approach to strategising about how to deal with all the technology in the IT department.

Before starting I thought to myself, what standard should I score this against? This then lead me to think about different levels of Maturity of Strategy implementations (in this case an IT strategy), but it could be used for any strategy I suppose.

Basing my thoughts on the CMM definition I came up with this table below in terms of the levels of sustainability, repeatability and continuous optimization of Strategy:

 

Level
Conscious
Planned
Governed
Quantitative
Continuous
Description
0 No No No No No Chaotic – Unconscious of Strategy
1 Yes No No No No Initial – Cognitive Strategy
2 Yes Yes No No No Managed / Planned Strategy
3 Yes Yes Yes No No Defined and Governed Strategy
4 Yes Yes Yes Yes No Quantitatively Managed Strategy
5 Yes Yes Yes Yes Yes Continuous Optimizing Strategy

 

So level 0 is where there is zero concept of any strategy. The organisation just muddles on, project by project, request after request – firefighting.

Level 1 has a cognitive concept that strategy is important and tries to implement it from a mental model, and give direction in conversation to people, but no more. This tends to come from someone leading but is perhaps not general knowledge in the department.

Level 2 is where a plan has been derived and planned, based upon gathering information in some one-off exercise. This is typically put together for the budget in order to justify funding for the next year or three. Thereafter it is cast aside, once the money has been obtained and the projects have been defined.

Level 3 takes this to the next level, because not only is it planned but over time, it is managed and governed, to ensure this strategic plan actually happens. The reason this has been differentiated as a separate item is because in my humble experience, many of the best laid plans fall away after a few months, as people change positions or business changes occur. Eventually the initial strategy is forgotten, and things devolve into firefighting again unless governed against a baseline. Obviously this does not imply that the baseline cannot change, in fact it will change, but if a new baseline is derived then the governance can continue to monitor progress against the new strategic baseline.

Level 4 goes up another notch by measuring the Strategic Architectural goals met against the initial plan versus the actual delivery. Even if Waivers and Dispensations are given, and these are measured, we have an adea of convergence or otherwise towards the strategy. Capturing daily, weekly and monthly Architecture review board activity metrics, and reporting them regularly over time. This also begins to imply that the Strategy is captured and managed as well, because if things change, we need to record the differences from the initial baseline to the new baselines over time of the Architecture.

Level 5 is where the Strategy evolves continuously, due to the above processes of monitoring, persisting the information and governing the change in a managed way on a regular (weekly to monthly) basis. Weekly. Eventually we reach the situation where it would not be necessary to do a one-off Strategy once per annum for the budgets, but to do one and keep continually refining it and governing it. When budgets are submitted, it is a simple matter of printing out a few diagrams and reports from the decision support system that already exist, ordered by highest risk and current business drivers.

All this would require a foundational set of configuration management, change management and iterative planning to keep on top of the “Models” be they visual or otherwise that make up the Strategy.

Based upon this maturity – the document and it’s contents I saw reached somewhere between 2 and 3, but I was not privy to how they would manage or govern it so I could not say for sure, as its not only about the actual document, but also about how we manage the Strategy over time that makes it more mature.

Enterprise Architecture

An Introduction to the Major EA Methodologies (2008)

  • 2008-05-302018-05-03
  • by Charles

Presentation

This talk was given in New York City at the International Association of Software Architects (IASA) on Friday the 23rd May 2008 by Roger Sessions. He has kindly given us permission to publish his talk here.

The presentation introduces Enterprise Architecture and the does a comparison is between: Zachman, TOGAF, FEA, AgileEA, VPEC-T and SIP.

Download

This presentation can be downloaded in PDF form from here: An Introduction to the Major EA Methodologies

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.

Posts navigation

1 2 3

Categories

Tags

#digital Agile AgileEA-Process archimate architecture practice BIAN business-arch Business Object MOdels Business Uses cases Capabilities cloud culture Data Architecture Employee Enablement Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt Use Cases Values visual models Worker Workforce

Recent Posts

  • BIAN in Archimate 2019-04-05
  • Digital Workforce Enablement 2019-02-08
  • 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

Previous Posts

Our Twitter Feed

My Tweets

Recent Comments

  • Homepage on BIAN in Archimate

Translate language

Tag Cloud

#digital Agile AgileEA-Process archimate architecture practice BIAN business-arch Business Object MOdels Business Uses cases Capabilities cloud culture Data Architecture Employee Enablement Enterprise Architecture health checks IoT maturity openstack Requirements Services strategy System Use Cases techical debt Use Cases Values visual models Worker Workforce

Blogs about

AgileEA Process Blogs Cloud Openstack Digital Enterprise Architecture Health checks Information & Data Modelling Strategy Technical Debt Thoughts Use Cases

Contact Information

To ask any questions you may have, contact us via:

: make an online enquiry

: +27 61 8495792

: linkedin.com/in/charlesedwards

: charles.edwards.skype

: @Charles_Edwards

Copyright: Time 2 Talk CC TA AgileEA.com, 2006 - 2019.
Theme by Colorlib Powered by WordPress