POINT OF VIEW
Buying enterprise software is a long-term decision and one that has challenged IT managers for decades.
Back in the good-old nineteen eighties, packages were few, they were expensive, and not configurable. The decision to build often delivered cost savings, and delivered a solution that suited and evolved with the business.
Packages have changed
Buy if you want to deliver something quickly, or to adapt faster that the package vendor.
Today there are hundreds of packaged applications that almost always deliver broader and deeper functionality than home built. They are cheaper to procure and adopt, and deliver a solution that maintains pace with regulations and market demand.
• Packages are available to kick, and the delivery risk has already passed
• Packages can be configured but not infinitely
• Packages are immediately available for installation
The beauty of packages is that anyone can have them. You have to build if you want to deliver something unique, or to adapt faster that the package vendor.
Build if you want to deliver something unique, or to adapt faster that the package vendor.
Building a solution does make sense in some circumstances.
• You have a unique problem that is not catered for in a package
• You want to evolve the solution quicker than a vendor will
• You believe you can do a better job or want a challenge
A decision to build is seductive. It suggests agility, better requirements coverage, and perhaps long-term savings. It is easy to overlook that most projects fail to deliver most of their initial requirements, that delivery risk is real, and that the initial costs are invariably going to be more than expected.
Buy to Build
Flexibility has a price, and large parts of any solution are standard and cheaper to buy, for example you would not dream of building an operating system or database.
Buy foundational software to accelerate and de-risk your build. Be clear about the objectives and principles of the design and development, and avoid continual polishing or refinement.
Packaged solutions, such as the Responsiv Unity Process Module, deliver a runtime that provides the fundamentals, operating system, security, connectivity, monitoring, and development tooling. This allows you to focus on the parts of the solution that need to be flexible and that deliver benefits.
This particular product tooling is designed to allow quick changes to the processes to allow continual refinement rather than big bang must be right first time. The result is fast time to value and perhaps just as important, a quick way to evaluate that it is right for you.
Choose foundational software with a good secondary market in skills to manage delivery costs, and to help facilitate long term maintenance.
Finding: Buying a foundational product is justified in the long term.
Foundational software is often difficult to justify for the first small projects that may benefit. The danger is that by the time a project does justify a package you have already invested heavily in build.
• Seek to adopt middleware early in stages of company development.
• Use professional services to reduce delivery time, risk, and TCO.
• Use a portfolio of projects to justify early purchase of foundations
Do not overlook the cost of maintaining DIY infrastructure software.
Responsiv Solution as a Service
Responsiv solution as a service is an offering that provides you with the best of all worlds.
• You define requirements.
• We discuss requirements in terms of time to deliver, cost, and value.
• We build a solution that delivers your agreed requirements
• We host and operate the solution,
• You pay an annual subscription and bask in the benefits
Summary of Considerations
￼￼￼￼￼￼1. Sometimes it’s better to build, however most of the time a buy or buy to build approach will deliver better and faster.
2. Use experts with experience. Experience counts. Look for companies prepared to share delivery risk.
3. Buying is most appropriate when there is a good fit with minimal configuration. Always make sure that the business value of solving the problem justifies the cost. That the solution can be integrated and managed as part of the larger estate, and consider skills and ongoing costs.
Richard Whyte has been building enterprise IT solutions for over 20 years. He is known for creating innovative practical solutions that provide a strong foundation for future development, whilst solving immediate problems. Previously the European CTO and Principal Architect for IBM Systems Middleware at IBM, he has an MBA, a degree in Statistics and Computing, is a Chartered Engineer, a Chartered IT Professional, and Fellow of both the Institute of Technology and the British Computer Society.