During every G8 summit we see television images of protestors, held too far from the conference centre to properly feed the hunger of their protest, instead swarming disconsolately against a force whose ills they perceive but can neither influence nor prevent. Inside the conference, the G8 leaders are doing much the same, also unable, really, to influence or to prevent.

Whatever your view on the morality of economic globalisation, there’s no questioning the impact on everyone’s lives of the increasingly strong linkage between the world’s economies; or that while globalisation amplifies our collective ability to produce efficiently, it also increases the severity of economic variances.

A recent example is the failure of Northern Rock - the result of over-exposure to defaulting sub-prime mortgages in the US and the subsequent global tightening of inter-bank lending.

It’s useful to remember the good and bad of economic globalisation when considering the application environment within most large banks. It’s typical of these organisations to run up to 800 different applications, each with its own criticality, value at risk and performance characteristics. These applications can loosely be equated to the economies of different countries.

Most application system architectures in this domain have evolved in ways akin to the global economy. Over time, core functions have been “outsourced” to specialised application or data services. With the obvious benefits of reliability and cost-effectiveness to be had, this has occurred to an ever greater extent, so that now it’s not just the obvious data services like customer account information that have been outsourced, but also application component functionality such as document image rendering, workflow management and identity management.

I call the result Application Globalisation and like economic globalisation, it can be very difficult to control or predict the estate-wide impact of variances in application performance and availability across this web of interdependence.

For example, a slowdown in a security authorisation component can affect applications that don’t use it because of their reliance on applications that do. Does anyone in your organisation really understand these relationships or how to spot when a global impact – as distinct from a local application issue – is operating?

Application globalisation is one of the reasons that proactive availability management and outage recovery are so difficult.

In the search for help, it’s useful to turn once again to our economic analogy. Our understanding of globalisation has increased markedly in the last 10-20 years through the development of sufficiently descriptive models, the computational power to run them and the increased standardisation of economic data to drive them. Sounds a bit like IT Analytics, and it is. But in the application economy, the state of awareness and maturity of application globalisation lags far behind its economic analog.

Recently, we’ve been helping clients address this by an exactly analogous approach to that of our economist counterparts – by applying IT Analytics beyond the application, into the wider application economy. Already we’re enabling a far higher level of insight into the real drivers of application performance and behaviour, and helping our clients to improve both.

We hope that, through this initiative, the protesters at their gates might disperse too.

“Do not go gentle into that good night
Old age should burn and rage at close of day
Rage, rage against the dying of the light”

Dylan Thomas wrote these words as he contemplated his father’s last days and hours, urging him to fight for just a little more life, even as death came ever nearer. The poem from which these lines come is partly a celebration of the tenacity of the human spirit, continuing to rage and strive for life, even at its end.

I wonder what he would have made of today’s n-tier application availability. Our critical applications, upon which our businesses absolutely depend. Why do they fail so readily? Why are they so fragile? Why don’t they grasp life more firmly?

The human organism has evolved over millions of years to withstand, and adapt to, sustained environmental bombardment, both physical and emotional. The n-tier application has, of course, not been granted this period of maturation. But we have made matters worse by disrupting its short evolution and, as a result, we’ve unintentionally birthed ever more elaborate, sensitive and refined creatures that effectively have no immune system, and no heart for the fight.

In the world of compromise in which we must operate, we have, wittingly or not, emphasised features over architectural robustness, scale over resiliency, flexibility over availability. In evolutionary terms, we’ve broken the control feedback between life experience and adaptation through federated IT models that put the teams that run applications far from the people that write them. We’ve used the data that tells us how these applications behave to inform us of their recent death, not to give us insight into how to engineer them to live.

We continuously monitor application infrastructures much as the prison officer continuously observes the prisoner on suicide watch. But in both cases the results are often discouraging.

Until we engineer our applications to fight for life, to rage against failure, we’ll continue to be disappointed by their performance and availability. But today, most development teams are ambivalent about the longevity of their applications, and don’t really embrace resiliency and recovery design at all.

Here’s an example. Most critical financial services applications are deployed with some kind of “fault-tolerant” parallel infrastructure. So how come they’re almost never tolerant to faults? It’s because the designers and developers knew they had to tick a box for fault tolerance, so they specified a standby infrastructure, but they didn’t sweat out the details of how applications really fail or degrade or how operations teams have to react to these situations.

In real life, operations teams don’t switch over an entire 50-server infrastructure to a fallback site just because something somewhere in the primary infrastructure is running slowly. It’s too scary a proposition, and, until they know the cause of the slowdown, who’s to say that the same problem won’t recur within the fallback infrastructure too?

So instead, while they attempt to puzzle out the reason for slowdown, the application limps or falls, the fault tolerant infrastructure remaining idle.

If we want applications to be genuinely resilient, we need to engineer them at a finer granularity than this, to have paranoia enough for effective self-monitoring, to have intelligence and resources enough to divert themselves from failure as soon as it is starts to emerge.

The reason that this rarely gets done is because we regard that task as a theoretical computing science problem, almost in the realms of artificial intelligence. This makes it seem too difficult. We should instead treat it as a practical engineering challenge, which exploits the mass of data on past failures and implements practical mitigations to automatically deal with them in the later applications that we build.

IT Analytics provides an essential guide here, in converting raw data about past degradations and failures into information and insight about how those failures developed within the distributed application.

We should provide this information to our development teams and task them with building practical recovery scenarios for the common failures and degradations of the past. What failed in previous incarnations will fail again in later versions, or in new applications, in much the same way as it did before. In the meantime, for those prior applications, can we only will them to stay alive for just a little longer?

And you my father, there on the sad height
Do not go gentle into that good night
Rage, rage against the dying of the light

If there's one good thing that might arise from the current recession, it's that we're all becoming a bit more thoughtful in what we're consuming and what we actually need.

For IT departments, the struggle to reduce costs is often focussed first on the datacentre - with consolidation and virtualisation initiatives taking precedence.

However, one area that's commonly overlooked are the applications themselves. Legacy apps that aren't delivering value and that hardly anyone is using are an uneccessary drain on the budget. It's the last thing cash-strapped businesses need right now.

So what can be done about it? Well, for a start, it's one area that IT should be talking to the business about right now. Not as a one-off exercise, but as an ongoing dialogue. Business leaders want to know how IT can make the business more profitable, efficient, how it's bringing value now - and, importantly, how it can deliver even more. Trouble is, IT departments are not known for being particularly forthcoming with this type of information.

One area that can kick-off a fruitful discussion between IT and the business is a review of existing apps and what they're bringing to business' everyday operations.

At Sumerian, we've pioneered ways into helping both IT teams and the business leaders understand what applications are actually being consumed - by who, where and how. It provides a first stake in the ground to getting IT and the business talking - and it's a great way of proving ongoing value. If you're interested, take a look at this new case study that demonstrates how well it can work.

Posted by Fran Bolton, Technical Author