Before we start it’s probably worth defining what is meant by evergreening. There are several reasons for this. One, it’s a term that is not particularly widely used, two, it’s a term stolen from the legal profession and, three, it’s a bit of a misnomer.

An Evergreen Definition?

In legal circles the term evergreen concerns the automatic renewal of a contract clause. Evergreening can also refer to the taking out of new patents to extend intellectual property rights. The latter is perhaps the better analogy here in that it involves effort and investment. More of this later.

For the avoidance of doubt (nice legal term), evergreening in this article refers to the non-functional upgrade of IT systems.

Non-functional upgrades can include, but may not be limited to, the following:

• Upgrades of technology versions to provide or prolong vendor support, including the renewal or extension of licensing arrangements;
• Providing appropriate levels of resilience and disaster recovery;
• Migration to strategic technology platforms in order to realise the benefits of rationalisation;
• Performance and/or capacity improvements to accommodate future growth;
• Achieving sustainable cost savings, for example through the use of virtual environments rather than dedicated hardware;
• Refactoring of application code to improve maintainability with respect to both troubleshooting and functional improvements.

Note I have listed these in what I feel is a descending order of importance. The order shown is however debatable and may vary from organisation to organisation.

Finally, we have the misnomer highlighted by our friends the botanists. As they would have it the term evergreen refers to foliage that persists and remains green throughout the year. Unfortunately for those working in the field (no pun intended) of information technology, evergreening is a little more involved than planting a Canadian Spruce, Picea Glauca, in the corner of the garden and throwing a bucket of water over it when the mood takes you. Indeed, as soon as you’ve expended the time and effort to evergreen your estate, it starts dying in front of your crying eyes. Those managing the extensive estates of larger organisations will find evergreening not unlike the painting of the Forth Bridge.

So, evergreening may not be best term, however until something better comes along it serves a purpose. Answers on a postcard or a sealed down envelope if you can think of a better name.

The Cost of Evergreening

When it comes to evergreening it can be very difficult to write a business case for the associated investment. Unlike change activity, where you are investing to make something happen, such as the generation of some business, with evergreening you are ensuring that something doesn’t happen, i.e. a technology failure. With evergreening you are seen as spending rather than investing and it’s very difficult to claim tangible benefits. The costs are all too real in the event of a failure, however given this is the very thing you are trying to avoid, then this is perhaps not a metric you’d rather collect.

Given that evergreening is perpetual in nature, and will likely not have a natural end point, it makes sense to allocate a specific budget for evergreening activities. The pitfall here is to assume that not spending the budget means you haven’t met your evergreening targets. At the end of the day, and indeed the beginning, the budget is the sum of the estimated costs of the work you intend to do. At least it should be. As with all things cost savings can be made. The focus should therefore be on the completing the work you set out to do, and not on spending the budget. Okay, there is always the option of undertaking more evergreening than you originally intended, however this may put you into the realms of diminishing returns.

It may actually be possible for evergreening to be undertaken at a discount. Savings can be achieved by rolling evergreening work in to change activities occurring around the same time. The resulting rationalisation should serve to reduce costs. You may also find that those more accustomed to estimating for change activity over egg their estimates for evergreening work. As the level of uncertainty for evergreening work is a generally less than in bespoke build, allowances for estimating tolerance and contingency should not need to be as high.

For these reasons evergreening work is more likely to come in under budget than over. Maybe.

The Value of Evergreening

If we work on the assumption that the value of the work you have completed is more prevalent than the cost you have expended undertaking it, then there is a project management technique that may be useful. Let’s recap. We have cost, value, and although we’ve not mentioned thus far, it’s always helpful to have a plan. A point to all those who said earned value management.

Earned value management is useful in that it encourages a focus on the value you have achieved, rather than the costs you have incurred. It serves to highlight instances where, although you may not be spending the entire budget, you are still competing the work you intended to at the outset / beginning of the financial period.

Earned Value Management

The graph above shows a positive cost variance. The actual cost (in red) is trending below the earned value (green) so all is good as we are under budget. Well, all would be good if it were not for the negative schedule variance demonstrated by the earned value (green) sitting below the planned value (blue). Therefore, in this scenario the project manager needs find ways speed things up a little up in order to bring the delivery of earned value more in line with the plan, ideally without doing too much damage to the cost variance.

Note, bringing a project in under budget is always a good thing, even in the case of evergreening. Trust me on this one.

A Metric For Evergreening

Oy, you at the back! Wake up! This is the interesting bit. Interesting, if only because it’s completely made up.

As mentioned previously, evergreening doesn’t have an obvious business benefit. It is more about preventing loss. This loss can include financial loss, perhaps resulting from the business you lose if your IT systems go down, and non-financial loss, such as reduction in customer satisfaction and brand damage. Ironically the latter may well have more of a hit on your bottom line than your former.

So what if we could quantify the value of your evergreening activities? Not in terms of the estimated cost of a work package, but rather the value they embed.

Earlier I listed the types of activities I saw falling under the evergreening banner. This included a suggested order of priority. What if we could quantify the benefit of undertaking these activities?

In software development functional points provide a unit of measure to determine, or rather estimate, how much business functionality is being delivered. Function point analysis (FPA) uses what it terms “functions” to calculate the amount of software being delivered. Think of it as a way to determine how many square feet of software development you have ahead of you. I’m not going to go into the detail here, suffice to say functional points are essentially interactions, of either a user or through asystem interface. It’s something like that anyway. Google it if you’re interested.

What if there was a similar metric to express a square foot of evergreening? Until a better name springs to mind lets call this a green point.

Green points

So what is a green point? Given that we have vendor support at the top of our list lets start with this and make a green point which, in its simplest form, is a supported transaction. Consequently, if you are extending the support life of a system by 12 months, and the system supports 100,000 transactions a month, then you have 1.2m green points. Note a transaction can be a user interaction, a system update in a batch file or any other unit of work processed by the system. A little like FPA then but with the focus on the number of transactions processed rather than the types of transactions the system supports.

We also need to consider the number of technologies that are being evergreened. If you are evergreening both web servers and a database you will be undertaking more work and embedding more value than if your upgrade concerns only a single technology. Given the various coefficients and factors discussed later, you may wish to look at each technology separately. That said, the additional complexity of upgrading several technologies concurrently means the calculation of green points per technology doesn’t add much in the way of improved accuracy. Green points are not an exact science. How could they be? I’ve only just made them up.

Supported Transactions (The Base Unit for Green Points)

Example

Supported transactions, sn = nt st ar

Where:
Number of technologies, nt = 1
Support extension, st = 12 months
Transactions rate, ar = 100,000 transactions per month
Supported transactions, sn = 1 x 12 x 100,000 = 1,200,000

Tiering Coefficient, CT

Ideally all transactions would be equal, however, it's more usual that some services are more critical than others. The tiering coefficient accommodates this by scaling the number of green points to reflect the importance of the service.

The following values for the tiering coefficients are suggested; however organisations may wish to vary these to accentuate importance of a particular service tier:

Tier 0 = 1
Tier 1 = 0.8
Tier 2 = 0.5
Tier 3 = 0.2

Green Points (Scaled by Tier)

Refactoring Coefficient, CR

The refactoring coefficient also recognises that tidy, maintainable application code is relevant to the number of transactions running through it. It seems reasonably safe to assume that there is more value in refactoring code that gets some hammer, rather than that which is hardly ever used. The amount of refactoring required is also worthy of consideration. This coefficient therefore varies depending on the amount of refactoring effort required and, as with the tiering coefficient described previously, scales the green point count.

As a starting point the following values are suggested:

None = 1.0
Very minor = 1.05
Minor = 1.1
Major = 1.2
Very major = 1.4

Strategy Coefficient, CS

Finally, for these type of coefficients at least, we have accordance with the strategic architecture. It can be argued differently, and there is a case for levels of compliance, however for the sake of simplicity this is seen as binary. It either complies or it doesn’t:

System uses strategic architecture = 1.0
System will move to strategic architecture = 1.2

Capacity Reduction Factor, rc

There is little point in extending vendor support much past the point where the system will run out of capacity. The capacity reduction factor allows for this reducing the period over which green points can be collected. In essence you can’t bank green point past the point where you expect to start experiencing capacity issues. Harsh but fair.

Outage Reduction Factor, ro

An outage will reduce the number of transactions processed by the system. It therefore seems reasonable to remove the green points resulting from lost transactions from the total. The problem here is that, although an outage is a serious event, a pro-rata reduction of green points based on the length of the outage will not result in a significant reduction. A five-hour outage once a year on a system that runs twenty-four seven is such a small fraction of a percent that it’s hardly worth mentioning. Read on...

Outage Coefficient, Co

Finally, we have another coefficient. Well you just can’t have enough of them can you? The outage coefficient recognises the criticality of a loss of service by scaling up the outage reduction factor. An outage coefficient of 100, as suggested below, scales up a five-hour outage such that reduction in the total green points is equivalent to that of a 500 hour, or three week loss of service:

Resilience / disaster recovery within agreed limits = 1
Resilience / disaster recovery outside agreed limits = 100

Green Points (Reduced by Capacity and Outage)

Green Point Calculation

So there we have it. The calculation of green points looks something like this:

Number of green points = nt CT CR CS ar ( st - rc - Co ro)

Worked example

And now a worked example. Everybody likes a worked example:

Number of technologies, nt = 1 (Web servers only)
Tiering Coefficient, CT = 0.8 (Tier 1 service)
Refactoring Coefficient, CR = 1.0 (No refactoring to be undertaken)
Strategy Coefficient, CS = 1.0 (Service is on strategic architecture)
Transactions rate, ar = 100,000 transactions per month
Support extension, st = 15 months
Capacity Reduction Factor, rc = 3 months (Capacity issues expected 3 months before support agreement ends)
Outage Coefficient, Co = 1.0 (Resilience / disaster recovery within agreed limits)
Outage Reduction Factor, ro = 0.0 (No outage expected)

Number of green points = nt CT CR CS ar ( st - rc - Co ro)

Number of green points = 1 x 0.8 x 1.0 x 1.0 x 100,000 (15 - 3 - (1.0 x 0.0)) = 960,000

What’s The Point?

So what do green points give you that earned value doesn’t? Perhaps the most relevant thing is that green points uncouple the value you are actually embedding in the estate from the cost of the work you will undertake.

It is fully expected that the coefficients suggested above will be tinkered with and will differ from one organisation to another. Some may even be negated if they are seen as the minimum standard. For example, if all your systems are super resilient and never fall over then the outage coefficient would be frozen at 1.0.   Mmmm.

Once you have settled on the coefficients you wish to use you have relative scoring mechanism which can be used to prioritise. Consider a scenario where there are two projects both estimated at around £500,000. If the calculation shown earlier demonstrates one project delivering 200,000 more green points than the other, then you may well decide to tackle this one first.

Green points can also be used to monitor the effectiveness of your evergreening activities, and identify any incremental improvements you are managing to make. If you know how many green points a project is delivering, and the cost of this work, then it’s a simple calculation to determine the cost of a single green point. If you track this from project to project and the cost reduces, then it would appear you are improving. Conversely, it may also serve to highlight where a point of diminishing returns has been reached and evergreening is not achieving the benefits it once did. There’s no point in gilding the lily, even in evergreening.

Finally, we have estimating. Once you have an idea of how much a green point is costing to deliver then you have a metric for estimating which can be applied early in the development cycle.

Feedback welcomed and appreciated.