Before evaluating a build versus buy discussion for any commercially available software or cloud application, the discussion should begin with the question “what exactly is the need?” In other words, “what is the use case for the solution?”

When the use case is compliance with a set of complicated and demanding regulations and cybersecurity standards, such as the Defense Federal Acquisition Regulation Supplement (DFARS), the International Traffic in Arms Regulations (ITAR), and NIST SP 800-171 governing the possession and handling of federal Controlled Unclassified Information (CUI), answering the build vs buy question can be particularly demanding.

A useful analysis considers not just the necessary internal assets, required personnel, needed features, and goals of project stakeholders, but also requires a complete understanding of those regulations and where they are headed.

By necessity, this understanding of the legal requirements will go beyond whether an internal development will be timely, cost-effective, and achieve the needs of stakeholders, but also whether the immediate and future results of the development will fulfill the expressed and intended scope of the regulatory or compliance concerns related to the information. Without that being achieved, the best run development project will efficiently produce a solution that is worthless.

This paper will start with an analysis of whether to build or acquire an ITAR or CUI compliant storage and collaboration solution by first laying out the evaluation framework using the traditional factors of Cost, Control and Maintenance. Then, it discusses how an organization considering an internal ITAR or CUI development model will need to achieve the requisite regulatory knowledge and experience for that development, and then remain current on those regulations throughout the use of the internally developed solution.

Cost of Internal Development vs. Acquisition

No business wants to spend more money than necessary to have a working IT solution. Unfortunately, some real costs are often not considered in the decision-making process. Purchasing software can have an upfront cost (or subscription fee) that may seem expensive by contrast with the use of existing resources, but the expense is known, and the product compliant and ready to use very quickly.

But are all the costs of redeploying existing programming resources and launching an internal solution known and calculated correctly? Let’s look at some often overlooked or less than completely analyzed areas when determining real costs:

Immediate Development Staff Costs: Good software requires more than just programming talent. At a minimum, those line programmers must be joined in their efforts by project planners, software architects, senior management code programmers/developers, database architects and administrators, quality assurance personnel, application testers, and the administrative support and associated managers of all those teams. Even during the initial development, changes, enhancements, and new functionality are common in any development process. The less thorough the scoping of the project, the more those unknowns will surface.

Likewise, not usually planned, but always existing are the hours and hours of often unplanned or inaccurately planned debugging, scope creep, redeployment or loss of personnel resources, and budgetary pressures. It is little wonder that Gallup has reported that one out of every six IT projects have a cost overrun of 200% and a time overrun of almost 70%.¹ Some, of course, miss more widely on unplanned costs and delays than that found by Gallup.

Do you have a user experience team on staff? What about application designers? Does anyone in your organization know the possibilities and needs of a virtual data room solution addressing ITAR and CUI compliance? How strong and knowledgeable is your security team? The answers to all those questions have to be emphatically in the affirmative or the effort will be at best, at risk and at worst, a preordained failure.

Designing and building this kind of software requires more than just reassigning existing programmers or hiring an offshore team to build a scoped project. What if the technology you thought would be suitable turns out not to be sufficient? What if you need to find highly skilled or specialized employees or contractors? What happens when the technology changes? Better solutions or more efficient solutions are constantly being developed.

Long Term Support, Maintenance, and Upgrades Staff Costs: And the unknowns can multiple. If the developers that build your application leave the company, will new people be able to understand the code, address bugs, and make improvements in a timely fashion? Will those developers be available later to provide the user support, maintain the solution in an ever-changing IT infrastructure, and provide upgrades to address additional user and regulatory demands? Can it even be known how much additional work this will cause, thus challenge budgetary assumptions?

Technology Costs: There are numbers of instances where a project began using an expensive technology platform, only to discover there was a better, less expensive open-source alternative. Conversely, an organization will choose an open-source technology without fulling understanding the costs and challenges in staffing the project (as well as the limits and requirements of related technology licenses). In either instance, these technology platform issues can cause both substantial additional costs, delays, or both.

Time Costs: If a company wait to build an application, how much potential revenue will be lost while until the development is completed? What are the costs of continued regulatory non-compliance from forgoing an existing solution in favor of one internally developed, but not available during the interim? The revenue loss of being unable to address ITAR and CUI related opportunities or, perhaps even worse, suffering non-compliance penalties and fines that would not have occurred with the use of an off-the-shelf solution could far exceed the payment for a license or service subscription. When calculating return on investment (ROI), all factors need to be considered, including those associated with such a risk.

Controls for an Internally Developed Solution

One of the most popular reasons for building an inhouse solution is the company having control over the application. However, this means that the company is always going to be responsible for hosting and maintaining the application, as well as relying on the development team to make any changes or improvements to the solution. With an available commercial solution, there often is the advantage of getting exactly what is wanted or needed now, and achieving that at a fixed cost for hosting and supporting the solution.

Additionally, an internally developed solution is frequently subject to renewed or extended development as internal constituencies with access to programming resources are looking for more.
“Scope creep” is where a planned project starts to stray from its original intended purpose, and other parties want you to add a function or build something on top of the application. Scope creep can be devastating if not managed properly – and it rarely is when building inhouse. A big part of scope creep comes when a company realizes the newly developed system needs to work with other systems being used. It’s never as easy as it sounds.

As an example, Customer Resource Management (CRM) solutions aggregate customer data -which seems straightforward. It builds some forms, saves customer name, address, phone number, email, website, and some other bells and whistles. Easy enough – now we’re done!

But wait! What about sending emails out of the CRM from a sales team’s email addresses? What about modifying the design and content of those emails? What if the sales team wants to automate those tasks based on user requests? What if they want to integrate calendars? Management wants to watch our sales numbers, so integrating the CRM with accounting or ERP software becomes a requirement for the project.

That simple CRM now has tremendous scope creep. Not because it was not scoped appropriately, but because people wanted to use the system for more or improve the current processes or systems. This scope creep folds right into the development goals of a third-party provider of the system as it seeks to make a product as useful to the market as possible, sometimes by only adding niche requirements that nonetheless can attract user interest. Scope creep for a company-specific solution however cannot be leveraged across a market but involves costs that have to be absorbed by one company.

Once the internal application is built, the integration is needed so that it can talk to our other systems. Building a solution allows you to integrate with the current technology ecosystem, but that can change as well. How many databases and code bases do an IT department want to support?

Maintenance of an Internally Developed and Supported Solution

Experience shows that the third traditional factor of maintaining an internally developed solution can quickly expose a company to what is more a curse than a blessing. While additional third-party cost for a service contracts is perhaps avoided, although not in all instances as hardware and software must be obtained to support an internally developed solution, the involvement of a company’s people is still going to be a cost measured as time spent that could have addressed other projects or IT needs, as well as in money. Maintenance and support and security are a 24/7/365 requirement. Pulling resources away from current projects can have far-reaching effects on other aspects of the organization.

Other parts of maintenance include updating the system, creating enhancements, improving the system and securing the system. These require a company’s team to constantly spend time staying up to date on the latest and greatest technology to keep an internal solution current and operable – in addition to their regular responsibilities. More than likely, your company does not have the experience in building this level of complex applications. This is when you turn to a company that knows the industry, the regulations, and the nuances.

Lack of Regulatory Expertise

Having expertise in all aspects of a software is nearly impossible, but it’s just one aspect of a company’s risk when undertaking development of an internal solution. Legal ramifications, compliance requirements, and privacy concerns are not usually skills developers possess. Failure to address these factors can make your project unusable. Is the software Sarbanes-Oxley compliant? If not, no public company will buy it. Will it satisfy the requirements of the ITAR, NIST special publication 800-171, and the Defense Department’s Cloud Computing Security Requirements Guide, or the evolving standards underlying the DoD’s Cybersecurity Maturity Model Certification (CMMC) framework? If the answer to all of that is less than an emphatic Yes!, the effort is not just worthless, but dangerous to the company.

Training also must play a part in your decision. If an application is very complex, a company will need to spend a lot of time training people and integrating the process and procedures into its current system. This may require hiring more staff that is more experienced with the new technology.

Costs, Risks, and Loss of Functions Avoided by Not Seeking to Replicating the Focus of RegDOX’s ITAR and CUI Solution

RegDOX’s focus is on using its leverage across multiple customers to ensure both ongoing ITAR and CUI compliance and providing its solution without the risk of non-compliance and at price and level of functionality that cannot be replicated by any one company for its internal use. The success of this effort is demonstrated by its approval by the Directorate of Defense Controls, the agency that has issued and enforces the ITAR, and its numerous and growing number of patents covering its application. This success is the product of many working years of development and a deep expertise in the ITAR and requirements for CUI.

The bottom line for any company considering programming its way to ITAR or CUI compliance is that seeking to replicate what RegDOX’s does best is not only going to be more expensive when considering all upfront, ongoing and hidden costs, but the effort will bring greater risk of non-compliance and many fewer features and functions.

¹ September 11, 2011, Why Your IT Project May be Riskier than You Think, Harvard Business Review 89(9):23-25.

 

About RegDOX Solutions Inc.

RegDOX Solution’s first-to-market ITAR and NIST 800-171 (DFARS) compliant online storage and collaboration product has redefined how export-controlled and CUI documents and electronic files can be handled within regulatory requirements. This was recognized by the formal opinion of compliance provided by the US State Department’s Directorate of Defense Trade Control (DDTC). RegDOX’s unique capabilities were confirmed on August 20, 2019 when the US Patent and Trademark Office issued a patent covering RegDOX’s system to store and manage export-controlled documents in the cloud. (Patent No. 10,389,716). The RegDOX® ITAR/EAR solution provides ground-breaking and unsurpassed technology enabling the efficiency and flexibility of a cloud solution to allow multiple users located at numerous locations to collaborate using controlled data while remaining fully in compliance with the strict regulatory and licensing requirements of the ITAR and DFARS.

www.RegDOX.com