The biggest application estate we're working with at Juriba is 12,000 unique applications. Imagine that, 12,000 applications across a user and computer estate running into hundreds of thousands. I mean, where do you even start?

Well, let's start by actually defining the problem. You've got your apps strategy sorted out by now (if you haven't you are wasting your time), and decided which platforms and formats you are going to use. This includes the operating system architecture you are deploying (32 or 64 bit).

Now you need to understand the applicaion estate. This is where it starts getting complicated. Organisations around the globe are all pondering the next question...What is my application inventory? Some (the clever ones in my opinion) make a very quick judgement call by stating that they will only consider 'managed' applications. A managed application is a software package that is 'known', it is delivered through approved distribution mechanisms, and can be traced back to a collection or group.

Some however, want to start managing their 'unmanaged' applications. They believe that it's IT's problem to solve the application inventory. I feel there is a very simple problem with this approach. How did the applications get on there in the first place? Well, either the user (with admin rights), or the support analyst (with admin rights) loaded them on.

Herein lies the problem. Any administrator of the local machine can load on whatever they like, whenever they like. Can you manage their local apps? Not in my opinion. You could survey a machine today and have no guarantee that it looks the same tomorrow. So why even try? How can you even begin to contemplate putting a structured deploment program around such moving goalposts? In addition, most people I know that have local admin rights have so legitimately due to their job function, and are perfectly happy to re-load their apps themselves. If you try to make all their apps managed, not only are you forcing the cost of packaging into the organisation, but you are also stopping people doing their job role efficiently.

Of course, I'm not saying you shouldn't use this opportunity to rationalise your applications, and where it makes good common sense, to bring applications into the managed portfolio. All I'm advocating is a pragmatic approach. You'll never get completed otherwise.

So how do we get our arms around the application inventory? Well, by creating a list of 'known' applications we are at a good start point. Now we need to know what's compatible with the chosen platform. In previous times, this would involve an army of application coordinators, packagers and testers. Thankfully, this is 2010.

Now I don't usually do this, but I wanted at this point to give a shameless plug to two companies with grea products in the application compatibility space because I really believe in what they are doing. They are Changebase (www.changebase.com) and AppDNA (www.app-dna.com). Both have products that will tell you which of your applications are going to work on your chosen platform in a very fast, low-overhead fashion. They'll save every organisation an absolute fortune in getting apps ready and reducing the project timeline. Check them out - it might be the best decision you take on your Windows 7 migration.

What's impressed me the most about this week has been the general buzz and sheer amount of people trying to find out more information about Windows 7. Microsoft's marketing has been right on the nail, partners such as ourselves have been havily involved and informed of the progress, and we have a wealth of material to help push forward. I also think there is a state of mind thing going on here. Certainly in the UK, IT departments have been scaling back, investment budgets have been cut, and generally, those still employed have been asked to do more and more with less resources. Maybe Windows 7 is that new, exciting project that is going to turn this negativity around. April 2014 sees Windows XP go end of life, so there's a clear timeline and directive to get it done. Virtualisation of applications and desktops is an effective reality. We've all got proper strategic decisions to make. What a great time! We'll have to take on more staff to deliver it, we'll have money to spend and we can finally spend money to remediate some of the old stuff. No wonder everyone is talking.

So once we've all been 'wowed' by the technology, what next? Now we have decisions to make - why, what, when and how? First the why? Well that's easy - if we don't do it, we won't be able to buy new machines because there won't be any drivers, we'll have to pay Microsoft for extended support, there are cost savings we'll be missing through Direct Access and Bitlocker and we can introduce additional productivity tools to make our workforce more effective. Job done.

Now what? What infrastructure are we going to utilise, what will be our application delivery method, what platform(s) are we going to be using, what is our build method, what is our business case, what is our budget, what is our governance process, what information do we need, what tools are available to help us save time? All these are critical questions to ask. Failure to answer them will inevitably involve a longer, drawn out, more expensive migration project than the CIO expects.

So we've answered those critical questions, let's look at when? When will our infrastructure be ready, when will our build be complete, when do we plan to deploy, when do we plan to finish, when do we engage the business, when will our applications be available, when will our information data-mart be usable, when do we engage suppliers and when do we need our resources. A word of warning ... I guarantee that the timeline you set will be too short. If you take what you plan and add at least 50% you'll be closer to the reality of your migration. There are a lot of components here - don't underestimate how long it will take to get you ready to build everything you need.

And last, but by no means least, the oft forgotten 'how'? I've sat through many planning meetings where all the effort was front-loaded into the product build phase that nobody really thought about how the project was going to be delivered until it was too late. If you're not thinking about this now, your project will go over budget - no question. Technical rollout is the easy bit - don't let anyone fool you. Technology is so advanced these days that I can kick off a full Windows 7 build + applications from a single command line. But it's not about the technical build, now it's about the end user. How do we identify the 'ready' users, how do we execute the deployment (rebuild/refresh), how do we manage the project, how do we engage the business, how do we report, how do we govern, how do we identify hardware/application incompatibility, how do we prioritise and target applications, how do we get service delivery teams more involved, how do we track progress, how do we hit timelines, how do we support the new environment, how do we do this more intelligently! I've not even started - this is by far the longest section and typically gets the least focus. Don't fall into that trap. Don't be blinded by the easy of the technology delivery. Don't go over budget. Don't forget to figure out 'how'. Don't fail.

Of course, the same used to be said about virus and patch management. Not any more. Those items have, in the main, been dealt with by a combination of technology and process focus. It's rare to hear these days that a company spends the inordinate amount of time that we used to on such activities.

Let's wind back the clock. The slammer virus has just hit. It's a brand new virus, never seen in the wild and it's spreading. Corporate machines are getting hit by the millions per second. Our first answer as IT - turn all the machines off, stop the spread. Next, figure out a way to patch and update all the machines without further spreading the problem. It was a common problem, and it required focus. Why did it happen? What could we have done to stop it? How do we improve our processes to reduce the risk in the future?

With a combination of senior focus from IT directors, software vendors and businesses who put the cost into $billions, the problem got pretty much fixed. Tools can now put out an update in a matter of minutes across hundreds of thousands of PCs, anti-virus companies have improved their speed to market for definition updates, IT have put in fast, slick processes to get the patch testing done to reduce the vulnerability window and most importantly, Microsoft sorted out their patch release process and made it regular and automated.

There's an argument out there to state we that we haven't been applying the same levels of focus to Windows migrations, even though the risk and cost are potentially greater. Typically, the lessons learnt from past rollouts are forgotten, and we spend months re-inventing the process wheel. The people involved in those efforts have long since moved up the management chain, and a whole raft of new resources are bought in to make the same mistakes as their counterparts all those years ago.

It's a common story we at Juriba hear time and time again. My only conclusion is that because the projects are generally such distinct, funded pieces of work, the people involved in them generally are not given, or more likely, don't want the responsibility to put in place more strategic tools and processes. Sure, the projects get delivered, but the legacy never remains. Therefore, we seem to live forever in the boom bust cycles, where each new migration is a mass of new resource, technology, process and cost.

So how do we begin to fix this problem? Well, in my experience, the project team will clearly identify all those issues we've been living with in BAU, the process challenges, the system challenges and the efficiencies that could be bought with new tools and processes. What now needs to happen is for senior management to take those issues and assign them to the BAU teams to implement, maybe even using some migration project funding to implement them. After all, if you can improve the processes and tools during the project, that will surely make the project more efficient and save critical expense.

But here's the key piece. We know that Microsoft are committed to a new desktop OS release every 3 years. So even if organisations skip the odd operating system, we're destined for a cycle of 3 year migration, 3 year steady state in the largest corporates. We don't need the project team in the steady state years, but if we can implement consistent tools and processes in BAU that take the pain away from the migration planning, when we do need them, we shouldn't be asking them to reinvent the process wheel. This is the key to future migration success and the beginning of what we'd like to see as a new cultural way of thinking about migrations within BAU, something I'll be covering more shortly...

This got me onto thinking. If all these organisations are doing it this way, it's hugely likely that this is a global epidemic. Is anyone just going to deploy Windows 7 into their existing environment? And if not, what impact is this going to have to the timeline. Organisations such as Gartner regularly quote a deployment timeframe of 1-3 years. If the majority of organisations are going to build in an infrastructure change at the same time, isn't that going to push the timeline out by a further 1-2 years? We're in mid-2009 with Windows XP support ending in 2014. Hang on, that's 5 years - is it time to start the mass panic, before the OS is even released on October 22nd?

Well, not quite. The majority of these organisations are in a much better state than they were for the last migration. Software and hardware inventory is vastly improved, many of them have proper packaging standards and application understanding, locked down builds have reduced complexity and hardware performance improvements have driven down the number of devices they're currently managing. But that doesn't mean they should get complacent. Start in 2012 and build in an infrastructure change, and I can pretty much guarantee that the organisation won't be done before Windows XP support officially ends.

So what's the advice? Well, the advice is to at least begin thinking about your migration now. What's the technology mix going to be (fat/thin/virtualised/infrastructure delivery/inventory) for the Windows 7 migration? What tools can we use to rationalise the environment prior to migration? How can we ready the infrastructure? What are the key dependencies? What processes can I put in place now to ease the transition work later? All of these things can have a huge impact in the success of the project and there is nothing stopping anyone sketching out these thoughts right now. Certainly in my experience, a clear infrastructure strategy and execution, coupled with great processes can save millions of unnecessary expense on a migration.

Once the planning and infrastructure is in place, it is critical to get the deployment logistics plan in place. Knowing which environment you're going into and what needs to happen to get a user into that environment is critical. How is the project going to be managed, and how will we identify which users to migrate and when? Automation tools that were not available for the last migration can mean that this endless logistics challenge can be tackled much more effectively in the future. Everything from application compatibility testing and remediation, hardware compatibility, and even the whole end user migration analysis and management can be automated using software tools that will take cost, time and risk out of the project. But like all tools, they need to be part of the long term strategy so get them in now, get them tested and you'll be in a great state for the migration.

At Juriba we're working on some whitepapers to help organisations plan their Windows 7 migration more effectively. Look out for these on our web site shortly...

In reality, most organisations are going to be driven on desktop operating system plans by Microsoft's end of support deadlines. Not only that, but enterprises will also look at the infrastructure, software delivery mechanisms, new technology, user experience and all other facets of desktop delivery when they next migrate. This often results in huge, almost undeliverable programs of work, costing tens of millions of dollars. Why? Because many organisations budget on 'lights on' and 'investment' terms. If you're going to ask for $10m to deliver Windows 7, why not ask for $15m and do MDOP, desktop virtualisation and change the inventory system at the same time? Unfortunately, the culture is that any Windows change is going to be a massive effort, and therefore, inexorably tied to a spiders web of complications.

So the question becomes how can we take steps toward changing this culture? Both Gartner and Forrester both recently wrote about performing Windows migrations as part of desktop hardware refresh to save 41-59% of the cost by using existing teams and processes. It's a great theory but currently lacking in practical application. I know of very few companies that have actually managed to implement these methods or achieve the potential migration savings. User change + computer change + application change + h/w compatibility + application compatibility + external factors (technology, business governance/sponsorship, outsource contracts etc) mean that it's difficult for your average desktop analyst to make an informed migration decision.

Ideally, an operating system change should be as simple as an application rollout. A staggering 30-42% of machines will get touched during a support incident for either a rebuild, or for a hardware refresh every year. That means EVERY machine in a three year period should receive an OS build. Imagine what percentage of those machines COULD by upgraded. Imagine performing an entire OS rollout without a massive project team or associated expense! Imagine having the time to spend on real infrastructure innovation efforts that provide standardisation, new functionality, huge cost saves! That's my vision, and what we want to enable with tools like dashworks. It's a new way of thinking, but if we can remove the barriers to OS upgrade, we can achieve the goal.

The IT departments of today have a multitude of data from which to make their decisions. But how are they using that data? Is it efficient? I have, in the not too distant past sat through meetings reviewing problem ticket metrics collected 6 weeks ago. Of course, by the time that the questions are being asked about what happened, how it impacted, and what is being done to rectify it, the organisation has moved on, changed it's footprint and processes. The review becomes irrelevant - it's too late, people have moved on. What's really needed is to manage the end to end incident at the time it's happening, and ideally to predict what could happen before it happens. If it does happen then to make sure that the changes made in remediation are tracked dynamically. What was the impact the day after, how is the current environment stability, what are the new metric trends? These are the traits that will differentiate the managers of tomorrow from those stuck in the past, churning out their monthly reports for an audience that is working in the here and now.

So how does an organisation get to dynamic, accessible business intelligence?

1. Understand the requirements:
   Ok, so it's an obvious one, but let me explain. BI means something different to everyone that wants to use it. Therefore, when designing a new system, you'll find huge organisational engagement, a mass of requirements and an implementation timeline of years. Distilling what is really important to multiple levels versus what one individual thinks might help them is a complicated task and where most BI solutions fail. Get someone that has worked their way through the organisation in multiple roles, understands the needs of the staff and managers, and can judge the merits of each requirement based on actual value.
2. Stakeholder Buy In:
   A second obvious one, but you would be amazed at how many people will design a fantastic system, but completely miss the senior sponsorship effort. So why is this so important in BI implementations? Well, most BI is focused around faster delivery of information, better visualisation, and ultimately, the reduction of roles due to the increased efficiency this delivers. Now, who will be the main dissenters in the mix? Probably the people whose job it has been to produce this information manually, their management chain, and potentially the owners of the data itself, worried about what the transparency will highlight. So, make sure they are involved, get the senior level backing, especially about the bottom line returns, and make sure they drive it down the organisation, and finally involve the people that currently 'work' the data. They will be negative, but you'll often find a progressive type or two that can really give you a better system.
3. Visualisation:
   Data is boring, let's not make any bones about it. However, information can be really interesting if it's obvious what you are looking at and the data is correctly tied back to the base. So what makes a good BI system? Well, firstly, make it graphical. Nobody wants to look at reams of statistics, unless you are an accountant type. Employ someone to properly 'skin' your system, use big bold colours for red/amber/green status, use graphing tools to present information and historical data, and most of all, make the interface dynamic. Allow your users to click anywhere, link the data points, aggregate data for summary levels and make it flashy. Much as we always like to believe that content is king, we also love a 'wow' factor, so give the users what they want.
4. Data Quality:
   Probably the most difficult thing to get right in a BI system is the quality of the data that you render out. Simply speaking, a single, negative comment from a CEO where incorrect data has been displayed can have a massive impact on the success of your implementation. So, check and treble check that the numbers add up, test thoroughly that any drill down views are working correctly, and most importantly, ensure that when you are pulling from multiple data sources, that corruption or failure of those data extracts do not ruin the integrity of your current data. I would take old information over broken information any day of the week.
5. Speed:
   The latest generations are used to having a multitude of information at their fingertips. No point having the best BI system in the world if your pages take minutes to load. They'll get bored and soon switch to either doing it themselves quicker, or investigating a different source. So speed is of the essence. Make certain that your technology can deliver pages in no more than 5 seconds, preferably less than one second is optimal. Of course, with major technology advancements in Microsoft SQL, analysis services and other database engines, this is becoming easier and easier to achieve, and again, is critical to the success of your implementation
6. Proof of concept quickly:
   BI need not be a holy grail of data management. In fact, I would argue that everyone that manipulates a spreadsheet with more than one data source is actually applying business intelligence to their role. Having implemented multiple BI solutions for everything from application workflow to problem ticket management, the biggest lesson I've learnt is that people want the information, they just find it hard to start from a blank page. However, many people are great at seeing something and improving on it. Therefore, get the original information views up there quickly. It will drive innovation and more often than not, give you directions you would never have thought about before.

Juriba's dashworks product is designed to achieve all of the above in the ever changing desktop infrastructure environment. We use business intelligence to drive organisational behaviour, reduce expense associated with both business as usual and investment projects and improve operating efficiency. Our customers are saving millions of dollars/pounds annually by getting there faster and through the ability to truly see their world.