I recently wrote a hit article on buying enterprise software, and I was working on the followup when I realized that you, the manager tasked with choosing it, could benefit from an overview from an insider. I’ll explain how this software is packaged and delivered so you can discuss it with more confidence.
Most importantly, this will provide critical context and understanding to my final article, which will arm you with questions and talking points, both internal and external. That’s the one that will prevent you from going all Fahrenheit 451 on your company’s cash pile.
If you think you know all this stuff, please take a quick read and let me know if I’ve left anything out. Thanks!
What the heck is it?
I was a little surprised the first time an exec asked me, “What exactly is ‘enterprise’ software?” But it’s a reasonable question. In my view, it is software designed to handle the needs of the world’s largest and most complex businesses. This might include:
- thousands of transactions per second (Black Friday, returns after Christmas)
- large or complex data1
- highly complex business logic
- integration (data sharing and process triggers) with similarly complex systems
How do you write software that can do all this? Well, you don’t create a software package, like Word or Excel. You create a software platform. Something that can be molded and extended to meet your business needs within that specific domain (ecommerce, ERP, CRM, marketing automation, etc.).
SaaS or On Premise?
SaaS
Software as a Service includes vendors like Salesforce, Shopify, Mailchimp, Google Analytics, etc. They host it, and everyone is on the same system. It’s sometimes called “cloud based” because marketing thinks that’s cool. There might be different tiers of prices/features, and they will likely do something extraordinary for you if you throw enough money at them.
On Premise
The name implies it’s installed on your servers, but it doesn’t have to be. Could be hosted by the vendor, integrator, or anywhere you like. The key is that each installation is a one-off that requires separate installation and maintenance. Almost all on premise enterprise software includes the source code for you to customize, so it can also be a unique snowflake (for better or worse).
OOTB, Configuration, and Customization
OOTB is out of the box. It’s the features you get right after installation and minimal configuration. Like user management, and, um… well probably something else, you did just pay 6 figures for this.
Configuration requires no coding, just enabling features and modifying settings through the user interface. A product expert or business analyst (typically referred to as an administrator/admin in this case) can handle this, no need for a coder.
Note: Salesforce enables a ton of functionality via configuration, to the point where a Salesforce certified “developer” doesn’t do any actual software development (coding). Of course, there is coding you can do for Salesforce (Apex), but why not use confusing vernacular when you can? Welcome to enterprise software.
Customization requires coding. It’s often the bulk of the cost of the software. I frequently see professional services (what they call this work, along with the installation and configuration) running 1x-3x the license cost, which is often 6 figures.
Good enterprise software will have clear extension points (APIs) for customization. Most SaaS software has a web service API for integration. Web services enable your integration code to run anywhere, written in any language on any platform. You have a .NET coder, but the enterprise platform is Java/Linux, or some mystery? No problem. Through the API, you can download your orders, upload changes to your your customer database, destroy valuable data, etc.
A couple SaaS platforms, like Salesforce and Demandware, have a proprietary programming language, in addition to their web service. On premise software might have a web service interface, and/or a language API like Java or C#.
None of that is rocket surgery, but takes time to get the requirements right and cover all the edge cases. The problem comes when a core feature is implemented incorrectly for your business and there’s no way to customize it through the API. You have to change the core code (and maybe the database) to meet your requirements. I often suggest changing your process to match the software, if this is possible. But maybe you’re doing it differently because this is a competitive advantage. Or you’ve already changed your process to accommodate another, more expensive piece of software. Implementing this is possible with on-premise software that includes the source code.
Basic Architecture
It’s important to understand, at the 30K ft. level at least, the different parts of the software.
- Core code: The creamy center. It has most of the functionality and underlying services. It includes the APIs to integrate with other software (say, ecommerce to ERP or CRM) and add/modify features (customization).
- Admin interface: The interface to configure the software.
- User interface: What your customers or employees see.
- External integration code: This uses the web service API, FTP, or other external integration method. This code is stored and run completely separately.
- Custom code: What you write to add/modify features. It’s typically stored somewhere it uses or overrides – not overwrites – the existing code. Typically. It could include…
- modifying the user interfaces mentioned (changing the templates)
- code using the Core APIs to add features and integrate with other software
- changing (overwriting) the core code, if it’s really needed to support the business
As you’ll see in a second, modifying the core code is a lot like going back in time. You fix one thing, like, you didn’t total your classic car. But you somehow wiped out all the pandas. And we’re at war with Eastasia. (Luckily, we’ve always been at war with Eastasia.)
Upgrades
Upgrades can be very tricky depending on the platform and level of customization. With most SaaS, upgrades should be automatic and you get all the admin UI features and core fixes and improvements. The rest will require enabling through configuration, modifying the user interface, or adding code to access new features in the API. Code using old APIs should still work if they do it right.
With on premise, some of that will be the same. A new version means a new core. You drop it in, run regression tests, and you should get the fixes and performance improvements to the core code, plus any new admin screens.
In both cases, you may have modified the UI. That means your code is overriding theirs, so any features in the UI won’t be available until you add them to your custom templates. With on premise, you may have modified the admin screens as well, so same deal.
Finally, you may have modified the core code. This means you have to merge your changes with the new core. Which means understanding all the new code, but even the old code may have been changed significantly. Improving existing code is called refactoring and is an industry best practice. Lucky for you, such things are rare in enterprise software. No matter, it’s still a pain, and error prone. When finished, run a smoke test: are there still pandas?
In all cases, upgrades will be vastly aided by running your regression test suite. These are all the end to end tests created by your QA team that prove everything is working as it should, and they should be automated. When a project is running late, QA is the first thing to go. Why not assume we got it right the first time? When it’s time to upgrade, if you scrapped these tests, you’re going to have to factor them into the cost of the upgrade, along with everything else. Also, scrapping these tests means you have bugs you don’t know about, which can be really embarrassing for you.
Or you can continue to ignore proper QA. Just have your interns and office admins run through some basic tasks to see if anything broke. If so, blame it on the vendor. The vendor will never admit it’s their fault, but that’s OK until your CEO wants to be on your conference call.
Welcome to enterprise software.
- I find most businesses don’t have true, valuable “big data” despite the hype, but it can be pretty scattered and complex. [↩]