Monday, 15 December 2008

The Efficiency of "Right First Time"

Can you tolerate failure?

Some situations cannot tolerate failure: The highly political government project, the business-enabling SAP deployment or the market-leading e-business application all share a common characteristic - getting it wrong hurts.  And the most common symptom of getting it wrong?  Poor performance, poor availability, poor service - and disgruntled customers.

What happens then is where heros make their reputation.  Firefighting, troubleshooting, late-night candle-burning, bonus-generating heroics.  Don't get me wrong, it's great to be a hero - saving the day from evil, just before the clock ticks to zero.  But surely it's better not to get into that position in the first place?

Lessons from other industries

The use of simulation is common in industries where getting performance design right first time is critical to the bottom line.  Imagine building an aeroplane with control systems that didn't respond in times, semiconductors which performed worse than their predecessors, or civil engineering projects which couldn't handle the projected loads.  Scenario planning is also a favourite of agile business.  Just as a chess grand-master is thinking several moves ahead, the business planner looks beyond immediate trends and plans the impact of their next business strategy.

But, IT is sooo complex

For IT professionals, getting it wrong hurts equally as much; but here we are at a significant disadvantage.  The complexity of enterprise-class systems, the interconnected and often opaque nature of cloud services, the lack of insight into business initiatives leave us in the dark.    Whilst we're under constant pressure to reduce cost and risk, the ever-increasing complexity forces us to over-provision, to reduce the risk of getting it wrong. 
But is that right?  Is it true to say that IT is more complex than embedded avionic systems?  Probably it is not true to say that, although the rate of change is certainly higher.  Can we still afford to justify time in planning, even though the sands are constantly shifting under our feet?  In the past, we've focused just on a limited number of critical systems, or performed some pretty rudimentary analysis that makes us comfortable - and trusted in the heros.  But there must be a better way - a way that enables IT to be a part of the planning process, not just driven before the wind like a rudderless ship.  There must, mustn't there?

Converged scenario planning 

Times are changing.  Scenario planning tools have long been available in the marketplace, in the capacity planning sector, and now they are catching up with the needs of the business of cloud management.  Remember, that the agility of cloud computing provokes the need for better management of headroom - to maintain the capacity to support elastic demand, and cost - to do so at a profit.  Cloud Capacity Management solutions must incorporate and translate the needs of the business into capacity requirements, and also translate capacity requirements into business constraints.  And the universal language of business?  Currency.
The new world of the cloud demands alignment between the needs of the business and the capacity provided to it.  The cloud-enabled enterprise IT spend is proportionate to the needs of the business.  The cloud-provider has the challenge of ensuring that its revenue covers its costs and provides a profit margin to its stakeholders.  Efficient decision makers are seizing control of their supply chains, and ensuring that risks and costs are managed effectively throughout.  The convergence of cloud and consumer planning ensures transparency in that decision making process.

The new synergy

Successful business and IT leaders are getting their act together, and learning to co-operate in new fruitful ways.  Planning for IT and business initiatives through capacity management, with focus on both customer experience and the bottom line, is enabling enlightened decision makers to understand the ramifications of their alternative strategies, and understand the budget and risk parameters for their chosen plans.  

It turns out the old adage "a stitch in time saves nine" still has relevance today..

Monday, 8 December 2008

Performance in a downturn

Reviewing my activities over the last few months, it has been interesting to observe the different reactions that individuals and companies have to a downturn. Broadly speaking, conversations have led into one of two camps. The first is the more pessimistic, that cutbacks in budget are leading to reductions in planned expenditure - and that taking on new initiatives at this time would be foolish. The second camp, reveals a more entrepreneurial spirit - in that the downturn creates opportunity to develop better cost/efficiency in IT management processes and that additional value can be delivered to the business by implementing cost-savings measures.

As the CIO magazine reported recently, CIOs must show leadership to guide their organisations through the downturn. Delivering performance in a downturn is a test of guts, and presents a real opportunity to those who choose to grasp it. For some, improving cost/efficiency of their IT operations means pruning staff numbers - but for others, it means delivering increased results with a declining budget. Determination to deliver maximum value to your customer can position CIOs and IT professionals in the best place to weather this downturn.


Monday, 20 October 2008

Model universe

A respected friend and technical expert discussed recently his concept of a Model Universe for an IT organisation. Conceptually, each and every activity that an IT organisation undertakes in delivering business value should be documented and understood using modelling techniques. Some people misunderstand business value.

Business value isn't described in computer talk, ITIL jargon, or CMMI frameworks. Business value is demonstrated in hard cash, brand awareness and market reputation. Business value is delivered by IT organisations in the generation of revenue, capacity for market access and quality of service to its customers. The value of a model universe can best be understood by removing the understanding of each of those attributes. It is the understanding that is captured and documented with a model, the understanding of the performance of the revenue generating vehicle, the capacity of the vehicle to access the market, and the quality of the service that the vehicle provides.

Without the understanding, you have a vehicle but no blueprint. You have the car, but no owners manual. Without the model universe, you have the capacity but are unaware of the limits. If you had that insight, what would you do with it?

Thursday, 9 October 2008

manual vs automated "performance engineering"

When performance testing practises mature, recognising the connection between response time and system capacity, insight into the nature of the correlation becomes important. As often as there is a significant gap between a performance test scenario and potential live scenarios, the value of performance testing takes a blow. Filling that gap cost-effectively requires insight, which can only be gathered by correlating the workload, response time and system utilization. At this point, creating a performance model is the only technique that fits the gap.

But performance modelling can be a complex process, filled with uncertainty and concerns about time investments. Often, it's better err on the side of simplicity rather than drive into the details, however tempting it may be. Leadership in this field is essential to derive cost/efficiencies out of this maturity transformation; there are many complexities lurking for the unwary.

In my company HyPerformix, one recent customer success story came at PepsiCo. Doug Taylor, Enterprise Test Centre Architect, recently said "if I can shrink the amount of work I do on performance testing, it not only saves hardware and software dollars, because the machines are smaller, but it also decreases the amount of time that the performance team has to build an environment, run and environment, and test it".

Doug was able to make significant efficiency savings by moving from a performance testing model to a performance engineering model, and reduce the amount of time taken in one case from 5 months to just 1 day. Don't believe it? Review Doug’s webinar online here

Thursday, 28 August 2008

Results: your top 3 priorities for 2008/09

I'd like to thank everybody for their input. I asked 50 Enterprise Architects what were their top priorities for 2008/2009. Although it must be said, not the largest statistical sample, the results perhaps aren't so suprising:

1) reducing IT cost base through consolidation/virtualisation
2) deploying new architectures (primarily SOA)
3) implementing an IT chargeback model

With the global market in so much turmoil, the price of oil consistently rising, and businesses under pressure financially, it's not suprising that cost issues dominate the top priorities for the EA community. IT leaders must continually seek to recognise the value that they provide to the business, and deliver cost/effective solutions to their business divisions. In the top priorities we see reflected a need to reduce costs, but also to ensure cost is proportionately allocated to lines of business. Finally, we see that new architectures are a key part of the IT agenda, delivering greater flexibility, agility and scalability.

Thursday, 21 August 2008

innovation vs outsourcing

I returned from a customer visit recently, where the operational IT landscape is outsourced completely to IBM. In line with industry trends, the outsourcer was engaged to contain costs of running an IT department. Again, the perception of IT as a cost centre led to a strategic outsourcing decision. This perception and subsequent decision must be reversed if innovation and value-based IT services are to be delivered, services which align to the customer needs, services which provide agility to dynamics of business.

In this case, the topic of innovation was discussed. The customer wanted greater insight into the future of their IT function, to allow greater control over IT budgets and drive optimization projects leading to improved cost/efficiency.

Of course, this is in the customer's interest. But is it in the outsourcer's best interest to allow such optimization to occur? It is unusual to find such elements written into the outsourcing contracts today, but perhaps as CIOs become better equipped to manage strategic outsourcer relationships - they can place themselves more firmly in the driving seat.

Monday, 23 June 2008

performance - more than just a technical nice

I just read this article The #1 reason IT often fails to deliver value and it stirred some further thoughts:

  1. IT fails because it doesn't know how to measure success
  2. IT fails because it overcomplicates service delivery, and all sorts of phoney KPIs are used
  3. at the end of the day, IT is about cost-effective service delivery to the business. Measurement of IT as a whole should focus on:
    1. functional alignment to business
    2. cost-effectiveness
    3. agility to meet changing business demands
Performance in these key areas will enable IT to consistently deliver value to the business by:
  1. delivering what the business needs
  2. doing so at the right price, but remaining effective in supporting business volumes
  3. whilst supporting change and allowing innovation

Thursday, 19 June 2008

... performance is alignment

woah -- Buzzword alert! "Alignment" what does it mean, and why is it relevant to performance?

Let me explain this by reference: when you go to the local PC superstore to buy a piece of software, on the back of the box will be a "minimum requirements specification" looking a bit like this:
  • 2 GHz processor
  • 1 Gb RAM
  • VGA graphics adapter
  • ...

But when you buy enterprise class software, there's no spec like this on the box! That's because performance of the software is directly related to the workload it's servicing: how many users, how much concurrency, how many transactions...

Performance alignment means that whatever resources you allocate to a task should be proportional to the workload it is processing. This kind of alignment means your investment is proportional to the business demand: right-sized for the job in hand.

Friday, 13 June 2008

... performance is agility

High performance businesses flex to meet changing market conditions. They capitalise on change, they innovate to drive change. This CIO blog from Forrester CEO references the frustration CEOs derive from the lack of innovation from IT -- "Innovation was a mystery to most CEOs, they are not getting it from IT.”

Yet where IT is integral to the business, then innovation is essential - and is a characteristic of high-performance enterprises. Innovation, agility, the ability to change the market as well as respond to it - all are influenced by the understanding of IT service provision to the business, the concept of customer demand, and the correlation of the demand to technology investment. High performance businesses with an IT footprint require this information to be captured and shared, to enable innovation and alignment between technology functions and the ever-changing market conditions.


Friday, 6 June 2008

... performance needs dedication

Performance doesn't happen on its own. Just like any top athlete, performance of any system needs dedication. Dedication towards improvement, dedication towards achievement, dedication to quality. If you have dedication, you have 50% of the equation towards achieving performance. The rest is down to enlightenment and self-awareness.

Thursday, 5 June 2008

... performance is optimization

Optimization is getting the best from your investment. When shares are performing well in the market, their value increases quickly and the returns on the initial investment are high. Optimization of IT systems requires the same measurement of value, through
  • measuring the increase in revenue due to Optimization
  • measuring the cost avoidance due to Optimization
  • measuring the productivity improvements due to Optimization

Wednesday, 4 June 2008

... performance is efficiency

Do what you do, do it with the maximum of effect and the minimum of effort. A good guiding principle for any systems management. Provided you meet the service standards, then minimizing costs should be the priority. Costly overprovision of service can damage your ability to invest in other innovations.

Take the example of a football player, he scores a goal by investing effort in running up and down the pitch. But too much running early in the game will impact his ability to score later in the game. His performance is measured over the whole game; efficiency of his own game has a direct impact on that performance.

So it is with systems. Cost/effectiveness service provision is only possible when you understand how much running that system has to do - and what goals need to be scored.

Tuesday, 20 May 2008

sizing, accuracy and money

I went to see a new prospect today who was able to openly describe the difficulties they had in getting sizing right for new architectures. One of the biggest difficulties was in being able to communicate with their customer on workload projections; another was in being able to communicate to the service support teams the impact that these workloads would make to their environment. Net result? Systems which are over-specced in some tiers; and suffering from performance problems in others. Admittedly, some of those performance problems were non-predictable; but even focusing on the over-sized capacity could save them money.

How much?
Typical TCO for a typical small server can be around €10k EUR or £8k GBP - per annum; if you pay for this yourself you might see this broken down into categories:
12% hardware + 8% software + 9% installation + 60% operations support + 11% service/maintenance

For accounting purposes; assets like compute capacity are often written down over a 3 year lifespan; so that typical small server would have a total cost of €30k EUR or £24k GBP

All of a sudden; eliminating a few servers can start to result in big savings! Taking 10 small servers out of your datacentre this year will save you €300k EUR or £240k GBP. for more on TCO calculation.

Wednesday, 14 May 2008

Non-predictable performance problems

Some aspects of performance are predictable. Study a horse-racing form guide and it will give you historical information that gives you some clue about how fast a race the horse is likely to ride. However, it's no guaruntee that your chosen bet will win the race - there are many other non-predictable aspects to performance that have some influence. Here, I'll list a few; and leave this topic to more scrutiny in further posts:

1) there's nothing as unpredictable as a person. Whether they're customers; staff; suppliers or jockeys; a person can behave completely erratically without a moment's warning. When assessing performance of systems where people are involved; statistical analysis of interaction patterns is very important.

2) bugs; gremlins or glitches. These quality deficiencies of imperfect systems will certainly affect performance, and since they are a consequence of design and creation - but thereafter hidden - then they will only become apparent when they choose to manifest themselves. Secure yourself with solid engineering processes; and test your systems before deploying!

3) acts of the Almighty. Often referred to in insurance contracts, 'Acts of God' can strike you when you're least expecting it - and blow performance completely out of the water. A flooding, lightening strike or simple UPS failure can all knock all or part of your system down; and cause service performance to degrade.

However; remember that many other aspects of performance are absolutely predictable. You may expect that performance for a system may degrade if you start adding more and more users. Consider the time spent queuing at the Post Office - you spend more time in the queue when more and more people arrive; this aspect of performance is predictable - provided you profile performance well enough. Consider these aspects as predictable:

1) performance degrades when load increases. Add more workload to your system, what happens? System will start to slow down. This degradation happens because throughput is nearing a capacity limit - and can be predicted.

2) performance improves when you upgrade your system. Add more or faster capacity to your system, you'll find it can take more workload - and often perform faster too. This can be predicted.

3) performance changes when you change your system. Whether you change your business processes; add new services; change to a new service provider or re-organise your underlying resources - performance can change, and can be predicted.

So predicting performance does have a place in a well-organised business; though due to non-predictable performance problems; predictions by themselves still don't give you all the answers you need.

Wednesday, 7 May 2008

Do you 'model early, model often' ?

I was speaking with a services partner today, who coined the phrase 'model early, model often'. We were discussing performance assurance from early in the lifecycle, working with loosely defined designs, and incomplete data.

We already know that modelling is a great way of predicting an outcome, but we can't take the results of a model seriously unless we're always updating them with the most current information. Calibration, and recalibration will ensure that your models retain their value throughout any extent of time - and as designs and business processes become developed, capturing their changing profile within your model-universe will keep your future vision accurate and always useful

Friday, 18 April 2008

The 4 Elements to Performance

Engineering systems performance will always have 4 main disciplines that divide and segment the community. However the value of synergy, when understood, will lead to greater value in focus of investment. Between being reactive and predictive, there are a raft of options available to the VP Operations to ensure performance through turbulent business or operating conditions:

1) Performance Diagnostics. Detecting and isolating problem areas: hotspots, bottlenecks and high latency components.

2) Performance Tuning. Optimizing configuration items to decrease latency and/or improve throughput.

3) Performance Testing. Checking any new release for performance, ensuring the quality of any change to business process or operating environment.

4) Performance Simulation. Predicting the impact of any proposed change to business process or operating environment, providing insight to make cost-effective investment decisions.

Whether in IT or in other business areas, progressive performance engineering which delivers all of these elements can provide significant value to a business which seeks best value for money, optimized business operations and ultimately, alignment with customer demands.

Thursday, 27 March 2008

Testing performance

When big changes are made to an application, some assurance is sought regarding the performance impact of the new release. Whilst performance testing is still not universally adopted, it is the de facto standard to 'prove' that a given application can perform adequately on release. There are many tools on the market, HP LoadRunner being the market leader, but they all essentially work in the same way - by simulating an artificial load onto a test environment and observing the performance of the result. This is such a standard approach that it's not often thought about, and is often considered a checkbox to release rather than to consider the intrinsic value of the exercise. However, some industry leaders adopt a risk-based strategy to testing which takes advantage of performance modelling technology to supplement the testing cycles. Performance Modelling has the advantages of:
  • Providing greater flexibility than testing alone. With performance testing, you can prove the performance of a given application configuration on a specific hardware platform. With performance modelling, you can predict the performance of that application under many different configurations and hardware platforms. Expect to drive efficiencies and optimization projects with a greater success rate.
  • Provides quicker value: often saving weeks from the project plans. How? Since Performance Testing depends on a properly configured evironment, various teams must get involved to prepare the ground for the test to be run. With Modelling, you can get there quicker; with a few mouse clicks you can evaluate several alternative configurations. Expect to save weeks from the cycle for every release.
  • Reduces cost of testing. For full value, performance testing often seeks to test against full-spec test labs. However, these can be hugely expensive to buy and maintain. Performance Modelling has none of these costs. Expect to save 90% of the cost of testing.
  • Accuracies. With reliable performance modelling techniques, expect to be hitting 90% accuracy levels on your capacity and performance predictions. Not as good as testing, but bang-for-buck a winner every time.

Those companies who adopt this risk-based strategy to testing, don't eliminate the need for performance testing - rather they drive cost savings and efficiency savings that traditional approaches can't provide.

Thursday, 20 March 2008

business partner performance

In a channels-led business model, a sales director faces two main challenges. First: recruiting the right partners - and second: investing in successful channels.

Finding and recruiting partners should be the result of a careful market segmentation exercise, finding synergy and alignment of business models. Synergy can be commonly found:
  1. between product manufacturers and service providers, where the partnership delivers combined value that's worthwhile to both parties.
  2. between manufacturers in related but dissimilar market segments. For example, between a systems management company and an analytics company. For this relationship, trust and rapport are essential to avoid conflict and threat.
  3. between system integrator and manufacturer. Consider a Formula 1 car, where the final product is greater than the sum of the individual parts.
  4. between service providers, where benefits of cost or added value can be found in an alliance.
Once a partnership is in place, then investment in the right channels is a critical decision for the sales director. It is imperitive to spend time enabling the successful channels, and to not focus so much energy on the less successful ones. For a clear and effective dialogue, I recommend use of a performance audit that can be applied to each channel. The audit should focus on 4 key areas:
  1. Ability to deliver. Consider the scale of the organisation, the interest in the relationship, the energy invested, and the trust factor. You want to know if your enablement efforts are working, if the partner sales, marketing and management teams understand the partnership value and are communicating it to the market. What's the trust factor in the relationship - is there transparency in your business relationship, or are you sometimes faced with nasty suprises?
  2. Focus on sweetspot. Your market segmentation exercise has identified a particular market in which you've found synergy. How closely does your partner align with the sweetspot? What's their customer base in this segment, and what are their marketing plans to grow in this space?
  3. Territory alignment. As part of a larger geography, what coverage does your partner have with the territory you've got to cover? What language skills do they have, where are they based?
  4. Revenue potential. Consider the result of the partnership. How much revenue will they deliver this quarter, or this year? What's the scale of the organisation? Ultimately your business partnership will flourish or flounder based on the joint revenue you deliver.

Having an open, regular and accountable performance audit with your business partners will encourage a trustworthy relationship, and allow your energy to be focused on key, strategic partners who deliver results.

For further reading on this subject, I recommend: