In my previous blog on Technical Debt, I explained the concept of technical debt using software architecture as an example, and described the saw-tooth pattern of well-run businesses that consciously accrue technical debt for a period before investing time in paying off the worst of it.

The technical debt metaphor also describes the challenges of businesses maturing from the inception stage to one can make a good business case for ERP and beyond.

Technical debt is a term coined by Ward Cunningham in 1992 to describe the software engineering phenomena of how expedient, short-term decisions can have negative, long term consequences that make it difficult to maintain and update the software. The concept does not just apply to technology companies, any company that uses technology also has technical debt and understanding the concept will help you manage it and run your business.

Ever noticed how quickly things come around again? No sooner than you've accomplished something, there it is again warranting your attention. 

Twelve months ago this month I completed my first charity Etape du Tour after months of preparation and planning. And now, I find myself having done my second, successfully summiting the infamous cycling climbs of the Col du Tourmalet and Hautacam on 20th July -however, this time around it was a very different story indeed! 

A few weeks ago my ageing TV packed up and it was a sad moment when I threw my trusty appliance of many years onto the tip. I am now the proud owner of a flat screen, HD, Internet connected, "you name it my TV has got it" TV and wondering why I didn't upgrade it a long time ago.

In 2010 there was a debate between some of the major enterprise software influencers and bloggers on whether single or multi-tenancy was an issue for Software-as-a-Service (SaaS) applications. On the one side was Josh Greenbaum who argued that the type of tenancy should not matter to SaaS users; on the other was Phil Wainewright (here and here) and Dennis Howlett whose views were that multi-tenancy is the only way for SaaS software. This debate is still going on.

Single-tenancy refers to a software configuration (application and database) in which each client has its own underlying application resources. Multi-tenancy is where all clients share the same underlying resources. Multi-tenancy also means that all customers get the same application upgrades and enhancements at the same time, whether they want them or not.

Imagine living in a world where we humans don’t age gradually: we do so in one leap every birthday. After being fed at your mother’s breast for a year, your first birthday brings a rapid doubling in size, the ability to move around on four (perhaps even two) legs, babbling a few words, wide open eyes that see everything clearly … all in a flash. The second birthday sees you suddenly walking and running unaided and making conversation. And so the process goes until a ripe old age. An ideal situation? I don’t think so.