Proprietary Software Development can be a significant asset or can impede growth and agility. Here are some things we look for when we look under the hood of a software engine as part of a proprietary software review(PSR).
Some of the considerations we evaluate fall into these three buckets.
Financial
There is cost to maintaining software, from the license cost, to the infrastructure cost, to the cost of allocating people and resources to keep it running. The financial cost can be especially difficult to anticipate if there is a big release event or if the application or infrastructure needs to be updated.
Business
There is business risk to having out of date or poorly maintained software. If the software is not current and requires an update or even a rewrite the cost to the business could run in to the millions. It’s imperative that any and all software assets are up to date and if significant investment is required you will want to understand that cost.
Think of software as being almost like a condo HOA. When the condo structure is new minimal maintenance investment is required, but over time the foundation can start to degrade, the windows might need replacing, the roof will age. Software ages much in the same way that buildings and physical infrastructure do.
Technical Exposure
Software depends on technology to work, that underlying technology itself is prone to failure. Security vulnerabilities and integration risk pose challenges to software performance. The technology contributes to the business and financial risk of maintaining proprietary software, so you need to identify the overall cost and risk of any software package and its adjacent systems.
This blog is focused on providing insight primarily into some of the key technical considerations and things that we look for during a proprietary software review in conjunction with greater technical due diligence.
Different (key) strokes for different folks
You don’t know what you don’t know. While many company’s greatest asset is their differentiated software and related intellectual property, software applications are only as good as the person who wrote them and the platform they are running on.
Have you heard of something called COBOL? It is a computer programming language developed in the late 1950’s and early 1960’s. It went out of fashion in the eighties but It’s still being used to power government and financial systems around the world. As trendy as mid-century architecture is these days, running your software applications on a language that was developed before we put a person on the moon might not always be the best solution for your value creation strategy.
Based on our experience conducting thousands of IT diligences and looking under the proprietary software hood we have compiled a set of key considerations that we wanted to share with you as you plan for an acquisition or evaluate your own internal software maturity.
MANY SOFTWARE APPLICATIONS SEEM TO WORK FINE BUT POSE HIDDEN RISKS
Applications can have excellent functionality and be highly tailored to the company’s business processes but “under the covers” could present many functional and quality issues that are difficult to detect. Some of these issues include:
- Obsolete or inappropriate (programming)language and/or platform
- Unsupportable versions
- The software might claim to be SaaS-based while running multiple versions of single-instance software (sometimes thousands)
- Obsolete or “dead-end” technical infrastructure (we once reviewed proprietary software for a major e-commerce company that had to go on eBay to buy a certain vintage server because that’s the only one the antiquated software would run on)
- Inefficient or buggy code causing performance bottlenecks or worse
- Lack of documentation making support difficult if not impossible
In the same way that programming languages become outdated (but can still be in active use), there can be inaccuracies in the code, inefficiencies in the way the applications are running, and a lack of a resiliency strategy just to name a few. It takes an expert eye to identify these vulnerabilities and mitigate the issues..
WHAT’S UNDER THE HOOD OF YOUR CUSTOM APPLICATIONS OR THOSE OF YOUR PORTCOS?
If you were to look under the hood of a software engine, would you know how it’s running? What if it stalled out, would there be anyone around who knows how to fix it?? There is a concept that we come across quite frequently that is a huge vulnerability and that is what we call “key person risk” Is there one person (or just a handful) at your company that are the only people that understand how a specific application works? What if they leave the company?
One of the first things we take inventory of when conducting a Proprietary Software Review (PSR) is understanding the business environment. The importance of the custom code to the business informs the way that it needs to be developed and maintained.
Is the software very important, as in a SaaS provider that is planning on monetizing the software to grow its business? Is it a mission-critical app for a brick-and-mortar company that relies on packaged software to keep the business running? Perhaps you are evaluating a company that uses e-commerce to sell its goods with some custom software or “code” where if the e-commerce platform goes down the company has no way of making money while at the same time eroding its brand. The level of importance of custom software informs not only the business value but the business risk.
RED FLAG PROGRAMMING LANGUAGES
Our reviews illustrate two major issues with language choice: Obsolete languages and inappropriate languages.
Inappropriate languages are usually those that are meant for the non-IT person to create a small departmental tool – but time goes by, the tool keeps growing until it becomes a “mission-critical” application but has limited (or no) scalability, performance, support, and documentation. Examples of these are:
- FileMaker or FileMaker ProColdFusion
- Microsoft Access
There are coding languages that fall out of the mainstream or become obsolete. When application developers use antiquated languages, it makes it difficult to support modern trends in technology (e.g. web-based, mobile, etc.). A few examples include:of dated languages include:
- Classic ASP
- Delphi
- Non-.Net Visual Basic
ARE YOUR APPLICATIONS RUNNING IN THE RIGHT ENVIRONMENT?
The “cloud” represents the most agile and scalable environment for application development, deployment, and backup. While it might not be right or every single application load, particularly highly sensitive applications, cloud-based systems are the defacto standard for building and running applications.
Here are some things that we look for when understanding the extent to which a company is leveraging the power of cloud:
- How is the company using the cloud for development, maintenance, bursting, and resiliency?
- Is the company using the cloud for appropriate workloads?
- Do cloud-based systems interact or integrate with traditional systems and if not what would be required to do so?
- Are the key applications cloud-native (designed specifically to take advantage of a cloud environment)? Or just running in the cloud (designed using a more traditional approach that limits scalability, reliability, extensibility)?
- Is the company using a methodology that lends itself to running in a cloud environment, something called “agile” software development that relies on frequent meetings and development springs that provide for continuous innovation?
Most applications are running in the cloud and in those cases where firms are using a traditional client-server environment, there might be an opportunity to transition to a more progressive environment. You need the assurance that any application that is central to the success of the company and your value creation strategy runs in the right environment.
GOVERNANCE IS KEY TO KEEPING DEVELOPMENT AND MAINTENANCE ON TRACK
Software has to be produced using a consistent approach to design. Being deliberate about the governance that applications run on ensures uniformity in the way its development, maintained, upgraded, and even deprecated as part of an end of life.
These are some of the things that we look for in the management and governance of software applications that you should consider for any investments:
- Coding standards and guidelines exist that have been properly documented
- Naming convention standardization so that people can “read” the code and make changes
- The controlled use of third-party libraries, compliant licenses, and sufficient version control
- Is there a policy on code commenting? It’s important that when code is created and then made obsolete that the programmer not delete the out of date code, rather “comment it out” or remove it from active use but keep the original code in the software so that it if other people review it they can refer to prior versions of code
- Documentation of best practice and standards
- Clearly defined policies around stored procedures or actions that are triggered automatically
- We look for any out of date or antiquated practices
- Clearly defined guidelines for different languages and adherence to those guidelines? For example, MVC – Microsoft Best practice
- Can the code be easily interpreted and enhanced or is it unintelligible?
WHAT IS THE LEVEL OF QUALITY ASSURANCE?
Even famous novelists need to have their writing reviewed, edited, and rewritten. Computer code is no different and requires quality assurance:
- Quality Assurance – are there toll gates in the process?
- Testing can be automated which is a great way to add efficiency – are the applications you are evaluating using automation for testing? If so that is a sign of high sophistication.
- Does the company even have QA people? You want/need to see at least one dedicated person with some kind of basic structure
- There are different ways to manage quality and it is important to develop and run different kinds of tests to make sure there are no surprises including cases — Regression testing, System Testing, and Unit testing
BACKUP AND RESILIENCE
If the software is “Mission Critical” like an e-commerce engine that runs applications in real-time, you or your target investment companies can’t afford to have any outages and the application needs to be developed with that in mind.
- There needs to be a backup and recovery solution that ensures that there is no data loss in the event that there is an outage. Additionally, in the event of an outage, there needs to be some mechanism to recover the application and reinstate it in its production form as needed.
- Many successful companies will have a practice established for scaling, bursting, recovering data and applications, and backing up key information
- backup applies not just to data but infrastructure settings, even the core software code, and configurations.
- Different approaches are required to backup and recover different applications, depending on geographical footprint, storage needs, performance variance, and other considerations – none of this is one size fits all.
SECURITY!
Security is paramount to the success of your environment. This is something that we consider as a separate type of diligence and engagement so go here to see more on our cyber assessment.
TIP: Security spans software, infrastructure, process, personnel and is a highly complex topic in itself, to learn more about cyber risks and considerations, see our Guide to CyberSecurity
Software done right is an amazing thing. But it is very complex, make sure you have the right experts on your side to make sure that what is under the hood is built to last.
For more on how PIP can help with a proprietary software review and Application Development and Integration, go here.
Need to learn more or get a proprietary software assessment?
TIP: Understanding proprietary software vulnerabilities is a core component for any IT diligence
