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.
Related posts:
If you liked this, click here to receive new posts in a reader.
You should also follow me on Twitter here.
Comments on this entry are closed.
{ 2 comments }
> 3. Everything is standardized This isn’t always true. I work with enterprise AD environments for several large organizations and I’ve never come across one that’s easy to program for. The easiest networks to work with are large school districts which rival enterprise AD systems. These school districts tend to be organized and programmable. The database information can be easily keyed to the OU location. The problem I run into with companies is they don’t really know the systems and they won’t change it no matter how much you tell them it needs to change. You begin to program for exceptions rather than rules.
This comment was originally posted on Reddit
> they don’t really know the systems and they won’t change it This is a great observation. This definitely happens in companies, and the effects are amplified in big companies. Keeping the business running is priority number #1 for the IT department. They really think twice before changing anything, especially if they don’t exactly know what the system-wide dependencies are. What depends on the LDAP schema? What breaks if we change it? Nobody knows… "Everything is standardized" refers mostly to the software installed on machines, which is what the paragraph talks about. When I said "everything", I didn’t really mean*everything*. Ahem :)
This comment was originally posted on Reddit