EA Debt

(Note: I've added an addendum to this post)

It has been many years that we have lived with the concept of technical debt.  Martin Fowler did a good job of describing the concept in a 2003 article on his wiki.  Basically, the idea is that you can make a quick-and-dirty change to software.  You will have to spend time to fix that software later.  That additional time is like an interest payment on debt that you incur when you made the change.  Fixing the code to make it more elegant and clean “pays down the debt” so that future changes cost less to make.

I’d like my fellow practitioners to consider joining me in extending this idea to the enterprise.

Organizations change, and sometimes the changes have to be made quickly.  Processes that are implemented “quick and dirty” may have poorly defined roles, overlapping responsibilities, and duplicate accountabilities.  It may work, and it may be necessary to hit a deadline.  However, these “dirty” processes have the same problem that dirty code does – it costs more later to fix them. 

In a sense, partial process or accountability “fixes” in an organization create “enterprise architecture debt” or “EA debt.”  We run into it all the time in organizations.  Here are some examples that I’ve personally seen:

• One team is responsible for checking the quality of all manufactured products and making sure that they get to distributors.  However, products that are custom developed have their own quality check and distribution function.  Effectively, two different teams duplicate a couple of functions.  This could be simplified, and doing so would likely reduce costs and improve consistency in quality checks. 
   
• The marketing team uses data mining techniques to identify potential customers (prospects) and enters them into a system along with attributes like segment, predicted value, and targeting within specific marketing programs.  When a new customer reaches out to actually purchase a product, however, the customer record is created in a CRM system that is not linked to the marketing record.  Consistently linked customer information could provide valuable information about the effectiveness of marketing programs as well as enriching customer information for the sale of service and ongoing sales.
    
• An outpatient specialty radiology department in a Hospital requires patients to be registered separately from other hospital services in order for patients to be handled.  For most patients, this is not a problem.  However, for patients within the hospital, the separate registration requirement creates opportunities for errors as information is hand-transcribed from one system to another.
   
• A retailer sets up an e-commerce division to sell their wares online.  However, inventory and warehousing the new e-commerce site is not integrated into existing store systems.  The ecommerce “store” is treated as another physical store.  This works, but any attempt to allow customers to purchase online and pick up at a store become problematic because the retailer has no way to handle purchases made in one store to be fulfilled by another.
   

These, and a thousand more situations, are the result of “partial” or “messy” implementation of organizational changes.  They are a form of “EA debt” because any change to the organization that hits these capabilities will be more expensive to change in the future as complexity slows down the organization.  In effect, EA debt is like taking a Lego set and gluing the pieces together.  The parts will remain just as they are, but the will be very difficult to change in the future if something needs to change.  (Apologies to “The Lego Movie” for the metaphor).

Why call this “EA debt?”  Because it is not a financial term.  It is nearly impossible to accurately measure all of the EA debt in an organization.  It is, however, fairly straight forward to measure monetary debt.  So we have to be careful not to use terms like “enterprise debt” or “organizational debt” as these may be confused with general accounting concepts.  Just as technology teams sometimes twist the concept of an “asset” to apply to an information system, Enterprise architects are using the metaphor of debt to refer to one of the root causes of difficulty in making organizational change.

---

Addendum: I guess I shouldn't be surprised that this idea is not novel.  It's fairly self-evident.  It was my mistake that I didn't go looking for other references to the idea before writing the above post.  Laziness.  No excuse.  While the concept of technical debt does in fact trace back to Ward Cunningham (inventor of the Wiki), as discussed by Martin Fowler in the referenced blog post, the application of that concept was first applied to EA in 2008 in the Pragmatic EA Framework, and is part of the current version as well.  I'd give a link to that presentation if I could but the best I'm able to do at this time is a general link to PEAF at https://www.pragmaticea.com.  Kevin directly responded below with links into his material .  It is no disgrace to be in the shadow of Kevin Smith (author of PEAF).  It is an error, however, to appear to originate the idea.  For that, my apologies.

Comments

• Anonymous
  June 24, 2014
  The source of Technical Debt is not Martin Fowler. Enterprise Debt™ was defined and published in PEAF in 2008 and basically forms the bedrock of the Governance & Lobbying Discipline it defines. It has been updated and will be published in 2 (of 3) books in the coming 2 months. You can read about it in POET starting at page 76 (physical page 88) here issuu.com/.../poet_-book You can read about it in PEAF starting at page 74 (physical Page  88) here  issuu.com/.../peaf-book-_compressed The information for its capture (Waiver) is defined in the Artefacts section starting at page 100 (physical page 114) You can also read it online in POET staring at www.pragmaticea.com/poet-models.asp and in PEAF starting at www.pragmaticea.com/peaf-models.asp. The fact that you talk about this and do not even reference my work is astonishing.

• Anonymous
  June 24, 2014
  Hi Nick, The concept of 'Enterprise Debt' (over and above Technical Debt) is all already very comprehensively covered in PragmaticEA's PEAF.  And Accordingly supported in Avolution's ABACUS. Cheers, Tim

• Anonymous
  June 25, 2014
  Agree. See also this post.: The Enterprise Architect is responsible for the technical and "business" debts at it.toolbox.com/.../the-enterprise-architect-is-responsible-for-the-technical-and-business-debts-60997

• Anonymous
  June 26, 2014
  Kevin, My apologies.  I've updated the post and added an addendum. Adrian, Looks like you and I are also in agreement.  Thanks for sharing the link to your blog.