Introduction

You’ve built an exciting smart hardware solution that is starting to grow rapidly and produce the results that you have worked hard to achieve. Today, the business is built around a set of smart, custom hardware solutions that operate in unattended environments. While you are confident in the ability of the business to scale with a growing customer base, you are now considering how you will manage and monitor the growing fleet of devices.

For many businesses that operate a fleet of devices, the implementation of remote monitoring and management (RMM) of their growing fleet is one of the first “crises” that the business faces – as the size of the fleet grows, it becomes increasingly less cost-effective to manage with simple remote desktop solutions and more customer service representatives. It is often also the subject of the age-old debate, “build vs. buy”. You may have a development team, or partner focused on building your core product – what would it look like to have that team take on the build out of the RMM aspects of your product? How does that compare to purchasing a RMM solution to meet those needs?

In this article, we’ll explore the three typical stages of either the “build” or “buy” journey:

• Part 1: How do I get started?
• Part 2: How do I deploy the solution?
• Part 3: How do I operate the solution?
• Part 4: How do I evaluate the costs of each?

‍

‍

Part 1: Getting Started

‍Building an RMM – Getting Started

If you’re considering building your own RMM, you will likely already have dedicated development resources, either internally or via a trusted partner (if not, you should skip to the “Buy” sections as “Build” will require extensive software development skills). 

You will want to carve out part of the development team to focus on building your RMM and have them collaborate with the business stakeholders to set product requirements. The team should consist of resources from the following areas of expertise:

• Product Management: Sets overall goals and definition of the RMM MVP. 
• Development Leads and/or Architecture and Design: Translates the goals into technology designs and makes supporting technology decisions.
• Project Management: Builds project timelines and manages the technical team against them.
• Operations: Will be responsible for deploying the solution and the management and monitoring of the fleet that your RMM should enable.
• Customer Support: Ultimate end-users of the RMM tool that are engaged in day-to-day remote support of devices.
• Other Business Functions: Input related to how collected data can inform the future direction of the product and business (i.e., Product, Sales, or Marketing).

Once your team is assembled, you should begin building feature requirements for the RMM solution. Some core areas that should be considered include:

• Collecting data: What device data exists today? Are new data points needed to effectively monitor/manage the solution? How will you collect data from the device?
• Data transmission: How will data flow from the device to the centralized RMM to be monitored? How will you deal with offline situations?
• Data reception: How will data be received in the centralized RMM? How will you authenticate and authorize transmission? How is data distributed to downstream systems after reception?
• Visualization: What visualizations are needed? What kind of device reporting is required?
• Alerting: What notifications should be produced? How will they be distributed? Will a ticketing system need to be integrated?
• Taking Action: What remote actions should your RMM be able to trigger? How will it communicate them to the device? What security measures should be in place to prevent accidental or malicious misuse? How will you automate business processes to maximize uptime?

Finally, you will also need to make key some technology and solution architecture decisions:

• Frameworks: What frameworks are you going to use to support the development? You may need to make one decision on the device-side technology and a different one for the centralized management solution. What Open Source and other packaged development frameworks will support the effort? How will you manage any licensing implications?
• Dev Ops: What parts of the solution will you manage internally, and what parts will use a managed service for? For example, will you set up your own database or look for a managed solution provided by AWS, Azure, Elastic, or others?
• Hosting: Where will you host your solution? Do you have an existing relationship with a cloud provider, or do you host on your own? At what scale will you need to plan for resources?

The “Getting Started” phase can seem quite overwhelming when you decide to build your own solution, with so many questions to answer. However, we suggest looking towards technologies you are already familiar with, and that closely align with your existing product. You should also try to leverage subject matter experts in your network who are operating similarly sized deployments to learn from their experiences. 

In terms of timing, you should allocate anywhere from three to six months to complete the planning and design phase, depending on the feature set desired and the capacity of internal resources to dedicate to this work.

‍

Buying an RMM – Getting Started

When choosing to “Buy” an RMM solution, some of those processes are like the “Build” decision, while others are quite different. Again, the first thing to do is assemble a decision-making team, however, the roles on the team will be different. The goal of this team will be to define the selection criteria for the vendor as well as potentially setting up and managing a formal RFP process. As compared to the “build” decision, the team will look like this:

• Product Management: Sets overall requirements for an RMM selection. 
• Development and/or Solution Architect: Evaluates the integration points between the RMM and your product. 
• Project Management: Formulates project timelines and manages teams against them (this role may not be necessary for smaller organizations).
• Development / Technical Support: Input on requirements and use cases, typically less involved in the selection process. 

Once the team is selected, you will begin the vendor evaluation process. Because core design and deployment decisions have already been made by the vendor, your evaluation will likely center on these aspects:

• Data Collection: How flexible is data collection via the vendor’s prescribed methods? Do they have an agent-based deployment model, an agentless approach, or both? Can you interact with the solution via APIs to ease data maintenance between systems?
• Data Visualization: How does the vendor allow you to visualize the data that is collected? Do they offer key performance indicators (KPIs) and dashboards? Do they offer reporting and analytics tools?
• Alerts and Notifications: Do they offer a wide range of alerts and notification schemes, such as email, text, and integration? How do you control who and when notifications fire?
• Automation: Does the vendor offer any automation capabilities? How do you send actions to a device?

You will also need to evaluate the vendor against your own standards for various requirements:

• Security of data transmission and storage
• Adherence to compliance standards (industry-specific and/or standards like SOC 2)
• Customer support capability and experience
• Support service level agreements (SLAs)

The vendor evaluation and selection process will typically take an average-sized business between 1 to 3 months. For larger enterprises or those that require an RFP process, the timeline could be longer depending on how many vendors are evaluated and the need for technical evaluations of the candidate solutions. In that case, plan to budget for six to nine months for this process. 

‍

‍

Part 2: Deploying Your Solution

‍Building an RMM – Deploying Your Solution

When building your own RMM, deployment will most likely be very iterative since you will already have pieces of the solution deployed. The first capabilities to roll out will be the data collection, reception, and storage components. Depending on your chosen architecture, this may involve the deployment of an agent to the devices, the subscription to data pipelines, or both. You will also need to deploy new services and storage solutions to your cloud network to receive and store the data in formats friendly for downstream RMM capabilities.

Like any development exercise, this process will involve development management, quality assurance, and production infrastructure to support the effort. It will also require deploy/test/fix / redeploy iterations while you work the kinks out of the system. You should also do some degree of load testing to make sure systems can sustain the current fleet and any near-term growth targets. Load tests will depend on the size of the fleet and the amount of data being captured.

If you decide to do data collection through an agent-based approach, you will need to determine how you will deploy the agent to existing devices. Typically, this will be via the existing software deployment capabilities that you utilize for your product. After testing your solution and deploying it across your existing fleet, you are ready to begin the next phase of deployment. 

This next phase includes building out data visualizations, reports, alerts, and actions/automation. During the building process, you will likely discover new data collection needs and incorporate those as well. This phase is generally easier and allows for rapid iteration, seamlessly integrating back into your normal product development cycle. However, making improvements to the RMM can lead to competing resource demands, as they must be balanced with new product needs and ROI considerations against other features. 

Common pitfalls to be wary of as you deploy your custom RMM solution include:

• Inability to dynamically scale processing at key size ranges (i.e., hundreds, thousands, and 10s of thousands of devices).
• Inability to control data processing costs, which increase as your deployment grows.
• Locking your solution into certain tools or integrations with third-party systems that become painful to remove when the business needs to evolve.

Timelines for building and deploying the solution will range widely based on the features necessary and the development team’s capacity and velocity for delivering the solution. Estimates will likely range between 9 and 36 months of real-world time.

‍

Buying an RMM – Deploying Your Solution

When you choose to “Buy” an RMM solution, your ability to configure the platform is constrained by the vendor. However, if you have done a good job of matching those constraints to your needs, then deploying the RMM solution should be straightforward and have little bloat.

You should plan for a phased rollout to validate that the RMM solution does not impact your product performance by first testing in a lab or QA environment. Depending on the level of configuration and customization offered by your vendor, you may also need time with the vendor’s implementation team to ensure you best set up the RMM to fit your unique needs. 

Deploying the RMM solution will follow the same procedures you would use to roll out a custom-built RMM solution. The vendor should provide you with an easily reproducible installation that can be deployed at your own pace across the entire fleet.

Assuming you select a SaaS-based RMM solution, you should not be concerned with deployment mechanics or management of cloud-based components. Also, you should expect that the vendor has already planned for some of the typical hazards of operating a large network of devices, including the ability to scale to meet demand cost-effectively. An RMM solution should also offer you easily accessible integration points for you to extend the solution to meet your custom needs in the cloud and from the device.

Deployment timelines for a purchases RMM solution can take 1-2 weeks to 3 months, depending on the amount of customization your product requires. If data comes in standard formats and your need for customization is low, then getting your RMM solution deployed and running should be very quick.

‍

Part 3: Operating Your RMM Solution. 

Building an RMM – Operating Your Solution

After designing, building, and deploying your custom RMM solution, you can now start operating the tool. Successful use of your RMM solution will incorporate the teams used to build the RMM solution:

• Production Support: How will RMM outages be addressed? RMM issues may overlap with product issues, occur independently, or even cause one another. The resolution will likely require internal collaboration between support and development teams. 
• New Feature Development: As with any product, business demands change, and you will want to incorporate features into your RMM solution to address new opportunities. For example, the operating environment of your RMM solution will likely evolve as new versions of hardware and operating systems are developed and deployed. These updates will require compatibility testing and upgrades to the RMM solution.
• Scale and Cost Management: As your deployment grows, RMM costs will go up. While this is true regardless of the “build vs. buy” paradigm, choosing to build the RMM requires ongoing cost management and continuous ROI justification for the solution.
• Expertise: To successfully operate your RMM, you need an internal Center of Expertise (CoE) to perform the necessary support and maintenance of the solution. This CoE should be independent of your primary product focus and will develop a unique and important skill set in your business. This team will also want to develop and maintain relationships within the RMM space so that your solution can help keep you competitive with the market.

Buying an RMM – Operating Your Solution

Operating a purchased RMM differs from using a self-built one. After deployment, any upgrades will need to come from the vendor’s R&D process, requiring close management of the relationship to stay informed on new feature releases. It's crucial to inform the vendor about any product changes, like hardware or software updates, that could affect the RMM's performance. You should also communicate expected changes in the size or deployment model of your fleet. 

You will still want to develop internal expertise in monitoring and managing your fleet, which should sit with a similar Center of Expertise (CoE) function. When new features are released, this CoE should be dedicated to mastering the tooling for the purposes of internal re-training and continuous improvement of process automations. You should expect the vendor to supply timely support to your CoE and look for a wide customer base to build on community support. You should not feel as though you are alone in the journey to improve the uptime and usability of your fleet.

‍

‍

Part 4: Costs of Building vs. Buying an RMM Solution

Most “build vs. buy” decisions ultimately come down to perceived cost advantages and technical synergies that organizations realize from building their own RMM solution. To properly estimate the cost of building your own solution, you should consider:

• Development Labor Costs: The time required from skilled team members in the “Getting Started” and “Deploy” sections covered above, typically 12 – 36 months for a team of 4 – 6 partially allocated team members. 
• On-Going Support Costs: Furthermore, dedicated personnel for the solution operation and new feature development will be required. For some teams, this can be consolidated into a single person, but most likely will require dedicated time from multiple individuals. Also, cross-training to avoid single points of failure is key, as with any business function.
• Opportunity Costs: In addition to the actual labor costs associated with that development time, a consideration of the opportunity costs for those valuable resources should be made. What other product features or competitive advantages will be sacrificed or deprioritized to reallocate team time? 
• Infrastructure Costs: There are also ongoing “hard costs” associated with operating an RMM solution internally. Consider production and test infrastructure costs dedicated to the solution and the variable usage for data processed by the system. The economies of scale will be limited to the size of your own fleet, so some base-level costs will always need to be carried out.
• Time to Value: Another consideration of the 12 – 36-month timeframe for development and deployment is the time that your solution continues to go unsupported and the impact that has on product performance and customer experience. There are several ways to calculate what a suboptimal RMM solution is costing your business. 
• Overhead Costs: There are several “soft costs” associated with operating the solution, which typically take the form of management overhead dedicated to making decisions on resource allocation and new feature definition. These costs also include the training and development of staff on using the solution.

In most cases, the ongoing costs of a self-built and managed solution come to several hundred thousand dollars a year, even for a relatively modest-sized fleet. However, in some cases, the benefits of customization or the size of your fleet may be able to justify this investment.

Evaluating the cost of buying an RMM solution is much more straightforward and allows you to have a predictable budget for deploying and operating the solution. Beyond the standard license costs, you should expect some form of the following costs:

• Product customization: Assuming your product requires more instrumentation than is available out of the box from the RMM solution provider, some degree of cost for product customization should be expected. Depending on the RMM solution’s ability to configure and customize, these costs will typically represent a small fraction of the long-term operational budget.
• Licensing Price Increases: Once deployed, an RMM solution will typically have some per-unit cost associated with ongoing operation. These costs are usually based on a count of devices or the amount of data processed in the platform. You may be presented with volume or commitment discounts as the size of your fleet progresses.
• Soft Costs: You will incur ongoing costs for vendor management activity, as described above. You will also have costs associated with internal training and, depending on the model, an internal center of expertise for the RMM solution.

Typically, purchasing RMM solutions on the market is much more cost-effective than building one internally. However, there is likely to be a strong vendor lock-in once the solution is deployed, and that bears consideration in both the “build vs. buy” debate and also in the vendor selection process described in “Getting Started”. You should choose an RMM solution provider that closely matches your current needs, has a track record of being able to grow with their customers, has a strong history of performance, and demonstrates a commitment to helping you better understand your business.

‍

‍

Conclusion

For those organizations willing to give up having direct control of their RMM solution landscape, buying an RMM solution that closely meets their needs is typically a much more cost-effective option for both the short and long term. The key part is selecting an RMM platform that can meet the unique requirements of your business, device model, and deployment ecosystems. Frequently, taking a very serious look at building an RMM platform internally will help prospective buyers gain a strong understanding of their ideal platform requirements and guide their buying process. For more details on determining the optimal choice between buying and building, explore further information here.

When you choose to purchase an RMM, your organization gets to focus its energy on the core product and its development while simultaneously taking a big leap forward in terms of fleet availability and customer satisfaction. In the best examples, a true partnership with the RMM solution provider is developed, which expands the ability of the product organization to deliver its solution and services.

If you are interested in learning more about Canopy or understanding if our RMM software may be able to help your business, reach out to our team, and we’ll do a free evaluation of your device solution and support infrastructure. Email us at info@goCanopy.com with the subject line “Free Evaluation” to schedule a call with one of our technical subject matter experts.