Evaluating, Selecting and Procuring Off-the-Shelf IT Solutions

I had an invitation to attend a workshop on software selection methodology. While reading the synopsis, I thought not only about how much things moved on but also where they may have not changed enough.

When custom software development was the norm, the emphasis was on specifications that the developers, internal or external needed. The emergence of multi-client software packages lead to an evolved approach. This approach then became the new norm, even though we often come across cases where a custom development mindset is used in off the shelf procurement.

So for custom software, a project or projects are started and (instead of designing and coding a new solution), this project identify, select/procure and configure the solution based on (potentially commercial) off the shelf solutions. This process could be shaped by strict requirements, for example OJEU constraints, in which case the method tends to become heavy, driven by a mandate for full definition of the requirements. This tries to avoid what often happens anyway since even if the vendor solutions meet the requirements, the business expectations may have moved on...

These days, in most large corporates, we would argue that the complexity of the selection exercise advises another approach, an approach that is more holistic from the outset. When a new business strategy is adopted, various functional and non functional building blocks may be required, and most of the domain where the building blocks fit are not greenfield. The question is how can the key interdependencies, the current landscape high level integration requirements and any overlapping functionality be efficiently considered in parallel by each of the projects? Would that be efficient and could it be governed effectively particularly in a multi vendor delivery environment? I.e., with different SIs responsible for different projects. Or could the selection, procurement and configuration of packages instead follow from an initial high level architecture definition?

In this early high level architecture definition phase, the required capabilities could be defined, down to the key known requirements that cover functional and non functional aspects. This usually requires a level of research of the market, in collaboration with the business. A key outcome is the delimitation of each of the solutions, providing the basis for subsequent governance. This will also ensure that any subsequent projects that focus on selecting each individual sub-solution will more easily identify whenever overlaps with separate solutions are developing or when candidate solutions that had been researched fit better with other projects.

So we strongly believe that, before embarking on software selection, it is important to define the overall solution at a high level. This is the typical role of the business architects, analysts and enterprise architects, working with commercial/procurement, legal and IT & business stakeholders and often with vendors as well. Obviously cloud options also need to be considered early in this selection process, which is another topic in its own right.

Share Share