December 2009 Archives

Eric Ries has just published a post entitled Continuous deployment for mission-critical applications. In this post he takes a very clear stand on the suitability of continuous deployment to mission-critical applications, as follows:

 

"I want to directly challenge the belief that continuous deployment leads to lower quality software. I just don't believe it. Continuous deployment offers three significant advantages over large batch development systems. Some of these benefits are shared by agile systems which have continuous integration but large batch releases, but others are unique to continuous deployment.

1. Faster (and better) feedback... Engineers working in a continuous deployment environment are much more likely to get individually tailored feedback about their work.
2. More automation... Continuous deployment requires living the mantra: 'have every problem only once.'
3.  Monitoring of real-world metrics... There are huge classes of bugs that "work as designed" but cause catastrophic changes in customer behavior. My favorite: changing the checkout button in an e-commerce flow to appear white on a white background. No automated test is going to catch that, but it still will drive revenue to zero. Continuous deployment teams will get burned by that class of bug only once. 
4. Better handling of intermittent bugs... For example, consider a bug that happens only one-time-in-a-million uses. Traditional QA teams are never going to find a reproduction path for that bug. It will never show up in the lab. But for a product with millions of customers, it's happening (and being reported to customer service) multiple times a day! Continuous deployment teams are much better able to find and fix these bugs.
5. Smaller batches... Continuous deployment tends to drive the batch size of work down to an optimal level, whereas traditional deployment systems tend to drive it up."

I could not agree more - continuous deployment is very effective as a software quality improvement strategy. Whether you do BSM, ERP, transaction management or any other mission-critical application, thoughtful continuous deployment is an excellent way to go. The laws of software engineering apply to any kind of application you might be developing and deploying.

I believe, however, we might have a metrics problem on our hands. What often happens is that continuous deployment flies at the teeth of the 'Man in the Dock' theory. When a major disruption happens, we look for a single point of accountability instead of deciphering the complex pathways to the disruption. Such a theory in use, of course, leads to less frequent deployments which in the long run adversely affect software quality.

A major task for Agile Business Service Management is the development of metrics that take us away from 'The man in the Dock' mindset. These metrics need to satisfy two criteria:

1. Map software quality to customer value.
2. Help us realize that service disruptions are systemic. They are a matter of complicated pathways, not of the incompetence of one individual or another.

In Backing into the Future, Bernard Knox makes a fascinating observation:

"The early Greek imagination envisaged the past and the present as in front of us - we can see them. The future, invisible, is behind us... Paradoxical though it may sound to the modern ear, this image of our journey through time may be truer to reality than the medieval and modern feeling that we face the future as we make way forward into it."

How appropriate this mental model is in view of the recent and no so recent past. As pointed out by Perez, we should view the burst of the "dot-com bubble" in 2000 and the financial collapse in 2008 as a double bubble which is part of the fifth techno-economic cycle. Building on this premise. I made a bullish 2010 prediction for the Cutter Consortium. Here is the botton line from this prediction:

"I expect 2010 to be the first year of a prolonged golden age. Serious as the various problems we all are wrestling with after the 2008-2009 macro-economic crisis are, they should be viewed as systemic to the way a new generation of revolutionary infrastructure gets assimilated in economy and society." 

Likewise, my prediction for The Agile Executive is optimistic with respect to Agile Business Service Management:

"Agile breaks out of Development into IT (and beyond) in the form of Agile Infrastructure and Agile Business Service Management."

Click here for details of my techno-economic prediction for Cutter, here for my Agile-focused predictions for The Agile Executive. 

I am sure you have all been watching the Climate Change thing in Copenhagen. It actually reminded me of Ken's blog entry about Government IT - how to take an enormous amount of people, time and money and achieve very little.

• Now, do I believe that the world is getting warmer? Think so, although it's bloody cold here, the garden is covered in snow, and we've had more snow in the last two years than I can remember for a long time.
• Is the warming caused by man (and woman)? Probably helping to push it along.
• Does it matter? No idea, as everyone seems to have a convincing scientific argument proving it one way or the other.
  

What really annoys me about all this Climate Change stuff is that our government here in the UK simply sees it as an excuse to push their own agenda (desperate need for money to pay off their enormous reckless debt mountain) and slap a "green" tax on us. I would have no hang-ups about paying extra for use of energy, if the money actually went towards trying to find a working alternative energy source rather than being wasted on illegal wars and politicians' ludicrous expenses. (By the way,I can heartily recommend reading this. IMHO, this appears to be sane summary of what the world is doing with its finite oil resources and what we should be doing about it. And if you are looking for a late Christmas present, try this, which is a thriller I wrote based on a device that solves the world's energy problems - ignore the totally inaccurate review on Amazon by B.Callahan, I can only assume I met him once and upset him/her! Unfortunately, I have no way of contacting him/her to find out why as I am an Amazon UK customer and not an Amazon US customer, and Amazon won't pass on my question!!)

So what has all of that got to do with IT and BSM? The answer is that all too often in IT I see people pushing their own agenda based on a frightening lack of facts rather than actually getting down to the fundamental issues. The vendors obviously do this for reasons of trying to sell you something, and it is all too easy to get sucked up in new trends and ideas. I am not asking you all to become Luddites - just healthy cynics, who ask for proof of something before blindly accepting it as the universal panacea. (Just think, if we'd all done that years ago, WINDOWS would probably have never got out the door, and we night have ended up with a robust, secure operating system!)

The good news - BSM (done right) works. I've seen it, touched it, used it and seen the reduction in TCO it can bring at customers.

Apologies for the lack of blogging recently, but a combination of practising for a couple of Christmas gigs (I play keyboards and guitar) and being laid low by one of those tedious stomach bugs means that I have been somewhat occupied. Anyway, I am now out  of bed and the next practice isn't till later this evening, so I thought I would try and start a conversation on this whole cloud thing - makes a change from talking about Tiger Woods!

The title above is not the one I was going to use originally - I am more of the "Hey, you, get off of my cloud" generation (Rolling Stones for the youth readership). However, the song title, which Google tells me is from Oasis (grossly overrated IMHO) seemed very apt as:

1.Everyone has a different opinion as to what "Cloud" is, so
2.Every vendor has it, and hence
3.It is, like all new things in computing, the solution to all known problems, and therefore
4.It is also not the solution to all known problems, and will introduce a whole new raft of issues and problems.

For those who think that is a tad cynical, I have been in computing for 38 years - enough said.
Having said all that, "Cloud" will happen in some way or another and the data centre of the future will by definition be a selectively outsourced beast with e.g. one company running the network, another the desktop apps etc.

Hence, what I would like to throw open to debate is how do you set, measure and report SLAs in that environment? Who owns the service? Who reports to whom? Who knows how to react to a problem? Is it critical to them as a provider or critical to you as their customer? What does an outsourcing contract look like in a "Cloud" world"? etc. etc. 

With the British economy haemorrhaging £180 billion this year, mostly caused by the banking bailout, but not just the Banks are causing the problem. The National Health Service (NHS), the 3rd largest employer on the planet and an annual spend of £100 billion (that is 100 thousand million pounds to you and I, or £1,666 per Man, women and child in the UK per annum !). Just to add to this budget the UK government decided back in 2002 (and it's not due to complete until 2014) to create a "central spine" of IT for the entire NHS for:

• Patients' records to be electronically available to any GP or hospital in England, thereby replacing local NHS computer systems
• Other services include electronic prescriptions, an e-mail and directory service for all NHS staff, computer accessible X-rays and a facility for patients to book outpatient appointments online
• It is the largest single IT investment in UK - costs are expected to hit £12.4bn over 10 years to 2013-14
  

Can you a) believe the costs involved here, and b) believe that the 3rd largest employer on the planet does not have email services across all its employees?

I'm sure Microsoft or Google would have provided a stand-alone secure service to them if they'd asked! Tell me one other major business that does not have their employees reachable via Email? No wonder changes in policy and efficiencies are rare if they cannot quickly communicate to their staff. But just this week they have announced that because of the budget deficit they will need to cut this £12.4 billion budget down by £600 million.

My view is that no commercial business could afford this kind of project and more importantly if they did, it would have to be delivered well within 12 years. Now the saying goes that a week is a long time in politics, but 12 years is a really long time for an IT project, especially considering how quickly this industry evolves and progresses. I imagine that if this plan were to be considered today, cloud computing would be considered, which, again in my opinion, would speed the roll out and connectivity of all the major suppliers and NHS divisions.
 
Whilst I agree all this access to connected data across the NH Service makes sense to avoid the slow paper trial and minimise errors in typing and re-tying, it also raises the issue of privacy of data. Abuse of this information could be rife, with pharmaceutical companies willing to pay vast sums to access the data for analysis to determine which drugs they sell should be targeted at what audience. Insurance companies wanting access to determine risk and exclusions whereas today most people are entitled to medical insurance without even a check-up.

Would the Police Service  gain access for DNA matching, thus circumventing the debate over a central Police DNA database? The list goes on.

Some "selling" of the data if approved by the NHS client (the public) could actually go some way to recovering the cost of the project, a business (nasty word in Government circles!) plan.

Now, I believe, that we in the IT Service industry should get involved in these debates, perhaps through bodies like the ITSMF, British Computer Society etc . we have a lot to offer in terms of experience and insight. These large multi-year projects need to be reviewed and revised annually to ensure that they keep up with technological advances and prevent the completed project being outdated and almost inoperable.  IBM's market capitisation today on the Nasdaq is around $166billion, approximately the size of the NHS annual budget and with less employees. Perhaps they could provide infrastructure and service advise based on their own internal connectivity and I'm sure they did not spend 12years to obtain it at a cost of £12.4 billion!

Government really do live in a world of their own with no concept of business acumen or reality, if only they were held accountable by the people to the same extent that shareholders hold businesses accountable, we may actually achieve value for money, in a timely, cost effective manner. Look out America, if you go for Health reforms, consider who will run it, and those hidden costs and data debates!

Is your company’s IT department passionate about their work?

If not, then perhaps you’re not letting them solve problems…  Passionate IT solves problems - not just for IT, but for the business.

More from John Hagel on pursuing passion »

The premise of Agile Business Service Management is that software methods can be successfully applied to  domains like IT Operations and Service Management. An illustration of the power of applying Agile beyond programming is given in Anne Gentle's post Agile Across the Enterprise. Anne discusses the kind of hyper-productivity that transforms the econonics of various classes of books. The potential disruption to traditional publishing is mind boggling...

The answer to this self-posed question is given in Dr. David Farrar's 2/27/2009 Amazon review of Larry Klosterboer's book Implementing ITIL Change and Release Management:

For starters, many of my clients are IT and information systems specialists. Most are going through pain, change and challenges related to keeping up with the rapidly shifting demands of their customers, the adoption of new technology, and of course, the economy.

I wonder whether I should laugh or cry...

Colleagues Rico, Sayani and Sone recently published a book entitled The Business Value of Agile Software Methods: Maximizing ROI with with Just-in-Time Process and Documentation. Based on hundreds of systemic research studies, the authors cite some very impressive numbers. Even their least impressive numbers are awesome. For example:

• Agile methods ROA 1.6X more than traditional [software] methods
• Agile methods NPV 2.3X more than traditional [software] methods

We do not have anything like this rigorous study in the nascent field of Agile Business Service Management. I would, however, allow myself to suggest that the gains to be had through Agile  Business Service Management might be as impressive. The three main reasons for my suggesting so are as follows:

• Deja vu. Much of the gain in applying Agile methods to software engineering comes from breaking the metaphorical wall between development and test. Likewise, the application of Agile principles, technologies and practices to Business Service Management leads to breaking the metaphorical wall that seperates development and test from operations.
• Life cycle economics. As observed by Boehm, defects fixed during the Operations phase can be two orders of magnitude more expensive to fix than during the Requirements phase, one order of magnitude more expesive to fix than during the Code phase.
• Data-driven decision making. Agile deployment enables "real time" customer feedback. Hence, the quality and timeliness of business decisions are greatly improved.

I don't really know whether colleague Dr. David F. Rico might have an interest in Agile Business Service Management. I will most certainly try to induce him....

I recommend the following acid test in The Agile Executive post entitled Prior to Sprint Zero: A Note on Jakob Nielsen's "Agile User Experience Projects":

If you consider this "prior to sprint zero" approach a bit heavy-handed, I would offer a simple test to assess its reasonableness. Play with a number of IT Service Management (ITSM) products that you picked in random. Once you did so, compare the numbers of those that clearly have services at their core, to the number of those that integrated services into their user interface as an afterthought.

Granted, the test was originally conceived to make a point with respect to the timing of user interface architecture tasks in the cycle of Agile software development. However, it is actually applicable to ITSM products in general. For example, the results of the test cited above are indicative of how far a system management vendor shifted his mindset, architecture, technology and practices from servers to services.

I would actually go one step further to suggest the user interface architecture test as a reliable "bullshit detector" for vendor hype. Whenever a fundamental application paradigm change takes place, the degree to which a vendor embraced the change can be tested by examining the orientation of the user interface. As a potential customer, it tells you how seriously the vendor walks the talk with respect to embracing paradigm changes and investing in so doing in earnest.