Skip to main content

API Technical NFRs

Client projects have functional and technical requirements which are solved by looking at the desired outcomes and identifying which API calls and sequences of calls are needed to feed or retrieve data to and from external systems. Outside of these, there will be what are called Non Functional Requirements which integrators should be aware of and plan ahead for when delivering project's.

What is a Non Functional Requirement​

Anything which is necessary to support an implementation but does not directly deliver functional outcomes as described by business sponsors. Let's look at an example.

  • Functional Requirement : Ensure that downstream system A is updated with the latest Legal Entity Data after a Journey is Completed on Fen-X.
  • Non-Functional Requirement : Ensure that the Client Credentials used for API interaction only have the appropriate grant-types to achieve the specific outcomes needed by the client application.

The biggest difference is that business focused testing will explicitly determine the successful implementation of the first item, but often, this attention will not be given to the second item until much closer to an actual release date, so developers, project managers and other stakeholders should try outline their applicable NFRs up front to accommodate and plan for them.

Failure to accommodate for NFRs could breach a security policy and cause a project go-live delay. It may not get covered until a pre-go-live security gate review at which point it may be too late to accommodate in available timelines. This page will describe some common NFRs which clients can plan for when designing their Integrations.

Quick NFR Checklist​

  • Tenants / Not Environments Each tenant is separate. Can be thought of similar to traditional environments but some differences.
  • Tenant Specific Identifiers The configurations can move from tenant to tenant but the system identifiers will be different.
  • Security Configuration Establishing the security requirements for the tenants early as they will likely tier from softer to tighter towards production.
  • Integration Flexibility Your up and downstream Integrations will need to point at different tenants for different phases of the cycle.
  • Reporting and Monitoring The Fenergo SaaS platform is event driven and OOTB reporting may not cover all requirements, consumers need to decide what kind of MI data they need.
  • Data Migration Planning Data Migration is supported on all tenants but clients need to plan how they want to test and execute migrations along with which data they need to test.
  • Level of Data- Production data only allowed on production tenants. Gold State tenants can be provisioned at a cost to practice with real data in a non prod tenant.
  • Performance and Capacity SDLC and Production tenants are provisioned differently and also Vulnerability and Pen testing is performed as a service by Fenergo.

Detailed NFR overview​

Each of the items from the above list are explained in more detail below.

Tenants / Not Environments​

The Fenergo SaaS platform is a single code base, offered as a service. Clients get three SDLC tenants and one Production tenant. Each tenant is isolated from all other tenants, (including those belonging to other clients) no data is shared, can be transferred from one tenant to another or share data storage resources. ALL tenants are provisioned on our Production deployment. This is entirely standard for SaaS services but differs to traditional SDLC.

In a traditional software project, development passes through Environments. So code is tested in lower environments and promoted to higher environments. DEV UAT to Pre-PRODUCTION to PRODUCTION. This perspective does not need to change and clients can think of their assigned Tenants as Environments. Their respective Configuration and not Code is promoted from Tenant to Tenant via the Config Exchange Feature.

Considerations
  • For clients planning their software projects, they should be clearly aware of the different way to handle and configure each separate tenant.
  • SDLC tenants tend not to be secured to the same level as a production tenant. So users will have more permissions, the ability to action more tasks (for the sake of end to end testing). The plan for permission's and team structures should be tested and implemented in one of the higher tenants.
  • Client Credentials for SDLC tenants will usually have broad permissions instead of scope specific permissions. Production Credentials and strategy should be decided and planned for early.

Tenant Specific Identifiers​

Configuration for Policy, Risk, Journeys and Schedules can be moved from Tenant to Tenant. This is an extract and import mechanism where the target Tenant points to the Source and Pulls the configuration. This movement of configuration should be thought of in a similar way to how Code in a software project is handled, promoting from environment to environment.

Considerations
  • When a configuration is migrated, only the latest published version of that configuration is moved. Historical versions are not moved, and the entire configuration is created on the target as Version 1.
  • Clients need to think about and plan what their process is going to be for making changes, Where they happen and where they are tested then how they are then promoted to other tenants.
  • Config management could get difficult if that config is created and updated in more than one tenant. (adding new fields to a policy, new stages to journeys, new risk conditions). There is no way to merge multiple versions of the same config between tenants, so deciding the process up front will make the process easier to govern.
  • Plan for important Identifiers to be different. GUID identifiers are used throughout the platform, when the configurations are migrated, they will arrive with new identifiers on the target. If you are testing an integration in DEV and referencing a "Group Id" or a "Risk Model" these values should be updated as variables in your integration system.

Security Configuration​

There are different areas to think of with regard to security and access control. There is role based access control for UI Users along with Access Layers to protect sensitive data, then on the system to system side, client credentials can be configured with broad scope permissions and can use MTLS for added protection. Clients can also choose to bring their own key BYOK for data-at-rest encryption. In this regard, production is the only environment we recommend clients configuring to the highest level, as enforcing rigorous security settings on lower environments will likely impede development and testing.

Considerations
  • Decide on your BYOK policy, if clients want to do this they will need an AWS account (along with all their internal change controls). It is recommended this is only done for production. BYOK cannot be enabled AFTER the production environment is provisioned.
  • Design the Access Layers, Teams and the permissions for production, should be tested prior to go live in one of the SDLC tenants (whichever one is nominated as pre-production) but allow lower tenants to be more flexible. Broader permissions will speed up testing.
  • Decide if you want to use MTLS for the client credentials as the certificates need to be requested in advance. You should also test this in a pre-production environment before go-live and use environment specific certificates.
  • Clients can create their own CSRs to generate certificates.
  • Decide on how your systems will be integrating and use client credentials for systems which specify only the scopes that the system needs. This ensures that the system and its credentials is limited to accessing only the APIs it needs.
  • Ensure you have a credential with admin access for admin style functions or production investigation. In financial institutions these accounts tend to be strongly covered with change control policy's.
  • Performance and Penetration testing is performed by fenergo as part of the service offering. Clients are not permitted to conduct this analysis themselves. The results of these activities can be provided if required.
  • SSO (Single Sign On) if required will need to be enabled by the cloud business office for specific tenants. Clients may be content to just enable this in Production or may need it test it in UAT or other tenants.

Integration Flexibility​

When building integrations and codifying any operations against the APIs integrators will need to allow for different Tenant Ids that represent a different environment. The configurations will also have different identifiers so planning for extracting these id's as you move through sdlc stages.

Reporting and Monitoring​

The Fenergo SaaS platform comes with some OOTB reports that take a date range, and there is a subset of data returned in these reports, not the full record. Also as a hosted SaaS platform there is no access provided to application log files. Instead clients should look to the real-time notifications and polling as mechanisms to monitor and maintain sync with downstream systems.

Considerations

-Get familiar with the Notifications "Event Registry" as it covers all the activities clients may want to react to.

  • The detail in notifications can be used as a seed to further extract more information (such as the Legal Entity Id).
  • These notifications can also act as a way for clients to monitor activity in place of log files.
  • In client applications that are making API calls, clients can also log their request / response and response times.

Data Migration Planning​

Data Migration can be a very specific in terms of requirements from a client perspective. Fenergo provide the mechanism to load data onto the platform via APIs but this is quite different to typical Database orientated data migration style activities. There is no Snapshoting of target data stores or Rollbacks possible if mistakes are made with a migration. It is also an area of evolving functionality from a product standpoint and as new features are offered, clients will have even more options for how they choose to interact with Data. Data stores (such as the databases used on the Fenergo SaaS platform) are not directly available to clients, instead they need to use the Entity Data APIs and the Data Migration Functionality. Further still we advise a high degree of planning for a strategy of migration, testing in SDLC tenants and as much practice as is possible.

Considerations

-Data Migration has a tightly coupled dependency on the policy configuration. The policy being the target data model. Ongoing changes to the data model and policy will have to continuously be factored into the data migration preparation and planning.

  • Clients Target Data Policy might be different from their current data model, they may have less data fields available or other transformation might be required to craft the source data into a compatible migration candidate. Designing the target policy should include the mapping to current data sources including the availability and /or transformation requirements.
  • SDLC tenants are not provisioned with the same level of resources as production and do not support the same qty and allocation of resources. Threshold limits agreed at contract stage for Data and Document storage apply to the production tenant, SDLC tenants are expected to be kept minimal and not provided for volume testing. Migrations can be re-executed against the same LE data over and again which keeps the data volumes low. Clients can request "Gold State" tenants if they need to do volume testing at production level performance.
  • Practice and Designing a Data Migration is not about volume or real data, true the closer you get to real world data the more effective testing and confidence can be. But the Practice and Design can be done with good sample data coverage and in a way that does not breach the acceptable usage for SDLC Tenants.
  • There is a high level of flexibility available on the Data Migration Functionality. You can migrate subsets of data, and remigrate later with fuller data sets, you can choose to migrate only specific tranches of records and sequence and schedule your migrations over a timeframe that suits.

Level of Data​

Fenergo only supports real world data on the production tenant. Clients are not permitted to load or migrate real data onto SDLC Tenants. There is a higher degree of support and process placed on production tenants in terms of best practice and performance and it is not supported to place this same level on non production SDLC tenants. This could have a bearing on how clients plan to test journeys, data and data migration. If there is a requirement to test with real data (data which is not anonymous or obfuscated) this can be done on a

Considerations
  • SDLC tenants are likely to have looser controls around permissions and access to data which facilitates development and testing. They may also have direct Fenergo assistance (Fenergo users with access to the tenants) in creating and testing configuration where Professional Services have been engaged. Production Data in SDLC tenants will be handled as a data breach.
    • Production Data can be loaded to a "Gold State" Tenant, if one is required you need to plan ahead so it can be provisioned.

Performance and Capacity​

For software delivery projects, there can often be organizational requirements to perform load testing against a target application to prove that it can handle the planned capacity and growth capacity requirements. This is done as a service by fenergo and the results can be provided. The lower SDLC tenants are provisioned with lower resource allocations than production tenants. The Production SLAs and reports provided by us as a SaaS vendor are intended to satisfy the performance and capacity testing. If further space is required or more demand needed - clients can have a commercial conversation with their CSM or fenergo representative.

Considerations
  • Look for the Performance and Security Reports in advance to ensure they satisfy the organization requirements.
  • Discuss the planned capacity in terms of expected volume of LE Data, Documents, number of Journeys and ensure the selected Production tier meets your requirements.