Accelerate the Adoption of Software Products in Large Enterprises (especially Banking)

How successful software companies help their clients adopt their products at scale using an assisted and automated approach.

Successful software product companies, who build software to be consumed by software engineering teams at scale, look at the adoption/migration process of their products as an integral and essential part of their development process (and not as a sales function), to help their clients ramp up the consumption in an “assisted” and “automated” fashion. At the age of Digital Transformation, there are a ton of transformation initiatives currently underway, which combined with business-continuity programs caused by COVID-19 and also the compliance initiatives due to regulatory concerns imposed on Banking these days would make any model other than providing the ready-to-use and integrated patterns into the consumers’ ecosystem, an incredibly slow process.

A while back ago, I went through a migration process of a software product. The purpose of the exercise was to meet compliance and risk measures of a large organisation due to the poor performance of its infrastructure, which was deeply embedded within our engineering ecosystem. As the consumers of the product, and owner of a large software platform, we had to go through hundreds of solutions to upgrade the integration points, and even though the product was adding concrete value in terms of functionality, tooling and end-user experience (i.e. software engineers), the rate of adoption was considerably slow.

The main challenge, however, wasn’t with the product itself, but with the fact that the entire burden of the migration was put on our shoulders, as the consumer team, to find time and capacity to adopt the new tooling, while managing our non-stop and ever-increasing daily BAU delivery workload to develop and deliver new features. Despite all the pressure from the product owners, to adopt the new product and decommission the old one, no-one migrated as simply the initiative was too big, and not “assisted”.

It was up until the time that the product owners came up with automated tooling, a support process, and the man-power, to make the journey easier for their clients, that we gradually started to adopt their new versions (which for us was a breaking change and needed substantial amount of work).

Regardless of how committed you are to help your consumers to learn about the new product and how great it is, at the end of the day, delivery teams on the ground who will consume the product, will have to prioritise their daily routine over the adoption of new tooling, and unless the adoption process has been made so easy for them, it will be de-prioritised over and over again.

At the age of Digital Transformation, there are a ton of transformation initiatives currently underway, which combined with business-continuity programs caused by COVID-19 and also the compliance initiatives due to regulatory concerns imposed on Banking these days any model other than providing the ready-to-use and integrated patterns will just slow down the adoption process.

In my view, the process of product adoption by large engineering teams needs an active engagement with delivery teams on the ground in addition to making the provisioning and the consumption of the product as smooth and automated as possible, so they can embed and use the new product with the least possible friction.

In the current situation, it may not be enough to assume that building a great product by itself will attract consumers organically without an “assisted” operating model (that covers the below areas) to help the clients ramp up the consumption and integration into their ecosystem (Figure 2).

Figure 2 — Key Areas of Impact for Product Adoption

Looking at the problem from the end-user pov, it will be much much easier if we provide support and solutions in the below areas to make it super easy for the clients to adopt our product at scale. Considering how repeatable/reusable these solutions are for your entire client base, the cost of developing and providing these custom patterns and practices will be minimal compared to the revenue generated by the exponential rate of adoption by each client.

Adoption Operating Model & Support Program

• as a technology leader, while using the product, I have access to a persistent team onsite, with engineering and architecture leadership representatives, to help me with the designs and best practices
• as a technology leader, I can attend a regular forum held by the product team, so I can raise concerns and share solutions with my peers across the bank
• as a developer, I know the process to raise technical issues, to help me solve my challenges immediately
• as a developer, I can attend regular presentations/guilds, held by an Onsite Collaboration Station, to help understand the product’s new features

Consuming the Product

• as a developer, I can connect to/consume the product from my Local, Dev, and Test environments with no issues
• as a developer, I can diagnose/debug product-related issues on my machine, so I can unblock myself as fast as possible
• as a technology leader, I have received security and networking sign off, so my engineers can deploy change to production with no delay

Developer Machines — SOEs

• as a developer, my machine comes with the product pre-installed, so I don’t have to chase other teams to install the product for me
• as a developer, I can have a seamless experience on my machine, regardless of the company’s endorsed/hardened OS images (Mac/Win/etc.), so I can focus on my feature delivery rather than dealing with OS related issues
• as a developer, my machine comes with pre-configured network connectivities, so I can access internal/external assets connected to the product

App/Api Automated Provisioning

• as a developer, I can provision new Apps/APIs with the product integrated into the scaffolds, and it will work on my machine with no issues
• as a developer, I can access the product’s best development practices baked into the auto-generated scaffolds

Tooling

• as a technology leader, the product has been integrated into our ecosystem, so it is consistent with our existing tooling patterns and non-negotiables

Reference Architecture

• as a delivery team, there is an endorsed ref architecture on how to consume the product, so the decision to choose the product will be smooth with no objection
• as a delivery team, we have a clear idea of identity and access management patterns for the product, and it will need minimal engagement/sign off moving forward

Transformation/ Migration

• as a delivery team, we have assisted migration tools and processes available, so we can migrate/modernise our apps and port them to the new product
• as a delivery team, we are aware of the product offerings/constraints and what is involved, so we can transform our applications accordingly

Enterprise Patterns/ Continuous Delivery Pipelines

• as a project manager, the product has been integrated with our logging/monitoring systems, so the adoption won’t impact our end to end delivery budget
• as a developer, the product has been already integrated into our CI/CD codified/declarative pipelines, so we spend minimal time/budget on sprint-0 tasks
• as an automation tester, the product has been integrated into our QA pipelines, so I can start writing tests against it from day 1
• as a developer, deployment of the product to Non-Prod environments has been automated and integrated with our pipelines, so I won’t have to perform separate manual deployments
• as an Ops engineer, the product has been integrated into our automated stg/prod run sheets, so no extra configuration is needed for go-live
• as a developer/delivery team, the product is available and accessible on the legacy and modern hosting infrastructure, so our project won’t be blocked if we chose to adopt the product
• as a developer/PM, we have sufficient level of controls embedded in our group/security control repository for the product, so our deployment will pass all group attestations and non-negotiables
• as a Product Owner/PM, the product CI records have been configured in our CMDB, so we won’t be blocked by ITSMO and Service Management to go live
• as a team, in case of problems, it is clear who to engage and how, through the enterprise communication and ticketing systems such as Jira/MS Teams/Slack etc.

Pricing/Licensing Cost

• as a group, there is consensus that the product pricing is considered fair compared to its value, so a solution design that onboards the product is considered logical and affordable at scale

Pellerex Foundation: For Your Next Enterprise Software

How are you building your current software today? Build everything from scratch or use a foundation to save on development time, budget and resources? For an enterprise software MVP, which might take 8–12 months with a small team, you might indeed spend 6 months on your foundation. Things like Identity, Payment, Infrastructure, DevOps, etc. they all take time, while contributing not much to your actual product. These features are needed, but they are not your differentiators.

Pellerex does just that. It provides a foundation that save you a lot development time and effort at a fraction of the cost. It gives you source-included Identity, Payment, Infrastructure, and DevOps to build Web, Api and Mobile apps all-integrated and ready-to-go on day 1.

Check out Pellerex and talk to our team today to start building your next enterprise software fast.