Static Analysis: Out of the closet

A friend of mine, Chris Jackson may or not be known to you few who read this blog. Touted as the Top Man in Application Compatibility he undoubtedly has more knowledge, experience and understanding on the topic of application compatibility than all other organic (non-silicon) beings on the planet.

Recently, he posted a note on his blog about static analysis for application compatibility that may be interesting.

His posting can be found here;

http://blogs.msdn.com/cjacks/archive/2010/03/23/it-s-not-your-to-do-list-using-application-compatibility-tools-to-diagnose-problems-not-surface-them.aspx?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+Microsoft%2FMSDN-Blogs+(MSDN+Blogs)

I think his views on the topic are interesting - however, I think he raises a few key points that I feel the need to comment upon.

Chris notes that;

"One thing you want to be very careful of with all of the tools: it’s remarkably easy to surface all kinds of “issues” which would be “better” if you fixed them, but the software still lets you get your job done if you did nothing about it. Chances are, you were given the budget for an application compatibility project, not an application quality project. Application quality projects cost more than application compatibility projects – don’t create one accidentally."

I think from what we are seeing in the Enterprise application compatibility space is that as part of a migration to Windows 7 (or App-V) getting your applications to the next platform, really is a "Quality Issue". We are finding that most clients standards have changed and/or improved over the past few years since the last migration (remember the move TO Windows XP??).

So, the point here is that there is probably a large chunk of work to be done on each package as part of the migration effort. So, here is a quick summary of the tasks you may to complete to get each application package ready for the target platform;

1. Windows 7 Compatibility fixes
2. App-V tuning and optimization
3. Industry Best Practice Updates
4. Quality Assurance Analysis and Updates

So, you may have a lot of work to do to get your application packages into shape for the new platform. When we created AOK, we saw this issue coming and created automated fixes for these issues.

So, if you are doing a Compatibility Project, you are probably expected to also deliver a Quality Project.  And, my guess is that you need an automated solution for both the analysis and the remediation. 

Automated Fixing is good practice, good change control

I've been singing the praises of automation (hey, I am a computer guy) for several years now and in many instances it has been focussed on the application migration arena .  However, in more and more discussions with organisations the whole BAU (Business as Usual) topic pops up when we’re looking at application compatibility and maintaining that gold standard across the enterprise once the deployment is complete. Meaning, keeping the applications working while the organization changes above and below the application stack.

So this got me thinking about organizational Change Control and how automation fits in. Here’s my "50,000 Application"  view of the benefits of automation for Change Control within an organization;

1. Automation is good for change control –because of its orderly, process driven fashion it makes it easy for system administrators to achieve consistency across all changes with the application estate.
2. Automation by its very nature will have some form of log files build it. This puts more than a tick in the box for the auditing process and makes referring back to issues /process simple, quick and cost effective. Auditing tracks user actions and with good logging, you get the logic of the reporting and remediation process as well.
3. Consistency – already mentioned in part 1 – the removal of human error is key here. When it comes to migrating an application estate of native, web, browsers and portals, consistency is king. Automation enables organisations to achieve this.
4. It’s quick, it’s fast and it’s cheap. Automation frees up resource to focus on the bigger issues, it saves time and money both things the enterprise is short of in today’s economic climate. Computers are cheap, people are great, but not cheap.
5. Automation is trustworthy. This is a big leap for some. You trust your calculator because you have used it enough times and it has been right enough times to earn that trust. Automation algorithms (I prefer the term recipes) are generated by humans, performed by computers but generally tested by humans. When you trust an algorithm, you are trusting the humans who tested the outcome. Automation outcomes get tested by more people, more often and generally under more conditions than a manually performed process. Once you get automation right, it stays right, for longer.

So, if you are playing chess, calculating Pi or fixing application compatibility issues, I would place my bets on the  organic/fleshy coach, and the silicon player any time.

See you in Berlin next week!