Applies to: Windows 7
A few months ago, Marc Sweetgall, the Program Manager behind the Microsoft Application Compatibility Toolkit (ACT), described what was new in ACT 6.0 from a product perspective. I wanted to go back and talk about how these features, and the approach in general, were all driven by YOU. Because the biggest thing that's new in ACT 6.0 is that it's not designed in the "ivory tower," but in the trenches. That's part of my job—to serve as your mouthpiece to the product team to make sure we get it right. The other part is to actually do application compatibility work, so I'm personally invested in ensuring that our tools support this work!
The first thing we heard, and we heard it loud and clear, is that any data should drive a business action. There is the expectation that it does.
Alas, that's not always what happens.
Rather, people use ACT because it comes from the Windows team itself, so therefore it must be mandatory for an operating system migration. So, they invest a lot of effort, time, and money in gathering any kind of data that the tool is capable of collecting. Then, they have this giant mound of data, and they kind of shrug their shoulders and say, "now what?" That question usually goes unanswered, so a huge chunk of that data ends up getting parked in the back room, next to a red Swingline stapler, and never looked at again between now and the end of time.
Clearly investing a bunch of time to collect data that you then ignore forever isn't super productive.
So, we cut down-level issue detection. Building this was a fairly big investment, and will get you really accurate data on an issue-by-issue basis. However, it gets you pretty bad data when you consider the application as a whole (since it's an expensive way to detect things, we only were looking for about a dozen things). It turns out nobody was asking, "Does this app have one of these 12 bugs?" They want to ask, "Does this app work?" We weren't doing any better than chance at that question. That means this data isn't actionable. Goodbye. The same is true for the Internet Explorer Compatibility Test Tool, for different reasons. Because the issues we detected were mostly of fairly low probability of impact, customer after customer ended up with long lists of potential issues, very few of which manifested as actual issues with the application, so it was wildly over-reporting, again making this data not actionable. Gone.
We replaced this with up-level issue collection, based on the Program Compatibility Assistant (PCA). That gives us two benefits. First, it allows us to invest all of our engineering resources in PCA, rather than dividing them. Second, it allows us to collect really relevant information that we can incorporate into a workflow. If I shim an application, I no longer have to package up the shim and email it along as my only means of communicating this solution—I can automatically get a record of the fact it was shimmed, as well as commentary on whether it worked, all incorporated into a single application timeline view. This is really convenient for deploying the solutions to a broad audience. This data is actionable!
This has long been the biggest feature request for ACT—the ability to add additional applications, which the inventory collector doesn't find. This is incredibly helpful when you find applications that are installed… "a little differently." I notice this with customers who have deployment systems that didn't do the typical registration techniques. (I've seen some pretty odd deployment techniques in the past, such as one that just dropped shortcuts to programs that lived on a server, which were just dropped into a special folder sitting on a desktop. I am not making this up.) There are also a number of applications created by boutique vendors that are very industry-specific and who, while creating really powerful solutions for the problem space, may not have the same level of expertise in the installer space. (For example, I know of one application where the customer has a 50% success rate on the application completing installation.) These don't always show up in any of the places where ACT, or any inventory system, is trained to look.
ACT 6.0 finally gives us this capability, which is huge.
One of my most frequent feature requests for ACT is to support use of the Delete key. You see, simply choosing not to care about an application is the single most effective way to transform the application compatibility tax into a sensible application compatibility risk management opportunity.
Well, I didn't get the Delete key yet; I still have to use filters for that. But what I did get I like a lot—I got the product pressing the Delete key for me, automatically, for a number of redundant applications. Multiple versions of the exact same application now all appear as a single line entry. By reducing the size of that list, I end up having an awful lot less work to do in order to do the remainder of the work to clean out an application inventory.
Now, I still want to get support for the Delete key, and I'd like to also be able to manually assign applications as multiple versions of the same application (particularly when package naming standards cause applications to simply "appear" to be unique), but this is absolutely progress in the right direction.
In general, I think what you'll find is that ACT 6.0 gets you refocused on application compatibility as a risk management activity. Instead of fighting you and trying to give you big lists, showing you data because it can and not because it should, the product now tries to help you sort out data, and give you information that you can take action on. It's still just a tool, and my number one piece of advice to customers who are migrating to a new platform is to build out your process first and map tools to that process second. Having this toolset now slide in much more naturally is a big win for me and for other folks who are driving application compatibility to help customers both complete their operating system migrations more quickly and exit the process as a more agile organization.
Chris "The App Compat Guy" Jackson is a Principal Consultant and the worldwide lead for application compatibility at Microsoft, specializing in Windows, Internet Explorer, and Office internals. Jackson is a widely recognized expert in the field of application compatibility, creating technical documentation, training, and service offerings used inside and outside of Microsoft and based on years of real-world experience with enterprise customers and independent software vendors. Author or co-author of numerous technical papers and articles, he is also a featured speaker at major industry conferences around the world and publishes a popular blog.