Build vs Buy
There is often little point in re-inventing the wheel when considering enterprise software. CRM, ERP, MDM, Ecommerce, Live Chat, Project Tracking Software etc all exist and have been proven to deliver when deployed effectively.
Creating such applications in house is not generally a good use of your budget. Not only do you have to invest in the actual build, but mission critical applications require extensive testing and refinement, often taking multiple iterations and consuming a huge amount of resource from stakeholders across the business to deliver something that already exists.
Rather, your budget should be used to build that functionality and logic that is unique to your business. Optimise those processes that make you stand apart from your competitors and deliver engaging innovations to your customers that break new ground.
The key is to identify where your business can adhere to industry best practices in order to align with Common Off The Shelf (COTS) software and where your business really must be unique and develop bespoke solutions.
Procuring ERP, CRM & Other COTS Enterprise Systems
When your company is considering adding or replacing a key back office system the driving force will typically be the business function who will be the primary users of that system, for example finance for ERP systems and marketing for CRM systems. It is therefore logical that stakeholders from those functions will contribute to the decision making process.
In fact, it is essential that they do in order to ensure an appropriate feature set exists in any newly procured system. However, in the modern age of technological advancement, rapid innovation and data driven decision making it is essential that IT has a voice in this process.
To keep up with competitors you need to be able to innovate. Will your new system be extensible?
To make data driven decisions your data must be accessible. Will your new system give you timely, standards based access to high quality data?
To stay efficient you should strive for standardisation across your estate. Will your new system introduce alien technologies that must be supported in-house?
To have low risk upgrades you must have testable solutions. Will your new system facilitate automated creation of test environments?
Extending ERP, CRM & Other COTS Enterprise Systems
Your unique processes and functions are the ones you should code, establishing high value intellectual property that exists in-house.
However, you will quickly face this question: should I extend my COTS software or should I deploy standalone software?
Many enterprise software vendors have invested millions in making their solutions flexible so that they can be extended to support such customisations. While taking advantage of this feature can be advantageous, it should not be considered the default position and at times is clearly not the best option.
An alternative approach is to deploy your custom logic, your unique business rules, in applications that your team authors and maintains, for example following a microservice architecture, if appropriate. This approach can afford you far more agility when it comes to innovating and deploying changes rapidly with low risk (just to be clear, that is little "a" agility but big "A" Agility also plays a role as we will see later).
This approach also avoids you investing in your own vendor lock in. The more you customise your COTS enterprise systems the more difficult and expensive you are making it if you ever need or choose to migrate to an alternative platform. Remember, you are coding your unique business processes, so if you change vendor you will somehow have to take that unique functionality with you, very likely necessitating a full rewrite.
Greenfield Developments
Often your back office systems are the ones most compatible with COTS enterprise systems. They model mature, slow moving business processes and tend to have a long lifetime. Your customer touch points on the other hand must often evolve much more quickly making them suitable for greenfield development.
Here you start with a blank canvas and ask the question: What will delight my customer? What will make a customer choose my company today and then return to my company the next time they need to make a purchase?
Keep sight of the following points with such projects:
- Create exceptional experiences - your developers should have enough time to deliver high performance applications where their code is robust and minimises the effort required by the user. Users do not want to wait for applications to load, they don't like error messages and they don't like inputting data that is non-essential.
- Deliver quickly - your user experience team can outline a fantastic project that would delight your customers, if you delivered it quickly. But customer attitudes and expectations have never been prone to change so rapidly as they do today. If you can't deliver until next year there is every chance that what you are going to deliver is out of date.
- Architect for change - since change is inevitable and by its nature introduces an unknown future state, you will maximise your chances of success by architecting for change. Create reusable building blocks and create components that integrate with other components so that in the event of a pivot your investments still have value.
Quality
The next step is to ensure that your code is going to be high quality. The lower the quality of the code you ship, the more time your teams will ultimately burn supporting it. There are several steps you can take to promote high code quality:
Estimation
The people writing the code need to be driving estimations, the alternative is near certain failure. However, each estimate needs to have a correctional multiplier applied. It is natural for such estimations to undershoot the actual time taken for reasons such as:
- Developers tend to be over optimistic
- Developers tend to think of the steps they will go through to write the required logic and pay less attention to time lost to team comms, debugging, refactoring, refining etc
- Developers tend not to add in extra time to give them some breathing space (of course there are some who would in order to take it easy and catch a free ride, but let's assume you don't have any of those in your team)
- Developers tend to try to hit deadlines that are communicated to them, either officially or unofficially even when the voice in their head is screaming "DON'T DO IT".
The good news is that there is often a good degree of predictability about this estimation error. So provided you are gathering data on your project delivery process it is pretty straightforward to come up with an appropriate correctional multiplier so that each team member can be given a comfortable amount of time to deliver their work to a high standard.
Testing
The testing process should start before you write any code, if you are aiming to ship high quality code. The rationale behind this is that it is easier for a developer to code against a set of well specified test cases than it is to code against a requirements document and technical specification. The reason for this is that test cases are written in terms of what outcome will pass a test and what outcome will fail. It is black and white.
What is more those black and white outcomes can be tested in code and that testing code can be executed automatically as and when needed.
Therefore, if you start by coding your test cases you can subsequently verify that the code being written to deliver your unique business process logic is high quality in terms of meeting the desired outcomes. When tests fail they can be investigated and fixed while still fresh in a developers mind, rather than some time later when all relevant context has been lost from memory.
Review
Better task prioritisation Your team will write better code if they are given time to review it and improve it. They will write the best code possible if, as a team, they can review and refine work together. Everybody has different specialisms and this is one of the best ways to share knowledge and improve the quality of code
Feedback
Adopt a delivery methodology that gives feedback early and frequently. Such an approach has numerous benefits such as:
- Early course correction
- Better expectation management
- Better task prioritisation
Here we are talking Agile. Big "A" Agile, as per the Agile Manifesto. But a word of caution, be sure to understand what it means to adopt Agile practices and ensure that there is an agreed understanding across the delivery team and project team, otherwise it is odds on that you will get near a project deadline only to find that the project is significantly behind schedule albeit with a much expanded feature set.
Agile is not a magic wand, rather it is a way of working that promotes feedback loops, frequent deliveries, prioritisation and sometimes even pivots. Keep in mind that such flexibility demands that the concept of project budgets and times must also now be considered with a degree of flexibility and that there will be a tradeoff between certain variables.
For example, a fixed budget is achievable against a flexible delivered product only if there is also flexibility in the exact features that will ultimately be delivered.
The smaller you can make your deliveries and the more you can amplify your feedback loops, the more value you will find in following Agile practices.
Architecture
Well written code is not enough if you want your organisation to be able to keep pace not only with technological advances, but with your customer expectations and you competitors innovations.
You need an architecture that can scale. The alternative is that as you achieve your business goals you find that your software must be rewritten in order to meet the demand that is being placed on it.
You need an architecture that is consistent. This consistency will allow your team to maintain your estate more easily.
You need an architecture that is testable. A testable architecture means you can identify problems quickly and easily and that reassurance makes it easier to maintain and extend your software, not only today but tomorrow, next year and even further into the future when your team members may have changed dramatically.
You need an architecture that is secure. Defence in depth is the best option in the face of multiple threats trying to steal data, extort ransoms or hijack your hardware.
Your architecture can allow you to decouple deployments from releases, minimising release risk by allowing features to be turned on and off as necessary. This is especially true when your architecture also allows you to gradually release your updates to targeted users rather than being forced into big bang releases.
Legacy Applications
There may come a time when one of your key systems will need to be retired and replaced with something newer or perhaps even some bespoke software. Perhaps it is end of life meaning the vendor will no longer support it, perhaps it fails to comply with current regulations or perhaps it is missing functionality that you need in order to stay competitive.
Often retiring a key system is a painful, high risk process. This is typically the case when it is responsible for a wide range of functions, has been modified/extended and when other systems depend on it in some way.
One effective way to de-risk such a project is to apply the Strangler Pattern, incrementally placing facades in front of specific functionality in order to decouple applications from the old systems making it possible to gradually move functionality to a newer system at which point the facade can re-route requests to the newer system. When all needed functionality has been replaced the legacy system can be retired without the risk of a big bang transition.