Integrating Third-Party Software
In some ways, integrating an externally produced software product is more challenging than building a homegrown product. Even if the product is designed specifically for your industry niche, there will be features that you wish that you had, and you also will be paying for features you don’t need.
You are going to have to pay software development money to customize and configure the software for your environment. And your organization will need to invest in time and training to reshape its processes to fit the paradigm and limitations of the new software platform.
A good software integration project can save the company huge amounts of money and dramatically improve the company’s efficiency and competitive profile. A bad integration project can bleed a company dry. Do everything in your power to make your integration project a success.
Note A package that is intended to fill a core business requirement should not be selected by the technology staff. The decision to seek a solution and the selection of a third-party vendor must be driven by business needs. The evaluation and selection process needs to be owned by a key business stakeholder, and the process must include input from representatives of the directly affected groups.
Before you invest in a supplier’s product, examine what is in the marketplace. Search the web for review articles about the type of software you are interested in. Then search the web for each of the software vendors mentioned in the review articles.
At each step, look at each vendor’s information to see which other vendors they compare themselves to. Then search out those vendors’ information too.
During this information search, you will be deluged with information. You need to structure the information you gather, otherwise you will start confusing which vendor has what feature set and what type of reviews. For each vendor, track the following information in your research documents:
- Vendor name and product name.
- Links to the company and product web pages.
- Sales representative and sales engineer contact information.
- Feature set, especially the features relevant to your organization.
- Summarize the sense of the online reviews and comments you find about the software.
- Links to the most relevant or interesting online reviews.
- Pricing information (including maintenance cost information, preferably going out at least five years).
- Information about the frequency of updates and patches.
- Information about the amount of effort required to upgrade or patch the software.
- Training information and links. Are there free online courses? Are training credits offered with the purchase?
- People within your organization who have experience or expertise with the software.
- People in your community (including online contacts) who have information or experience with the software.
- Information about and introductions to vendor user groups. These groups are good forums for learning about new product developments, as well as advocating for new features or fixes to issues.
EVALUATION SCORECARD
As part of the evaluation process, create a scorecard. The scorecard should include entries for significant areas such as purchase and maintenance costs, as well as key business and functional requirements.
These requirements should include information security, audit, or compliance requirements.
The software should be considered as a part of your business’s ecosystem, existing processes, and culture, and should be scored accordingly.
Each requirement should be weighted according to its importance, as specified by the key stakeholders, and scores should be assigned. This scorecard will be an important part of getting key stakeholders to coalesce around a consensus solution.
A rookie mistake is to assume that you can keep all this information in your head, or that you can easily search the information out on the web as needed. Don’t fall into this trap. I can guarantee that there will be some crisis that will emerge when you are in the middle of the search, and when you come back to the search, you will kick yourself for not collecting and organizing your previous search results.
CLOUD-BASED SOLUTIONS
One decision you will need to make is whether your solution will be implemented in-house, or in the cloud.
The “cloud” is a generic term describing solutions that are housed by a vendor and accessed over a remote network connection. There are several different varieties of cloud-based solutions:
- IAAS : Infrastructure As A Service. This sort of vendor provides a location where virtual servers and storage are available to run the customer’s applications.
- PAAS : Platform As A Service. Platform vendors typically go one step beyond IAAS vendors. With a PAAS vendor, you will typically get an operating system and program execution environment. Frequently, this will include database, web server, and application layer environments available for running custom-written code.
- SAAS : Software As A Service: SAAS vendors typically provide the entire software environment to customers. The advantage is speed to deployment and ease of administration, but vendor lock-in is much more of a concern than it is with IAAS or PAAS.
(Some definitions also include Network As A Service (NAAS), which outsources the responsibility for the network connections between different components in the cloud.)
The main advantages of a cloud model are:
- Cost: Cloud solutions are typically much cheaper than traditional alternatives.
- Speed: It is almost always faster to deploy to a dedicated cloud environment than to build out your own system.
- Flexibility: Because the deployment costs are usually lower, there are fewer sunk costs and lower barriers to entry to consider for new upgrades.
- Easier maintenance: Maintenance belongs to the cloud vendor, removing an important distraction that you would otherwise have to plan around.
There are some disadvantages to a cloud model as well:
- Loss of control: You can have any flavor you want, as long as it is vanilla. Your vendor decides what options to make available.
- Integration: Integrating the vendor’s software into your environment may be challenging, in part because a lot of vendors’ products aren’t designed to be interoperable.
- Lock-in: Your future becomes tied to the future of your vendor. Especially with SAAS, migrations become difficult.
- Performance: Depending on the solution, the performance may or may not be better, but it will certainly depend on the quality of your network connection.
- Security: Similarly, the level of security available is determined by what your vendor makes available.
In the end, you have to weigh your options and do what is right for your employer.
Research alone will not give you enough information to select a third-party software vendor. If this is a large investment or is a strategic component of your company’s business operation, then you will need to go further to ensure that you are making the correct decision.
You can sometimes use the application for a period of time in a “lab”-type setting. This approach is often referred to as a proof of concept (POC) or a proof of implementation (POI). You will need to create a short list of vendors based on the research, demos, and the results of reviewing the responses to requests for information (RFI) and requests for proposal (RFP).
You will need to plan and work with each vendor to engage in a small but meaningful proof of concept. The goals of the POC should consider all aspects of the vendor package that are relevant to your company, which may include the following:
- Use cases that are important to your business users.
- Validation of all integration points with your technology and applications. The vendor may offer several ways to integrate with your internal applications, so you will want to try to use and compare each method.
- Agreement on how the vendor package will be deployed to your production environment to ensure compliance with your company’s release management and deployment process.
- Verification that the package will not conflict with your company’s information security or data center policies.
- Specifications for how the vendor package should be monitored, and what tools and mechanisms are available to do troubleshooting.
- Experience using the vendor’s customer service and support.
When you select a third-party software vendor, you are making an investment in that company. You will invest significant amounts of money deploying and customizing the software to your organization. Then the people in your organization will spend significant amounts of time adapting their daily workflows and processes to use the software. If the software company or product line disappears, you will have an expensive piece of legacy software that will be difficult to replace.
Investigate the company as if you were going to buy stock in it. Look up financial reports and online analyses of the health of the company. Search the web for information about the company and its place in the competitive marketplace.
Who are the company’s main competitors? Is there some likelihood that the company will be acquired? If it is, how likely is your target software package to survive the merger? What are the track records of likely merger partners?
Do the same for the software package. Sometimes companies end up with two or more software packages that play in the same marketplaces. Look into the possibility that your target software package might disappear from the marketplace. If that happens, what would you do for support? Patches? User communities? Consultants and experts?
More than one company has invested in integrating a software package, only to have the software package become an orphan. Do whatever you can to avoid becoming a statistic.
Negotiate pricing relentlessly. Point out the features that you don’t plan on using, and ask why you should pay for them. And point out the features gap. Ask when that feature will be implemented. Ask what the process is for requests for enhancement (RFEs). If possible, get it in writing. And then bargain the price down based on the risk you are taking on the vendor.
Secure proposals from more than one company in the marketplace. Look at the strengths and weaknesses of each proposal. Then discuss these strengths and weaknesses with each of the vendors. Make them sell you their product; part of that is to get the best possible pricing for your company.
The top-line price is not the only cost you should take into account. Take into account the costs of integrating the software, supporting it, updating it, training your staff, and deploying it to your user community.
Frequently you can get credits from the vendor for many of these costs. Look for training credits, or hours from the vendor’s consulting arm. Negotiate for years of maintenance bundled in, or at least for not-to-exceed pricing for support at the original discount rate. You will never have as much leverage as you will have prior to signing the deal; you owe it to your employer to extract maximum value. And get everything in writing.
Don’t let yourself be swayed by personal attachments to sales reps. Judge the product on the technical merits, including the costs and opportunities at all stages of the product’s life cycle.
REVENUE SHARING
Another way to fund the purchase of a vendor package and support is to negotiate a revenue sharing arrangement. This is not always an option depending on your business, but it has many benefits. In this scenario, you are offering the vendor to put “skin in the game” in return for sharing in the revenue achieved with a successful implementation and long-term stability and performance of the application.
It is important to make sure that the service level agreement (SLA) includes penalties in which revenue sharing payments are held back for breaches of the SLA. In this arrangement, it is in the vendor’s best interest to deliver versions of their application on time and with high quality.
No matter how friendly the sales reps and sales engineers are, they are in business to take as much of your company’s money as possible. Your job is to maximize value for every dollar of your company’s money.
Your legal agreement with the vendor should include penalties for failure to perform. Use your leverage to add enforcement language to the agreements with the vendor to deal with nonperformance or failure to meet agreed-on targets.
When there are problems, raise them with your vendor. Be clear. Be definite. Pull out the paperwork and emails, and show them where the vendor has failed to meet its commitments. Negotiate to have the problems fixed, promised features added, and to get compensation for shortcomings in the vendor’s deliverables.
You don’t have to be a jerk, and you don’t have to get angry. In fact, you will be more effective if you keep your temper and stay businesslike. State your case clearly, cogently, and effectively. And demand that the vendor produce the results you thought you were getting when you purchased the software.
There are several types of support you need from your vendor. At a bare minimum, you need the ability to find out about the product and get help fixing the problems that emerge. Here is a quick list of some types of support you need from your vendor:
- Information on new products and features.
- Methods for communicating problems and enhancement requests to engineering.
- Break-fix support.
- Integration support.
- Links to experts or consultants.
- Access to a user community.
Some vendors spend significant resources developing an ecosystem surrounding a product. These communities of users and vendors can be invaluable in resolving problems, recruiting support staff, and identifying consultants for short-term projects.
Have a phone number of a specific person at the vendor whose job it is to keep your company happy. Then be clear about your expectations and demand excellence.
Before bringing a software product into the environment, you need a clear understanding of how the product will fit into your environment. What value do you expect to see? What functions will it fill?
Talk to other customers, and verify that the software is capable of what you need. Find out how much effort is required to customize the software for your environment, then estimate the costs associated with that effort. The development costs are part of the project budget for the overall integration, so they have to be included in your proposal to management.
Once you start integration, treat it like any other software development project.
Success starts with your sponsor’s buy-in on clear requirement statements. Translate the requirements to clear functional specifications, and develop a test suite to validate the results.
The fundamentals of a software integration project are the same as for a blank-slate development project. Identify the business need, design a way to fill the need, and then execute the design in a timely, professional way.
The business needs to own the selection process and be a key part of specifying, procuring, and testing the application during the deployment process. That will help avoid a mentality where there is an expectation will be that a purchased software product will just work. For anything more complicated than an office productivity suite, that expectation is poison.
The conversion from the existing application to the new package needs to anticipate the following:
- What existing data needs to be transferred (and often transformed) to the new platform? This data may come from anywhere in the organization. Some applications calculate data on the fly without storing it in the database. You will need to figure out how this data will be seeded in the new platform since it may not actually be stored in the legacy platform.
- How will users validate that the new platform is correct when the cutover is performed? This is often an afterthought that usually requires the application development team to provide (build) onetime utilities. Typical issues include automating and streamlining validation by the users, frequently by comparing outputs/data between the old and new platforms.
- Any large implementation should plan to include several mock or trial conversions. This is needed to fine tune the detailed steps leading up to the actual conversion/cutover. Understand and optimize the time needed to execute the detailed steps in this process. Remember, you will need to be able to complete the deployment and conversion (usually on a weekend) and have time to do the checkout and fail back in the event the cutover or conversion fails.
- The team needs to start planning early on the approach to be used for implementing the new platform. Will it be a big bang or be done in phases? Will there be a pilot period in which a small set of business groups and users process a subset of the business in production prior to cutting over the rest of the business?
If the stakeholder communities have been intimately involved in the selection, proof of concept, deployment, and testing process, a lot of issues around end-user training will be apparent long before cutover day. Track issues that appear during testing, and keep them in mind for the rollout of the application. The more people you can involve in the POC and testing phases, the less of an issue this will be.
The user-training program is an essential part of a deployment. If people don’t use the product because they don’t know how, you have wasted your time and your employer’s money.
Appropriate training will depend on the nature of the software. It may include documentation with step-by-step instructions and screenshots, it may include presentations, and it may include formal classroom training.
The success of your training program will be measured by your target audience, not your developers. Test your training program on a small group of end-users, and find out whether it was effective. Have them explain the material back to you.
Eventually, a software product will need to be replaced. It may be that the package has reached the end of its support life. Sometimes an old package no longer fits in an ecosystem dominated by another product. And sometimes a package has been a complete disappointment.
When it comes time to replace a product, first understand what valuable functions it is fulfilling in the environment. If the proposed replacement products do not share all the required functionality, find ways to fill the gaps.
The entrenched product has the advantage of familiarity, whatever its disadvantages. Your training program will be the key to overcoming this advantage as far as possible. Planning the resources for training is more important in a replacement situation than in a blank-slate situation.
When selecting the replacement, take a clear-eyed look at the strengths and weaknesses of the proposed packages, including the integration costs. You may find that the best alternative is the software package that is already in place.
Summary
Third-party software can be the best way to provide needed functionality to your business. This will only be the case if you can deliver the software, fully integrated, on time, and within budget.
Understand the requirements, both functional and budgetary. Consider the alternatives. Extract maximum value from your vendor. Train your users. Deliver value to your employer.
Discussion Questions
- Think about a software integration project you have observed. What aspects of the deployment were successful or unsuccessful?
- Consider someone who is trying to sell software into your organization. What do you need from that sales rep to be successful? What does the sales rep need from your organization?