(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:
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 http://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.
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.
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.
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
My apologies. I've updated the post and added an addendum.
Looks like you and I are also in agreement. Thanks for sharing the link to your blog.