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
Architecture Maturity Assessments Health checks

Why do Architecture Maturity Assessments regularly?

  • 2017-03-222018-05-08
  • by Charles

What shape is your Architecture practice in?

Do you know what shape your company’s Architecture team are in health-wise? You should test your team against some form of Industry or third-party benchmark. Architecture Maturity Assessments should be like clock-work. Once a year.

These maturity assessments tend to be expensive, time consuming and get in the way of day to day business. So assessments are not done often enough to keep track of progress or regression. So practices muddle on without much realisation about what needs to improve.

What is Architecture maturity?

Based upon the premise that all Architecture Practices have some form of life-cycle. Much like a human goes though from foetus, to baby, to childhood, to adolescence, to adulthood. Starting from very immature ⇒ very mature.
  • Architecture practices start off being non-existent nor recognised as a capability. A few good people fighting the good fight.
  • Then practices become more formal and recognised but still reactive. A team where individuals each do their best to fight the good fight.
  • Then practices become proactive, functional and repeatable. A team which do their best according to their method to align the architecture.
  • Then practices move towards better integration with other structures. With better communication to more stakeholders. A team which do their best according to their method and integrations to other teams to align architecture.
  • Finally they become ubiquitous. They drive out business value outcomes as part of the daily function. A team whose raison d’etre is understood and their methods and business alliances make a massive difference to the efficient and effective business operation.

 

Measuring your Architecture maturity

So how would you like to find out where you stand once a year? In a series of 10 minute surveys by each of your Architects. For Free. And what the next best recommended steps should be, to improve this situation. You’ll also get a Radar chart like this one to show you your assessment for this year. Looks like this model below.

 
It’s always easier coming from a 3rd party than from within, even if you know what to do. Once an area of weakness is identified, there are more detailed health checks to get into detail if required.

Benefits of doing an assessment

  • It’s quick – 10 minutes of each assesee’s time.
  • It’s easy – Minimal questions to cover your entire architecture capability.
  • It’s free – Avoid expensive audits that by the sheer cost only happen once in a blue moon.
  • It’s impartial – Get a 3rd party impartial view of your architecture practice.
  • It’s based on industry standards – BAMM, TOGAF, Gartner, etc.
  • It’s repeatable – Because of the above it’s easy to do once a year and keep a track of progress

 

Want to take it further and do the free assessment?

If you are interested, read up more on this free health-check Architecture Maturity Assessment service.

 

References

  • Measuring business architecture capability maturity
  • Gartner.com – Scoring Enterprise Architecture
  • ErWin – Why Enterprise Architecture Needs Maturity Models
AgileEA Process

EA Conference 2009 – Agile EA: A Step change…

  • 2009-06-132018-05-08
  • by Charles

Abstract – Agile Enterprise Architecture Step change required

This was the presentation given at the RealIRM EAC 2009 in London.

The title was Agile Enterprise Architecture: A Step change is required.

Download

Get the .PPT here (4.2 Mb)

Enterprise Architecture

Who should own Enterprise Architecture?

  • 2009-03-282018-05-08
  • by Charles

The clue about Enterprise Architecture ownership is in the title. One of the issues I see as an EA practitioner all the time is the fact that Enterprise Architecture typically falls within the IS/IT Department remit within many enterprise organizational structures and not where I believe it ought to be positioned. EA should be part of the Strategy Department under the CEO and therefore divorced from either the Supply or Demand side of the Enterprise, thereby governing from a neutral position and informing the executives of the enterprise. EA positioned within IS/IT it’s like having two opposing Lawyers in a court room where one of them is also acting as the Judge; the verdict is always only going to go one way.

Why is EA in IS/IT mostly? The reasons for the evolution of EA being owned within the IS/IT department are quite understandable. The practice of Engineering and Architecting systems and systems-of-systems stems primarily from the Technical domain rather than the Business domain, out of a need to build and supply rigorous software and hardware systems.

The business domain have used simpler diagrams to show concepts, to collaborate on ideas and thoughts, but till more recently the business have never had to be very rigorous other than in the financial sense. More recently the business domain is dealing with more formal business processes diagrams that generate working software, so the rigour is beginning, and so too is the understanding.

Whereas the Technical domain has relied on a far more rigorous diagramming notation to formally build and help implement systems. Architecture does not stop at diagrams; Requirements have to be formally managed and traced, Configurations of systems have to be managed, Change controls have to be managed, Testing, Hardware connectivity for LANs and WANs have to be formally managed, etc.

The common currency between the Supply and Demand has been money, time and power. All discussions have come down to the first two with the third making the final call. These are only the tip of the iceberg. Unfortunately none of these involve complexity and the buildup of “Enterprise Technical Debt“.

Hence the practice of building up Architectures and being able to Govern and manage complex systems has mostly evolved from the Engineering side. The Technologists have understood why this is important to them. They have built mechanisms to cope with complexity such as Abstractions, Visual Modelling, Configuration and Change Control management systems, Reusability, Services, Test, Build and Deployment automation, etc.

So with this in mind, if you look at an Enterprise from a Supply and Demand point of view, in general Business drive the Demand and Technology Supplies the solutions. On the demand side you would expect to see motivation, direction setting and strategy, which ties into the time and money available.

On the Supply side you’d expect to see a reply to that Demand given certain principles and constraints such as ensuring re-use, avoiding duplication of resources in terms of Servers, Data, Functionality, etc.

Put all this into a negotiation between Demand and Supply and somehow out of all of it, certain compromises get made on both sides.

Generally Business give up functionality and Technology gives up coherent Architecture. In order to control and regulate these conflicts of interest IS / IT departments have implemented Governance processes, at various levels, Programme and Project, Architecture, Service management, etc.

The challenge is that as the ever technically savvy Business submit Demands on the Technology Supply side, how can IS/IT possibly govern these compromises if they are not empowered to straddle both sides of the debate? An IS/IT based Architecture governance is not in a position to rule against the Business, particularly if the Business hold the purse strings and are the Demand “Customer”.

Consequently IS/IT want to make themselves look good by trying to deliver on time and within budget, and start compromising on their own principles by ignoring the Architecture governance outcomes, or offering endless Waivers and Dispensations. Many Supply side Risks and Issues are never feedback into the Business on the demand side, and even if they are fed back, many times it’s too late or the business cannot interpret the meaning. Ultimately the Enterprise is compromised over time.  The Enterprise Technical Debt builds up and builds up until all ability to make any change at all becomes impossible. Any change costs too much or takes too long. All Agility is lost.

Instead if a small Enterprise Architecture team of practitioners made up of Business Architect(s), Information Systems Architect(s) and technology Architect(s) are put into a “Strategy” team under the CEO, who liaise closely with the IT Solution Architecture team, and the Business subject experts then, the equilibrium should be restored. The IT Solution Architects should still remain under the CIO and not directly report to the “Strategy” (or some more meaningfully named) EA team. This assumes a lot of collaboration, communication and engagement between all parties. The “Strategy” EA team should have the necessary technical and business background to feedback the overall Risks in the business and thereby avoid the inevitable Enterprise Technical Debt build up over time.

AgileEA Process

Putting the Agile into an EA process (2007)

  • 2008-07-252018-05-08
  • by Charles

Abstract

In March 2007 Charles delivered his first talk about the Agile EA operational process at the Togaf Conference in Cape Town South Africa. Read up on the content here:

http://www.opengroup.org/capetown2007

http://www.opengroup.org/capetown2007/edwards.html

Download

pw2007-Togaf-PuttingThe’Agile’IntoAnEAProcess-V1.1.pdf

AgileEA Process

Building a case for an Agile Enterprise Architecture Process…

  • 2007-02-042018-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.  Enterprise Architects starting a new practice say “There is so much to do and so much complexity. Where do we start? How do we move forward in a structured and well defined way, but still add value to the organisation quickly?”

The goal of this second paper is to suggest using existing standards to drive out solutions to the problems EA Practices face (as posed in the previous Part 1 paper). To suggest a set of standards upon which an Agile Enterprise Architecture Process could be more specifically defined. Processes to help Enterprise Architects get started quickly and easily.  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.

Download

This can be downloaded in PDF form here: Agile Entperise Architecture V1.0 – part 2

Posts pagination

1 2 3

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 - 2024.
    Theme by Colorlib Powered by WordPress
    Agile Enterprise Architecture
    Proudly powered by WordPress Theme: Shapely.
     

    Loading Comments...
     

    You must be logged in to post a comment.