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
Technical Debt

Calculating Enterprise Technical Debt

  • 2009-04-192018-05-08
  • by Charles

Abstract

This paper proposes a simple mechanism for calculating the Money Future Value of Enterprise Technical Debt (ETD) showing a simple worked example, so that the business people can understand the financial implications of their Tactical versus Strategic technical architectural decisions.

Download

Version 0.02 can be downloaded here: Calculating Enterprise Technical Debt v0.02.pdf

Technical Debt

What is Enterprise Technical Debt?

  • 2009-03-282018-04-22
  • by Charles

If you’ve ever tried to write a Business Case for justifying an Enterprise Architecture Practice, justifying it with all its promises of delivering a “utopian” better world, you’ll agree that to translate what for technologists and others who “just get it” think of as “…just so obvious and why would we even want to discuss the why’s – in these days of financial crisis – let’s just get on with it and not waste any more time and money describing it while the enterprise flounders…”

Enterprise Architecture when implemented correctly helps maximize the capability within the organisation to minimize the cost and time to converge its Enterprise Information Systems; to be as well organized and efficient as possible. These concepts save time and money, making the enterprise more Agile, etc. Bla bla bla…..Spend thousands… save millions…”Yeah right”, they say, “we’ve heard it all before!”

These EA concepts and benefits are extremely difficult to describe in an easy to understand, meaningful manner, to business people. Particularly to do it so well that executives just want to rush out and spend on EA immediately once they have heard about the concepts. This is partly because over many years, so many promises have been made and broken, so many attempts have tried and failed, all in the name of “Enterprise Architecture”, that the term itself now has become stigmatized. Architects who understand the concepts tend not to have the patience either, trying to convert or translate many of these architectural principles into money and benefits-realization terms. I have certainly tried to avoid this documentation and explanation process wherever possible, but in order to justify the existence and get any funding you really need to roll up your sleeves and be prepared to do the difficult sell.

So recently when I saw the best distillation of the whole concept into something that is simple to understand and makes the most sense to me, and I would suggest, to any executive of any size enterprise, I thought it deserved to be aired.. It is the concept called the Debt Metaphor summed up in EA terms as “Enterprise Technical Debt“. It’s brilliant because it translates the Architectural issues directly into money terms that the Business people understand.

I first saw this in Pragmatic EA [1] and it makes perfect sense to me. Also from Ward Cunningham describing it in Software terms (not EA terms but very similar) [2]. The concept of Debt Metaphor was first described by Ward Cunningham and there is a You Tube video by the man himself describing what he means below.

I am however taking this concept and broadening the scope of it to suit the broader Enterprise Architecture rather than the Software Solution Architecture of one software program in an enterprise:

Martin Fowler [3] also explains it in simple terms. This paragraph below is taken directly from a blog by him and has been modified by me to suit Enterprise Architecture:

“You have a piece of functionality that you need to add to your enterprise. You see two ways to do it, one is quick to do but is messy – you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. Technical Debt is a wonderful metaphor developed by Ward Cunningham, (modified by PragmaticEA)[2] to “Enterprise technical Debt” to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a Enterprise technical debt, which is similar to a financial debt. Like a financial debt, the Enterprise technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development projects because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design.

Although it costs to pay down the principal, we gain by reduced interest payments in the future. The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity Architects may incur “Enterprise” technical debt to hit an important deadline. The all too common problem is that IS/IT organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.”

To me – if we can achieve explaining this to the executives of any Enterprise, we would be well on our way to getting their buy-in to funding a business as usual Enterprise Architecture practice. We could prove it works by measuring the money metrics in each case of how Enterprise Technical Debt (albeit rather subjective) are saved and lost and track the ongoing accumulation of interest on that Enterprise Technical Debt.

References

[1] Ward Cunningham – Debt metaphor https://youtu.be/pqeJFYwnkjE
[2] Pragmatic EA – http://www.pragmaticea.com/docs/peaf-governance-process.pdf (see page 6) and http://www.pragmaticea.com/docs/peaf-comms-ea-3enterprise-debt.pdf
[3] Martin Fowler – Technical Debt http://www.martinfowler.com/bliki/TechnicalDebt.html
[4] Wikipedia on technical Debt: http://en.wikipedia.org/wiki/Technical_debt

[5] http://enterprisearchitect.typepad.com/ea/2008/12/measuring-technical-debt.html

Technical Debt

Is lack of EA partly to blame for the…

  • 2009-03-012018-05-03
  • by Charles

Abstract

I have predicted for some time (although not brave enough to do so publicly[**]) that the manner in which the finance and other industries conduct their business operational processes, both Architecturally at all levels and from a Software Development perspective, would cause spectacular business failure in some form or another at some point. As it turns out that amongst other things it was a lack of understanding and communication about the Business Architecture and Business Models that have appeared to cause this failure.

This paper explores some of the potential causes, and why people don’t speak up too loudly… (and can’t be too explicit). Obviously it has become easier now that we have the evidence and proof, but will anyone listen and more importantly act on improving their Enterprise Architecture – specifically the Business Architecture?

Download

Access the PDF here: Lack Of EA – Financial Industry Collapse V0.01

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.