CIO’s Dilemma: Build, Buy or BPM
Choosing the Right Application Strategy Path
CIOs constantly face one of the most complex decisions on the IT Strategy front:
What is the most effective way for our organization to introduce new applications or rebuild old ones?
These discussions are always bound by key options:
- Build a custom application.
- Buy an off the shelf commercial application.
- Buy a BPM/BPA Suite.
- A hybrid approach.
Build
Ah, the custom application. The promised land, everything you want, built exactly to requirements ;). My favorite CIO quote in my time in BPM is: “I am so tired of being a custom software development house.” The Build option has historically been the de facto path to meeting the exact business needs of a desired application, and truly tailoring functionality. But building comes with unique resource requirements, longer timelines, and rigid change management that prevents agility. Add in the standard requirement of Line of Business (LOB) System integration, and even small applications can require large teams with diverse skill sets to deliver. For this reason, many organizations leverage 3rd party partners to help with development, which adds to overall project complexity. The benefit? If managed correctly, you get exactly what you want. Some great info on Build vs Buy here: Build Versus Buy Whitepaper
Buy
Whether its Safety, HR, Accounting, or any other core business function, there are focused commercial applications to meet business needs. Most of these applications will meet about 80% of an organization’s requirements, but what I find is that missing 20% is the true gold. Many applications offer APIs to extend and add functionality, but this requires custom development or hiring the 3rd party’s services team to extend. I am seeing more and more organizations that are trying to get their app “bloat” under control, and reduce the number of niche applications in use by their business. There are some key questions to ask when evaluating focused apps:
- How easy is it to integrate with my LOBs? Code or configuration?
- Is the system overkill for what we are trying to accomplish?
- How difficult is it to administer? Will I require certified staff?
- What is missing and what will it cost to extend and maintain?
I find many organizations “settle” when it comes to off the shelf applications, and adjust their business to the application. The key benefit, in most cases, is you get up and running quite quickly, and can glean advantages and ROI without waiting for dev or build time.
BPM/BPA
The Business Process Management/Business Process Application suites are just about always in the mix, but I find there is always some deep education required on capabilities. There is quite often core resistance to them, especially from the development teams. No/Low Code platforms can be perceived as a threat, but smart dev managers see them as powerful tools that can lead to reduced delivery time, increased agility and quite frankly, a driver for accomplishing more with less. The benefits are shorter dev times, agility when it comes to modifying the applications, and creating process centric applications that map to the business. These platforms have evolved into a true “swiss army knife” of IT, and can be used as a plugin to provide solutions around all types of requirements. More on No/Low Code here: No/Low Code Platforms
Hybrid
The hybrid approach seems to be quite common, and many of the inquiries I see today involve organizations looking for BPM/BPA platforms to round out their existing inventory. Maybe they have a custom dev project where they need a workflow engine, or a data integration layer, and see the platform as a way to provide core capabilities. Perhaps they purchased an off the shelf app, and need to extend it, or wrap it with a more capable forms or reporting engine. To see how a hybrid strategy including BPM/BPA can impact an organization, see this post: BPM Benefits The true benefit of this hybrid strategy is that you can have all the benefits of the core BPM engine, and use extended capabilities through the APIs to add value to other existing apps or projects.
Just a quick overview of App Strategy observations. Comments?
