The Move to SaaS and the Role of Technical Advocacy in Fenergo

George McGrane

Introduction

As a Technical Advocate for SaaS Engineering here in Fenergo, my goal is to help our technical consumers get the best from our platform. For over 10 years our products have been helping to protect our clients in adhering to an evolving list of regulatory obligations and our latest CLM platform continues to deliver that protection but as a fully Cloud Native, API First SaaS solution.

Through our own SaaS transformation, we know what that change of strategy means for our clients and in this post I’m going to touch upon the kind of topics and subjects we have encountered as our clients also transform and adopt SaaS.

Introduction - Where We have come from?

For any successful software product company, it is an accepted fact that the product does not stand still. It evolves, almost organically, with the aim to deliver the best technological capabilities whilst meeting equally evolving expectations of clients.

In Fenergo we are used to responding to a changing technical landscape. Every client represents a nuanced yet subtlety different version of an Enterprise Landscape. Historically, these environments are where our products were deployed, and they belonged to; and were the responsibility of; our clients and their operations teams. SaaS has changed all that.

Changing Drivers

A confluence of circumstances has accelerated the adoption of cloud products and services, to the point where now, our clients in the Financial sector, are more open than ever to meeting their needs with cloud solutions. Examining the key business drivers behind cloud is well trodden ground, reduced TCO, speed of delivery and shifting the responsibility for platform ownership to a vendor. These all enable Financial Institutions to focus on the values and benefits rather than the management overhead that comes from provisioning on-premises software.

One key area which proves challenging for FIs is the high-water mark of responsibility they face as their enterprise software requires a bulletproof approach to security, resilience and compliance. FIs cannot be trendsetters, however attractive the technology. Cloud maturity, compliance to standards and strong data protections have de-risked these challenges.

This Cloud thing is not New – It has been around a while

The coining of the term “Cloud” can be traced back to 1994. Andy Hertzfeld (who was a member of the original team that created the first Apple Mac) described a programming language called Telescript that allowed client devices to upload code to be run on remote servers. Andy described these servers as a “Cloud of Places” (Telescript didn’t last). Then in 2002 Amazon created “Amazon Web Services” and in 2006 they offered their first service in the shape of “Simple Storage Service” (S3), followed rapidly by Elastic Compute Cloud (EC2) and to be fair. . . That Did Last. This was so much more than a server hosted in a Data Centre, it was more indistinct than virtualisation and consumers who were used to owning and managing hardware needed to shift their mindset to a shared-responsibility model.

The biggest difference between then and now, aside from the rich suite of service offerings (currently well beyond 200+ services from AWS) is platform maturity. Maturity has addressed many barriers of adoption which previously inhibited Financial Institutions from migrating their workloads onto the cloud. Cloud platform operators and SaaS vendors like Fenergo have been lifting those barriers by focusing on security, stability and resilience in the cloud space, so FI’s are now well positioned to start reaping the benefits that SaaS vendors can offer. Fenergo put Trust and Security front and centre, with significant efforts employed to earn and retain externally validated certifications which prove industry best practices are in place.

What’s the impact of SaaS on Technical Engagement?

It’s amazing how fast clients can get started when there is no need to provision infrastructure along with dependant software perquisites, network configuration, data stores and access controls. What once required and involved (expensive) engagement from multiple client teams, can be made available in minutes. The desired outcome is no different than before, client users need access to a running application from within their environment, but the means by which it is achieved is incomparable to equivalent on-premises solutions in terms of simplicity and speed. So, when a Fenergo technical SME interacts with clients, the focus is at once on the requirements and how to achieve their outcomes. A vast tranche of the technical NFRs are eliminated up front because SaaS shifts the responsibility to Vendor.

Config First

Two core principles that Fenergo adhered to when creating our SaaS Platform are Config First & API First. We might have the best process models and data structures, reflective of industry best practice, but clients will ALWAYS want to put their own stamp on it. How their business works and what information they gather is often unique on a client to client basis. So self-led frictionless configuration was a critical success factor for our SaaS solution. It needed to become a trivial activity for clients to adjust and re-adjust their configurations. Now instead of a requirement assessment following an SDLC and deployment process, a configurator can implement, workflow, data model or risk changes with a few clicks. They are using the platform to reflect their way of doing business and supporting that activity in a responsive, agile way. Better still, it can be done without any vendor dependencies.

API First

With API First, things really start to get interesting. When an API interface is added to an existing application to facilitate an integration, even a well-designed API is still just adding a feature to a product. Setting aside APIs, software engineers are creative people, and exposing embedded functionality from applications has resulted in solutions like RPA, Screen Scraping or DB interactions. These have always been impure stopgaps that try to smooth over legacy limitations or poorly designed systems.

Turning this situation on its head, where an API (or catalogue of APIs) is the Product, exposes the broadest range of possibilities. Consumers are not limited to a specific intended purpose but can create integrations which use API building blocks to achieve a diverse set of programmatic behaviours. This results in more options for how to work with application capabilities and clients can use APIs to create their own unique or custom experiences. The core implementation is still the same, but the applicability is far broader. With API First, your Application User Interface of your product becomes a lightweight wrapper around the APIs because its the APIs which are the product.

Permanence with API First

API First offers permanence when publishing functionality. You likely know explicitly what you are doing with your APIs on our own User Interface, but when an API is released, there is no way to tell what a client might be doing. Furthermore – client implementations built against your APIs will use that functionality for a long time. This means a diligent design strategy must accommodate how an API can scale and continue to perform under future state thresholds. As an API vendor you are never simply designing for today’s data and usage volumes but looking to the future at how volume and demand might affect behaviour. A strong commitment to durability and performance is made when publishing API functionality, because those API contracts are what clients implement their business logic on and the availability of that functionality is part of a SaaS vendors commitment to their clients.

Finally – How Does a Technical Advocate Help?

As mentioned, my goal is to aid our technical consumers in getting the best out of our platform by helping them to understand its capabilities. Sometimes you need to explain what SaaS is not, how it differs from traditional software solutions as well as what it is, and the features which are available. But where I am seeing the greatest success with clients, is where they have embraced the SaaS paradigm, ventured out independently and crafted their own solutions and experiences on top of our APIs.

In my role I spend time creating documentation, training material and engaging with Project teams to help them get to creative outcomes, but once a consumer has invested some time to learn the capabilities of the platform, they are best suited to see where it can be most beneficial within their own environment. It’s up to an API producer to make the knowledge and information about a product available and easily accessible, but its when clients use that to build their own successful implementations without direct help, that’s a real success story.