Software development is a process, not an event. Having said that, from time to time, we have an event. The release of a new version of software is such an event. The software development process, however, continues. The decision as to where to draw the line to separate one release from another is a complex interaction of competing goals. The Marketing folks are trying to keep up with the competitive feature package from another vendor. The support team desperately needs a patch for a nasty unforeseen system configuration that introduces an undesirable result and the software team has an aggressive agenda of its own making.
The list of new feature demands is unending. Driven in part by user requests, marketing objectives and the pressures of other vendor releases. If your product is built on Microsoft, clearly you are under pressure to stay compatible with any new releases they might make available to the market. In fact, as it relates to ShoreTel, many people were seeking Windows 7 support when what they really want is Microsoft Office 2010 support! Was it 64 bit desktop computers or 64 bit server software that the market demanded? Do we do the Apple IPhone? Is that web based Communicator really needed in this release or can it wait? Fixing the release of new features is one of the most challenging business decisions that companies have to make.
Generally companies try for two DOT releases per year and one major new release every year. For ShoreTel, we generally expect a DOT one and a DOT two release. For example we might have a Version 10.1 in general availability (GA) while we are beta testing a major release like 11.0. We move to a GA release with the DOT and 11.0 becomes 11.1 available to all. Currently, as of this post, ShoreTel is in GA on Version 11.1 while beta testing Version 12.0. The GA Version of ShoreTel 11.1 has a host of exciting new features, but architecturally we are most interest in 64 bit server support; virtualization, Windows 7 Support, browser based Communicator and distributed Databases. Version 12 completes the Microsoft compatibility by supporting Outlook 2010.
Distributed Workgroups was made available in Version 10, which enables the continued operation of Workgroups on a distributed voice mail server (DVM) even if the HQ server failed. This has some attractive options, but having an operating workgroup might be limited by an inability to have users log in or out of the workgroup. Version 11 enables distributed database capability. This means that in the absence of a HQ (e.g. read/write database) server, a user on a DVM could change their call handling mode; or a change in schedule from Off-Hours to On-Hours could be effected. You have to chose one over the other and I would encourage you to choose the distributed database. Best practice dictates that a Workgroup should be backed up by a Hunt Group that contains all the agents who make up the Workgroup. In this way a failure of the Workgroup, still provides a call flow that reaches all Agents. A distributed database, in my humble opinion, has higher impact. IN a multi-site deployment, you will want to change call handling modes even if the HQ server is down. This combined with a backup hunt group, gets the job done more effectively.
The browser based Call Manger is yet another power new feature capability. Now all those MAC users have an option! I suspect that more and more call control will be built into browsers limiting our dependency on the various O/S issues. Who cares if we support Windows 9 as long as we have a browser option!