Building software for enterprise customers is a very different experience from building software for home users, for example. If you’re working for a small software company, it can be sometimes difficult to understand how big corporations work. Here are some tips based on my experience. Hopefully, these are helpful in figuring out how enterprise customers change some of the expectations for your software.
1. Enterprises are big on policy
There is a policy for everything. Even though policies are usually defined in good faith, from the perspective of an individual employee policies are about compliance and not common sense. So sometimes, a policy will be the only reason which prevents your software from being used, or prevents it from from being configured in the way which would make the most sense. Don’t fight the policy windmill. Work around it.
2. Enterprises have long deployment cycles
It takes ages for big companies to move to new releases. As a case in point, think of Internet Explorer 6. It’s an ancient browser but still widely used. The last holdouts for IE6 tend to be corporations where IE6 is company policy. The lesson for your software: you may need to support and interoperate with very old products and technologies.
3. Everything is standardized
Big corporations like to standardize their operations. For software, this usually means that some part of the IT organization defines standard “builds” of operating systems. The build locks down the operating system, the OS version, applications, and their configurations. All new boxes are installed with a standard build. In order to be included in the standard build, your software must have no required setup steps after installation. Your configuration files, for example, should be designed so that the same exact configuration can be used on multiple hosts.
4. Prepare to integrate
The IT infrastructure in every big company will have a number of systems your software may need to integrate with. Possible candidates for integration could be identity management systems (Active Domain, LDAP, NIS+) , single sign-on systems, content management systems, CRM, and so on. You must design your software so you can integrate with everything and anything that makes sense for your application domain. If your software requires user accounts to be created and maintained separately, don’t expect a bank to buy it.
5. Prepare to port
The largest companies have huge global IT environments. They have acquired other companies. Semi-independent subsidiaries have been running their IT operations in different ways for years. This means that there will almost always be a number of various operating systems in use throughout the organization. There’s Windows on the desktops and maybe on some servers as well. There is usually a substantial number of servers running some flavor of UNIX: AIX, HP-UX, Linux, or Solaris. In the banking world, there will be AS/400 or z/OS mainframes, or both. Rarely, there are some Macs in desktop use as well.
Depending on the nature of your software, you may need to support a number of platforms. If you’re lucky, it’s only going to be a couple of different UNIX. In the worst case, you have to port your code to Windows, all the UNIX, plus the mainframe as well.
6. Prepare to release patches
Due to the large deployments, standardized builds, and dependencies to other software, you will be hard pressed to deliver fixes to problems by offering the fixes in the latest version. Usually there are policies which allow for a lightweight validation process for patches but require a larger project for a new release in fear of regressions (and rightfully so). Prepare to deliver patches, or minimal changes in some other way, so your customers can get the fixes they need and only the fixes they need.