Software approval processes in large organizations

Solution 1:

I'm part of the Software Approvals Group for a multi-national company and I would absolutely echo everything Adam says above.

I'd also make the following points, firstly always pay all of your "development taxes". This means making sure that your app works properly in a whole variety of environments that you may not ever use, but will very likely be deal-breakers for large companies, these are things like making sure that your app works well with roaming user profiles and redirected user folders (always use Windows APIs to find user and profile folders, don't ever assume they're at standard locations, or even on the local drive), making sure it plays well on Remote Desktop servers (where there might be a 100 copies of your app running at once, some using very slow connections), on laptops with slow network connections or low batteries and so on. As an example we recently rejected new versions of more than one piece of software from a very large company (starts with "A" and is famous for graphics) because their apps suddenly don't work with redirected home folders in the latest versions, this is a deal breaker for us.

Even for free/open source software, end users often have to submit some kind of request form to have the software verified and approved.

By the tone of your comment it sounds like you think the approval process has something to do with cost? From our point of view per-unit cost of an app isn't something we'd consider at all in the approval process. Financial justifications for apps will have been worked out, software approvals is all done from the technical and support-ability angle. Free and Open Source software generally has more trouble getting through our process than a proprietary commercial app. Often this is simply down to the lack of accountability. Who do you go to when there are problems with the app and you need support, what's their SLA? Who do you ask when you need to find out if the app will work with a new version of OtherApp v.X, are they really giving you an actual answer that people are really working towards, or is this a vague "someone in the community may do it" answer?

Once the process has been followed and the software is installed, upgrades can be troublesome - many organizations tend to stick with older versions of software (Windows XP, Office 2003, etc.) for fear of unknown issues.

Software upgrades have to go through the same process as totally new pieces of software do. The only advantage they have is that we'll already know the answers to some of the questions as we've already been supporting the software (this may not be a positive for the software, support teams have veto'd upgrades based on experience with the company).

Do you prefer MSI's or xcopy-able software?

Either of those deployment methods can be good, as long as they've been packaged properly. Otherwise we're quite likely to rip out your installer and repackage the software for deployment ourselves.

• Whatever installer you use, you must make sure that you respect all of its silent, unattended install modes. If your app requires a manual install, that is an instant deal breaker, there simply is no practical way to do that across machines on 5 continents that get all non-hardware support from a central office.
• Given the choice I'd prefer a well done MSI install to a well done xcopy install. The problem with most Xcopy-able pieces of software is when they try to setup and register themselves on first-run. I have very rarely found an app that does this properly and doesn't cause problems in a roaming user/hotdesk environment. MSI installers (if you stick to the standard API) aren't able to go too far wrong.
• Make sure that your silent install gives the ability to make all configuration changes that can be made in a manual install. If you're using MSI and sticking to the API then this is fine, we can make MST transforms and do all this no problem. If you're using a different third party installer, then make sure it allows something like an "answer" file or an INI file or similar. Test the silent install and make sure all the options work, I've come across products that gleefully announce their silent install options, but they've never actually tested if all the options work.
• Preferably give us extra options in the silent install that let us set a lot of the settings that a user would normally change in the Options panel. This could be by switches on the setup.exe, could be by having a documented INI file for the settings, by documenting the necessary registry changes, or all of the above. However it's done, we'd like to make sure that our users can get up and running with the software without having to do any configuration themselves, important ones here are default locations for files, default server names, proxy settings (if your app runs over a network), etc.

If the software requires frameworks (Java, .NET) is that more or less likely to be problematic?

It's definitely more problematic. Versioning in most frameworks and backwards/forwards compatibility is atrocious. With Java in particular many apps (and websites) require a particular major and minor version of Java installed and won't work with anything else. If you need to put three different apps on a machine that all need different versions of Java, and they're not happy with the standard ways of cloaking one Java version as another, then there will be problems. .Net has its own problems with versioning, but will happily let you install all major versions of the framework at the same time which gets around a lot of these.

If the software supports automatic updates, do you generally allow this?

Never. There are far too many versioning and inter-operability headaches to ever allow an app to update itself without any warning. App upgrades take testing and planning. Also users with normal user rights can't apply the updates anyway. If you use a deployment method that allows patching (eg use MSIs with MSP patches) then this can make things like security patching for apps far less of a headache, and we can manage the auto-updating ourselves using our deployment tools (WSUS and SMS). Also our security team are very suspicious of any app that "talks back to base", they like to know exactly what info it's sending and exactly why it needs to send anything to an unknown server over the internet.

How long does it generally take?

Some simple apps, and version upgrades can be decided in as long as it takes 6 people to click an "Approve" voting button in Outlook. More complex or controversial ones may wait for our group meeting every two weeks. Some apps may be talked about at more than one of these meetings as teams take questions about an app away and research/test.

What kind of licensing models do you prefer (transferable, per-seat, per-CPU, site-wide)?

Totally depends on how the app is going to be used, and by how many people. The most important thing is that your licensing is clearly defined. We have to send our people on (albeit free) courses to understand Microsoft licensing. We're not going to bother doing that for an ISV.

Consider our silent, automated install needs when it comes to licensing. If your licenses need activation we don't want to have to ring/email you every time we reinstall an app on a PC. If every copy of the app needs a separate, different license key typed in, then we can't deploy that automatically, whereas if we can buy a bulk (2, 10, 50, 500, etc seats) key that can be saved in the silent install, then we're happy. It's even better if we can go back to you a year later and negotiate to expand our number of licenses without having to change the key that's typed into the software.

What else can ISV's do to improve their chances of having their software approved?

We'll also look at things that aren't strictly related to how your app is at the moment. Bearing in mind that if your app becomes part of the standard workflow for one of our areas it might be used for 10 years or more, so what does your product's roadmap look like? If you don't support the latest brand-new or in development version of Windows yet, do you have a plan for when you will? Does it look like you stick to these roadmaps? Does it look like you have any plans for drastic changes to your app, either the way it works or the technologies/frameworks it uses? Does your app plug into any other apps, eg MS Office or IE, if so how tolerant is it of older or newer versions of those?

Solution 2:

We're quite a small organization, but moved to standard desktops and approved software to reduce our admin hassle.

Do you prefer MSI's or xcopy-able software?

Anything which can perform a "silent" install. MSI's generally work well here, but lots of installer software is fine too. If we have to configure it in some way then it's good to be able to script that too, either by xcopy-ing files or registry merging.

If the software requires frameworks (Java, .NET) is that more or less likely to be problematic?

It can be problematic because of the different version requirements. If you need .NET 3.5 and we're using 3.0 then we have to manage that upgrade and ensure it doesn't break anything else.

If the software supports automatic updates, do you generally allow this?

No. Too much risk of the new version causing issues. Also, users don't have Administrator rights so updates usually don't work anyway.

How long does it generally take?

If there's a pressing business need, as quickly as possible - as little as a few hours. For more awkward software, maybe a week or more.

What kind of licensing models do you prefer (transferable, per-seat, per-CPU, site-wide)?

The cheaper the better! We can deal with most reasonable options, but it gets hard if the software does any kind of automated checking or requires activation. These don't tend to deal well with dead PCs, failed activations etc., and generally make extra work for us.

What else can ISV's do to improve their chances of having their software approved?

Two things spring to mind:

• Consider the difference between the machine (Program Files or HKLM) and the user profile (or HKCU) when storing settings. If you do this right then I won't have to sorry about it.
• Document installation, settings and licensing details clearly either on your website or in your software documentation. It's much easier to follow a "deployment guide" than to try and figure it out for myself.

And of course you have to make software worth using in the first place - if the user really loves it, they're going to shout louder to get it approved!