The Software Is In The Clouds!

Software as a service (SaaS) is one of the most significant trends of the early 21st Century. SaaS is a scenario in which a person or organization access a piece centrally-hosted software. You use the software as long as you want, you don’t need the infrastructure to host the software and you don’t have to worry about dealing with the code. The organization using SaaS solutions needs to configure the software, manage the data, code and integrate organization-specific solutions outside of the SaaS package and manage internal uses. Significant SaaS solutions rarely are “plug and play”. Even straightforward SaaS solutions, such as Slack, often need administration and support inside the organization. Large SaaS packages, such as Workday, need teams to support, configure and administer the implementation. Some organizations using SaaS solutions to meet their information technology needs find it difficult to leverage agile, however with an agile mindset and a flexible approach agile is extremely useful in a SaaS environment.  (more…)



Packages come in all shapes and sizes!


Buying a package to perform a major function in an organization is rarely as easy as buying and implementing an app on your smartphone.  Package implementations often include: (more…)



Fitting agile to fit the picture.


In 1516, a few weeks before the modern project management and agile, a Bavarian nobleman enacted the Reinheitsgebot (German Beer Purity Law).  The law defined the ingredients in beer. Water, hops, and barley were one true set of ingredients. There are those inside and outside the agile movement that want to set and enforce similar purity laws. For some, agile is Scrum, Extreme Programming, SAFe, or Kanban. The argument is that you need to pick one but never combine approaches to address your specific culture or scenario. Combining frameworks is a bridge too far. Requiring framework or technique purity is s false requirement is often used to suggest that agile concepts and techniques can’t be applied in certain situations. These are five scenarios are often used as examples where agile is difficult or daren’t go:

  1. Mainframe Development and Enhancements,
  2. Maintenance,
  3. Commercial Off The Shelf Packages (COTS),
  4. Software as a Service (SaaS), and
  5. Outsourced (Contract) Work.


A dark alley...

A dark alley…

If someone were to approach you on a dark and stormy night as you stood below an underpowered streetlight and ask if you wanted some “technical debt,” I am sure answer would be an emphatic NO. While there are reasons we would intentionally accept technical debt, any development or support team would be better off if they could avoid being shouldered with it.  One strategy to get rid of it is to transfer the ownership of technical debt onto someone else.  Buying packaged software can do this – COTS (commercial off the shelf software) or SAAS (software as a service) can be used as a strategy to avoid owning technical debt.

When an organization buys a supported package or purchases SAAS, they avoid developing specific software development experience (who wants to code an accounting package if you can buy it), shortening the time needed to move from needs-recognition to using the software and avoiding maintaining a staff to maintain the software. In short, the day-to-day management of technical debt becomes someone else’s problem . . . sort of.  One of the laws of software (or at least should be) is that all software includes accrued technical debt. Some portion of the cost initial and annual support or subscription cost of the software pays for the management and maintenance of the software technical debt.

Most software companies do not explicitly publish measures of technical debt in their software, therefore as a user of the software you are more or less blind to level of the technical debt in the package. Why does it matter?  The level of technical debt can still affect your organization even when you don’t “own” the debt. Technical debt in COTS or SAAS impacts the ease of installation, ease of interfacing with your legacy systems, support costs, the existence of latent defects, and maybe most importantly, function agility.  Function agility represents how quickly new features and functions can be rolled into the software.  The longer it takes to develop and integrate new features, the lower the function agility of a software package. The level of technical debt in a package or in SAAS can only be inferred by observing these areas of performance. Review performance in these areas when you are doing your due diligence, and remember that since technical debt tends to build up, performance generally gets worse before it gets better.  And of course, changing software packages is very similar to trying to switch horses while riding (only done by trained stuntmen in the movies, not in real life). So, try to get it right the first time.

A simple cost analysis for determining whether to shoulder the technical debt or to transfer it elsewhere would use the following criteria (assuming the original build/buy decision has been made).

Costs to internally own the technical debt:

  1. Support Staff Costs                            _____
  2. Support Staff Overhead                    _____
  3. Support Staff Tools                            _____
  4. Support Staff Training                      _____

A. Total Costs                                              _____

Costs of someone else owning the technical debt:

  1. Support Cost/Subscription Cost   _____
  2. Support Staff Costs                            _____
  3. Support Staff Overhead                    _____
  4. Support Staff Tools                            _____
  5. Support Staff Training                      _____

B. Total Costs                                                      _____

Net                   Cost        (A – B)                         _____

This is a relatively simple view of the support costs. You should note that there will more than likely be some residual support staff costs needed to interface the new package with legacy systems or just to act as a help desk to initially triage problems. Intangibles, some of which are affected by technical debt such as function agility, will need to be factored into the decision process.

Transferring the servicing and management of technical debt of software by buying packages or using SAAS can make sense.  In many cases COTS and SAAS can reduce amount organizations spend on support and maintenance, including technical debt.  A cost benefit analysis can easily be done to verify whether this is true.  What is less obvious is whether the software’s owner will manage the level of technical debt well. If technical debt is managed poorly, the ability of the package to keep pace with the necessary functionally may suffer. Caveat emptor: do your due diligence and look before you leap.