Re-purposing the Technical Debt Metaphor

Recently, I had cause to re-visit the ‘Technical Debt’ metaphor coined by Ward  Cunningham when referring to agile software development:
I am finding, however, it applies to a much broader set of circumstances such as: unmanaged introduction of Consumer-grade I.T., Line-of-Business ‘Credit -Card-Cloud’ consumption and ‘technology-solution-without-a-requirement-and/or-architecture’ implementations. So I’ve had a go a rewriting Ward’s original words:-

“Technical debt is a metaphor an incremental, get-something-started approach with the easy acquisition of money through fast loans.



A monetary loan, of course, has to be paid back with interest. In terms of software development & technology selection &  deployment, payback requires the technicians to re-work the solution as they learn more about how it interacts with other technologies and which features are being used, or not, or are now needed. Just as monetary debt can easily spiral out of control if not managed properly, so can technical debt.



In business, the metaphor is often used to illustrate the concept that an organization will end up spending more in the future by not having sufficient understanding the complete requirements before selecting a solution. The assumption is that if an organization chooses to ignore a course of action it knows should be taken, the organization will risk paying for it in terms of time, money or damage to the organization’s reputation in the future. As time goes by, efforts to go back and address the missing requirements may become more complicated and, otherwise, messy. Eventually the problem may reach a tipping point and the organization must then decide whether or not to honour its original debt and continue investing time and effort to fix the problem. This decision can be made more difficult by something called ‘the sunk cost effect’, which is the emotional tendency of humans to want to continue investing in something that clearly isn’t working (e.g. can’t scale or missing features)”.


Anything you’d add/change/delete?

The Limits of Gamification in the Workplace

In the Wall Street Journal article, “The ‘Gamification’ of the Office Approaches”, Farhad Manjoo is justifiably concerned about the growing trend for managers to try to turn work into a game by simply adding points, badges and leaderboards. Manjoo observes, “Getting people to do things they don’t really want to do turns out to be […]

The post The Limits of Gamification in the Workplace appeared first on Brian Burke.

Taking the right path

In 2013 we saw the rise, and in some cases the rebirth of analytics and were told of the importance of using data to get closer to our customers. The growth of social media and the birth of the omni channel has meant that understanding your channels and the related data is going to be Read More

Fail Fast and Fail Often

Fail fast and fail often is one of my main mantras which I use at least once a day if not more often both towards the people I coach as well as towards me. And I must confess, I failed again. But this time I was stupid enough to not see the signals. In my last post which is quite a while ago I announced that I start something new. And I failed badly for various reasons. It was once again a dialogue with Tom Graves via his blog which made it obvious to me. If you are interested read his interesting post about Starting Friction including all the comments. To be fair I actually already knew it without knowing, but the dialogue helped me to get it on the surface.

I really tried, but it blocked me. It blocked me in a way which made me stop blogging, which made me stop sharing public, which also made me comment less on other sides. The thinking process itself, how to structure, how to write made me fail. Fail badly. Now, during the dialogue with Tom I retweeted a tweet from Bert van Lemoen to Tom:

@transarchitect: If you want to do something, you’ll find a way; if you don’t, you’ll find an excuse.” Very much true @tetradian
— Kai Schlüter (@ChBrain) December 26, 2013

This was not at all meant negative, but perceived that way: 

@ChBrain hmm… feels just a leeeetle bit too much like a put-down – which definitely doesn’t help right now, thank you… 🙁 🙁
— Tom Graves (@tetradian) 26. Dezember 2013

I am sorry for that Tom, but it did enlighten me. Obviously the books are not (yet?) ready for me to start with. There is a lot more urgent and interesting things to do. Therefore I decided to move on and hopefully also find the energy again to share every now and then. Because writing my posts in the past never took long, but all of the sudden I started to think about writing and by that lost all movement. I do not know where this leads me to, but I know for sure that the idea of writing a book is for the moment history. It does not seem to be my medium to transport the message. Furthermore, when I look at my own reading it is quite obvious. Books about Enterprise Architecture never inspired me, Stories do the trick for me, fiction about people, emotions and such topics no matter what media (e.g. books, movies). Good stories make me think different and then I adapt and abstract it towards Enterprise Architecture and create just another (sometimes working) tool.

So, message of the day: Back to my strength.

You Cannot Move Too Fast

This is the time of year when I seem to notice the speed at which other drivers on the road are traveling, and when I say "speed" what I mean is the plodding, lethargic, and dawdling forward movement of my roadway cohabitants. What is it that causes drivers to suddenly assume that speed limits are upper-end suggestions, and not the result of engineering to balance safety and throughput?

I’m

Stealth Enterprise Architecture!

This year I’m predicting more stealth enterprise architecture! I’d like to say that I invented this phrase, but I’ve found at least two previous uses: one in a comment by Peter Parslow in 2010; the other from Alec Blair, the head of Enterprise Architecture for Alberta Health Services, who described the journey of how his Read more

The Inversion of Big Data

Big Data is the Big Thing at the moment. It won’t be ten years from now. And not because we tackled the technical aspects of handling it, or created huge business intelligence systems capable of harvesting the treasures hidden in it. Or because it has become generally accepted and arrived at Gartner’s plateau of productivity. […]

Systems Failure at RBS – Again

Subhead: Modernization is NOT Optional!

Once again customers of The Royal Bank of Scotland (RBS) and its subsidiaries Ulster, Natwest etc are in trouble! Unable to use their debit cards, or access their funds! And the new Chief Executive Ross McEwan admitted today that RBS has failed to invest properly in its systems for decades! RBS has given no explanation of the crash, except that it was not related to the high volumes of transactions on Cyber Monday.

Actually the root problem for RBS, and many other banks and other very large organizations, is NOT that they haven’t invested in their systems for decades. The problem is that they have allowed the systems to evolve without good architecture and governance. Banking systems in particular used to be leading edge. But over the years the core systems that actually run the bank, have become badly out of date. Instead of modernizing the core systems, many banks have responded to demand for new products and services by surrounding the old legacy systems with new bolt on systems. As a result the old systems are held together with sticky tape and sealing wax, and modified piecemeal to adjust to new requirements, and the new systems create more and more interfaces and dependencies (including duplicated, hard coded business rules), so that eventually the systems resemble a hair ball. And as you know, a hairball is a tightly packed cylinder of fur, which also includes all manner of foreign particles, which can be quite hazardous in humans and animals. In systems terms we would more usually refer to the resulting mess as a monolithic systems portfolio.

The root problem therefore is twofold:
1. The increasing complexity and risk inherent in making change.
2. Increasing horizon of any change.

And the issues become apparent either when extremely complex operational processes execute incorrectly, or when changes in process, software or environment  are made, often unavoidably without full knowledge of all the implications due to lack of experience, documentation or even code!

Although I have no doubt that in all the large banks there are fierce debates about the IT budget, strangely the solution to this problem isn’t about the amount of money that needs to be spent. Rather it’s about how the organization embraces a real modernization program, which is led by good architecture and managed with strong governance.

Sadly in the IT industry the term modernization has come to mean something quite specific – the re-platforming or technology upgrade of some application. Whereas modernization should really encompass a much broader remit including:
1. Establishing a lingua franca between business and IT so that modernization issues and implications are genuinely understood by both business and IT management.
2. Defining a business systems architecture that a) facilitates transformation with low risk and b) progressively develops an inherently agile architecture, that can evolve continuously.
3. A roadmap for progressively rationalizing the business systems portfolio to comply with the architecture.
4. Implementing an integrated business and IT organization that owns the business systems.
5. Implementing knowledge management around business systems that ensures integrity and consistency and ownership of processes, information and rules.
6. Implementing a continuous Agile modernization and ongoing evolution process in both business and IT.
7. Establishing coordination, governance and risk management that ensures architectural integrity at all stages of the life cycle.

It would be easy for business management to think that the sort of problems experienced by RBS and other banks as IT problems. The above list suggests this is nonsense. The only way to properly resolve the issues is for business management to accept co-responsibility for IT. And it’s no accident that the first point in the list above is to ensure that business management understand the issues they are dealing with, and can communicate effectively with the IT organization. This isn’t just attending an education class; it’s embracing a common language that allows critical decisions to be taken on a properly balanced understanding of business and IT assumptions, costs and risks.

Retailers, manufacturers, power companies, logistics companies, government departments etc etc should not be complacent or smug when they see the problems at the banks. In fact almost all very large organizations have these problems. And the message for all enterprises is Modernization is not Optional!

Links:
RBS Crash – Management Prefer Offshoring to Modernization?
CBDI Journal Reports on Modernization

EA Worst Practice Alert – "I do not need to make any special effort to communicate my value, my work speaks for itself!"

Many enterprise architects are modest (otherwise a great quality!) and feel awkward when they have to toot their own horn, the “value horn”, if you will…Shouldn’t our work speak for itself? What value is there in being pompous and blowing our own hor…

Zachman

Zachman® One-Day Seminar

The Zachman one-day seminar is a full day of John Zachman talking about Enterprise Architecture and the Zachman Framework™. This day is part of our FEAF program. John spends time and develops the ideas around Enterprise Physics, the desperate need for Enteprise Architecture, the misconceptions around the Zachman Framework in addition to the EA ontology and how to implement it’s concepts.


JAZ teaching 2 
 Zachman® One-Day Seminar
View Syllabus

ZCEArchitecture-Seal72dpi

Zachman Certified™ – Enterprise Architecture Program

Zachman One-Day Seminar $299

Zachman One Day Seminar

The Zachman one-day seminar is a full day of John Zachman talking about Enterprise Architecture and the Zachman Framework™. This day is part of our regular DoDAF and FEAF programs. John spends time and develops the ideas around Enterprise Physics, the desperate need for Enteprise Architecture, the misconceptions around the Zachman Framework in addition to the EA ontology and how to implement it’s concepts.

JAZ teaching 2   Zachman® One-Day Seminar
View Syllabus

ZCEArchitecture-Seal72dpi

ZACHMAN CERTIFIED™ – ENTERPRISE ARCHITECTURE PROGRAM

Zachman One-Day Seminar $299