The Proof of Concept Evolution

Before embracing a technology, prospect organizations usually undertake a Proof of Concept (POC) project to evaluate the offerings of various development platforms.

A Pilot project, an initial rollout in production with limited reach, is an integral part of the POC project. A pilot project evaluates whether a development platform is capable of implementing features that are crucial for the system.

Prospect organizations undertake a series of POC processes to evaluate the following aspects of the platforms under consideration.

● Learning curve.

● The speed of development.

● Development process.

● The effectiveness of the final result.

● Quality

● Pricing

After evaluating these aspects for all platforms, the prospects decide which platform meets their requirements the best.

Does POC independently address all the challenges an organization will face in the future?

Is Proof of Concept, per se, a comprehensive and prudent way of evaluating platforms under consideration?

Unfortunately, POC processes neglect a fundamental fact of the software industry: Change.

Studies indicate that 40 to 80% of software lifecycle efforts are directed towards maintaining or updating software solutions.

Contrary to the popular misconception that the scope of software maintenance is limited to bug fixing, software maintenance also encompasses modifications to software systems for continuous improvement - which translates into developing new features throughout the lifecycle of the product.

In the era of software as a service and digital transformation, we must be clear that maintenance is probably the most important phase of the software lifecycle.

Proof of Concept is an efficient way of assessing a platform’s capabilities and effectiveness; however, PoC does not address the challenges an organization may face in an environment of fast-paced technological evolution. I believe that maintenance & evolution are key aspects that we must consider when evaluating development platforms.

POC & POCh

To exhaustively evaluate the ability of a platform to meet an organization’s software development objectives in all phases of the software product lifecycle, we need to append a Proof of Change (POCh) to the existing POC processes when evaluating development platforms so that we can evaluate not only the creation phase but also the maintenance phase.

So, what are the changes that can affect my solution?

&

What challenges do organizations generally face in maintaining and updating their software solutions in the long term?

We should create different levels of POChs where we can evaluate what happens when we have one or more of the following:

• Small Changes in business requirements

For instance: Adding egalitarian marriage support in a civil registry system. How the different layers (data, business, and UI) are affected and how the platform helps to take such changes into account.

• Big Changes in business requirements

If small changes cause problems, big changes will probably cause earthquakes in my system. What about the cost of changing almost every relationship between entities in my design. What about the data already in old structures. Again, what about different layers?

• Changes in the target platform.

Is the development platform capable of migrating applications from one target platform to another? I mean things like migrating the server-side technology from .NET to Java, or from .NET to .NET Core or from Android to iOS, or from Native to Web apps (or vice versa).

One might think that such colossal changes do not occur very often, and it is true, but when they do, they can become a major problem for various reasons.

There have been several changes in target platforms over time:

Examples: Moving from Silverlight to Web, from Text to Windows, from Web to Native apps, from SOAP to REST, from RWD to PWA, etc.

• Changes on the same platform

What happens when there are changes in the same target platform or changes in design trends?

This is very common in the annual updates of mobile platforms.

Changes in programming languages are less frequent, but they do happen.

For example The evolution of Java.

Changes in user experience trends occur frequently on each platform. At times, they are small – at times they are big, but they exist.

• Changes in political, social or economic context.

At times, political changes have implications in the sphere of technology as well.

For instance: If you are selling a solution that uses a push notification provider that cannot be used in some countries, you need to have the flexibility to change Notification providers, Ads provider, Cloud providers, AI providers, etc.

I think it is quite complicated to assess all these scenarios through a POCh. However, I believe that, at the very least, we must use POCh to assess how a platform allows for small and big changes in business requirements.

A POCh could enable us to evaluate whether a platform helps to make our solution “future proof”. We don’t know what the future will be, but what we know is that we will certainly have to change business logic to adapt to evolving business requirements. So, we should take into consideration the following question:

How well can the platform that I will use embrace change?

I recommend that organizations undertake POC-POCh assessment of platforms instead of only a POC project; otherwise, the complexity involved in embracing change on the selected platform may become a barrier in aligning solutions with evolving business conditions.