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

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

    Our Twitter Feed

    Copyright: Time 2 Talk CC T/A AgileEa.com, 2006 - 2021.
    Theme by Colorlib Powered by WordPress
     

    Loading Comments...
     

    You must be logged in to post a comment.