Technical Architecture

Not Just a Matter for IT

It's important to define the technical requirements for the tool so you don't find yourself with a tool that simply cannot function properly within the technical infrastructure of your organization. Clearly, defining the technical requirements is going to require much input from the IT group. However, it's easy to focus too much on the technical side and to forget the business implications of the technical choices. This is where a strong IT owner can orchestrate the contributions of the various technical staffers while adding the proper amount of business acumen and strategic thinking. The IT owner's contribution is essential in at least three ways:

  • The technical staffers may focus only on "cool" technology and prefer the leading edge, which they see as more fun and better for their resume. In fact, established technology may be a better choice for the organization if it combines a lower risk with "good enough" technical power. Note that the IT owner may have the same weakness!
  • The technical staffers may be unaware of the longer-term goals for IT. While the CRM project must be grounded in the present reality, it also needs to fit within the future framework. The IT owner should be able to bring that knowledge to the team. Also, it may be appropriate to accelerate some IT initiatives to accommodate the project. This kind of decision-making responsibility needs to be done at the IT executive level, by or through the IT owner.
  • Finally, there are occasions when the CRM project will trigger objections and changes to the IT infrastructure model. This is where an experienced IT owner will really shine. First, the IT owner should be able to recognize whether the technical requirements are inappropriately preventing a reasonable business choice for the CRM system, as opposed to reasonable technical requirements placing reasonable limits on the business choices. For example, if none of the good CRM systems out there run on the particular operating system that you support, perhaps your supported list needs changing. On the other hand, if only some CRM systems fail to support your preferred operating system, it's probably fine to just eliminate them from consideration.

    If the CRM project triggers revisiting the corporate IT strategy, the IT owner should have the wherewithal to drive the decisions required to make changes through the organization, and to do so quickly enough to avoid delays to the project.

The technical architecture area is one where asking all the team members to review all the requirements yields plenty of benefits for teamwork. If the business owners can understand why the technical requirements are restrictive, and if they can be convinced that the restrictions make sense, they will be more open to discarding some otherwise tempting candidates that do not include appropriate technical requirements.

Technical Requirements

Technical requirements include the technical platform, scalability, integration capabilities, and the all-important development environment. If you are a business owner and you're tempted to skip this section, try to read on: you should be able to follow the description easily and it will help you understand what your IT counterparts are concerned with.

  • Technical platform. It's usually best if the CRM system can conform to established standards within the organization, including hardware, operating systems, database, web servers, etc.

    Standards are useful in two ways. First, they capture some level of tested and approved quality. The organization believes that the standards that were chosen allow it to function properly; inferior solutions are not included in the standard platforms. Second, there's a great advantage to minimizing the number of competing technologies being supported at any one time because it is so much easier to maintain staff and training to handle a few different technologies as opposed to many different ones. So this is about simplifying the IT universe rather than keeping out inferior solutions.

    Would you consider adding platforms and protocols to the list of standards as part of the CRM project? If so, are there any restrictions to what you would accept? Most organizations strongly prefer or mandate open standards, for instance.

    One important aspect of the technical platform is whether the tool offers a thick client or a thin client. Older tools were built with a client/server model, in which client software must be loaded onto each user's machine and performs significant tasks for the user. That software is the client in client/server and is now often called a thick client. In contrast, newer tools can usually be run with a thin client, which handles only the user interface and the navigation, not the business logic. It is very lightweight and usually (though not always) embodied in a web browser. Web-based clients are much easier to deploy, since there's less need to fiddle with each user's machine. You may need to use a particular web browser, or to set up specific options in the web browser. Thick clients, on the other hand, can pack lots of processing power into the clients, thereby allowing faster processing, and they offer a richer set of widgets (drop-down menus, buttons, automated charts, clickable graphics, etc.). Of course, some type of thick client is required if users must interact with the system without a connection to the network, for instance, field sales reps using the system offline.

    Carefully qualify your requirements for thin clients if you decide to go that route. Most vendors require specific browsers, specific versions of the browsers, and large amounts of memory, which may require checking, configuring, or even upgrading each machine to ensure that it meets the requirements. That can mean a lot of work, especially if your users are not sophisticated and cannot do it themselves. Also, some vendors require significant downloads, either during the first session with the tool on a given machine, or every time the user logs on. That process would have an impact on usability and should be noted in the requirements. Finally, vendors that offer both thin and thick clients may offer only a subset of functionality through the thin client, so make sure your requirements specify what functions should be available through the thin client.

  • Scalability. This has to do with whether the tool can support the number of users you need to serve, and how well it can adapt to serving larger numbers of users. Scalability is of course a very important issue, but make sure to use reasonable scenarios in your evaluations. One of my clients spent months and lots of IT cycles to conduct large-scale trials to determine whether a particular tool could support ten times its current number of users, only to find out that the grandiose user projections never came close to being met. In this area as with other areas in the requirements, it's best to stay within a reasonable timeframe of a few years' time. Who knows what you will need and what software you will require in five or ten years?

    Starting with the number of users you need to support today, use a two-year projection. Consider where the users are located. If everyone is a LAN connection away from the server, life will probably be pretty good. If your users are dispersed, then you need to specify that in the requirements. High-end tools typically provide a three-tier architecture to support a large number of dispersed users, through which the thin clients on the desktops interact with an app server, or one of many app servers used for distributed processing or for redundancy. The app servers then interact with a database server. While your requirements should describe the business requirements (support X number of users located in Y areas) rather than dictate a particular architecture, it's likely that the IT owner will like to see a three-tier architecture.

  • Availability. Availability refers to the ability of a system to continue to perform despite underlying failures. Is it critical that the tool be available at all times, even in the event of something like a database failure? If that's the case then the tool should support continuous synchronization with backup servers to minimize downtime. What kind of clustering does the tool support? Is it compatible with the existing IT infrastructure?

    As you make your decisions about the availability requirements, keep in mind that high-availability is complex and expensive, and may not be worthwhile in all situations. Because of the complexity, high availability may be a good candidate for a second phase. High availability is expensive, not only because you need to purchase and set up much more hardware and software, but also because it slows down processing time, which may be more expensive than anything else. Don't blindly check off the high-availability requirement without fully considering your options. It would be a shame to disqualify candidates that would otherwise provide a good fit just because they don't have high-availability features you may never exploit.

    If some amount of down time is acceptable if the system crashes and therefore you decide to forgo a high-availability strategy, you still need a viable backup and recovery component to get the system back up after a crash. Make sure that the tool provides an acceptable recovery strategy.

  • Integration. Unless you are looking for a small, isolated system, you will need to integrate the CRM tool with other tools within the organization. The tools may be already in existence (such as your accounting system). They may be acquired concurrently with the CRM tool as part of the CRM project (for instance, a computer-telephony interface for the phone switch), or they may appear later as part of a separate project (for example, an analytics system).

    Specifying the integration requirements for the tools that are currently in existence is easiest, although the level of integration required is rarely obvious at the time of the requirements definition and may demand a detailed analysis later in the cycle to make a good decision. The requirements for future tools are even more challenging.

    If you anticipate tight integration requirements, you will want to require a fully defined API (app coding interface). It's best if the API is based on industry standards and allows access to all the objects within the tool, but you will find that some APIs are proprietary or only allow partial access. Especially if future integration needs are unknown, you would have the most leeway with a standard API and an exposed data model.

    For the integrations you are planning, it's a good idea to require production references. It's true that each integration is custom, but the fact that other customers managed to make it work bodes well for your success. You should get more details on what was done from the individuals who created the integration to get a full picture of what is required.

    Many CRM vendors have established partnerships with the vendors of tools that are often integrated with theirs. Partnerships are great, but be sure to fully evaluate the depth of the partnership during the evaluation phase. You presumably need partners that have accomplished more than merely paying a fee to be listed as partners.

  • Development environment. Unless you are considering a very simple tool, you can expect to have to make some customizations, and therefore you will need a development environment. Development environments can be the neglected stepchildren of CRM systems, so make sure you define and later evaluate your requirements in that area.

    You may need to modify the data model, the workflows, and the screens, so consider development facilities for all three areas. Wherever possible, prefer widely-used standards to proprietary toolkits. Older tools often require the use of little-known scripting utilities that require specially trained staff and are not useful outside that particular context, while newer tools may offer easier-to-use, but sometimes less powerful screen-driven tools.

    Consider that in most instances you will have separate systems for development, testing, and production. Cleanly migrating changes from one environment to another is critical, and yet few tools offer any robust assistance in this area.