April 9, 2021

Six Software Design Principles That Make PortX a Financial-Grade Integration Platform

by Kent Brown in API Management , Banking Core Integration , Cloud , Fintech , Open Source 0 comments

The PortX Integration Platform is our integration hosting platform focused on connecting applications for financial services companies of all sizes. PortX is different from your standard run-of-the-mill iPaas in that we purpose-built it as the “integration platform for the rest of us.” What do we mean by that? Developers are a scarce resource that should be focused on the critical initiatives that move the business forward – not necessarily integration work. PortX was designed to be intuitive enough for business users and analysts yet robust so that your developers won’t roll their eyes. In this blog series, we will share the technical principles that we adhere to in our design and development of this unique integration platform.

Defining “financial-grade”

Before we cover the technology choices, it’s important that we first establish the design goals of the PortX platform. The first assumption we made was that our customers would require innovative financial-grade software solutions. The term “financial-grade” comes from the OpenID Financial-grade API Security Profile 1.0 Baseline and we applied it more broadly across all aspects of our platform, not just API security protocols. We define “financial-grade” as creating enterprise-grade financial services-related technology solutions that are critical to the success of your business and your customers. 

12 high-level requirements for financial-grade software

The high-level requirements for developing financial-grade software are broken into two categories. Investment-related requirements are those related to measuring an organization’s expected ROI from a product. Operations-related requirements are those that scale performance and help move the business forward.

Investment-related:
  • Affordable – This is one area where we differ from the typical “Enterprise-grade” software because that designation usually equates to BIG $$$$. However, we don’t believe that should be the case because we are in the business of driving access to financial services.
  • Productive – You want to move as quickly as possible, not bog down your developers with unnecessary complexity.
  • Flexible – You want to build in a way that lets you grow, change the feature set, and evolve to create new solutions as your business matures.
  • Scalable – You may start small, but if your solution is successful you need to know that the system can gracefully grow to handle the increasing load.
  • Long-lived – Building software takes a lot of time, effort, and money. You want the solutions you build to last. They need to survive the waves of innovation that will inevitably come. And they need to be something you can build upon, rather than needing to constantly start over. 
  • Portable – You also need to have flexibility in the underlying infrastructure and supporting services as the market evolves. You don’t want to be held hostage by any particular vendor.
Operations-related
  • Secure – Hijack attempts continue to grow in volume and level of sophistication. The financial services industry is one in which a business cannot afford to allow that to happen.
  • Highly available – Your customers depend on this solution and could go to a competitor if it fails often.
  • Resilient – The system should automatically detect and correct common failures as often as possible, minimizing the manual effort required.
  • Manageable – You need a way to monitor the system you’ve built, understand how it is performing, and address changes and issues.
  • Repeatable – You need to be able to push the deploy button often and without fear of breaking things. You can’t afford to risk downtime when releasing an update.
  • Audited – The ability to control who can make changes and keep an accurate record of those changes is necessary for the accountability required for supporting financial services solutions.

Six modern software principles and practices

The requirements above are challenging for even the most sophisticated development teams. Unfortunately, they are even harder for the smaller teams that are common among community financial institutions.

Thankfully, the current state of software development and execution has progressed leaps and bounds in the past 10 years to address these kinds of requirements. You’ll hear buzzwords like “microservices,” “cloud-native,” and “infrastructure-as-code.” If you want to sound really smart, you might throw in a “containerization” or “Kubernetes” into the mix.

However, financial-grade software must go beyond the buzzwords. We’ll share how we design our products based on six modern software principles and practices that deliver on the requirements for financial-grade software.

Cloud-hosted 

At this point, the benefits of leveraging the cloud are well-known and well-documented. For financial institutions the main advantages are:

  • Faster time-to-market
  • Reduced capital costs compared to acquiring on-prem infrastructure
  • Reduced personnel costs compared to maintaining on-prem architecture
  • Increased security. A common first reaction is to question the efficacy of security in the cloud. In reality, the public cloud platforms have far more dependable security across the board (physical, network, access control, scanning and intrusion detection, compliance and certification, etc.) than you will likely be able to achieve on-prem.

Delivers on: affordable, productive, flexible, secure, scalable

Cloud-native

Hosting in the cloud presents big benefits. Unfortunately, you cannot expect the same success with software that was built on outdated models and migrated to the cloud. The term Cloud-native means you’ve architected your software from the ground up to take advantage of the scale and resiliency of the cloud. 

Docker & Kubernetes (K8s) are at the heart of the ecosystem of tools that develop cloud-native software. Docker acts as the unit of packaging for deployment, allowing you to include all dependencies. This eliminates possible variation due to the runtime. Kubernetes provides the orchestration of the deployment process in a scalable and highly available method. It allows you to detect and react to unhealthy states of your service. For example, it will restart the service if it becomes unresponsive, and wait to route traffic until the new instance of the service is up and ready.

The Cloud Native Computing Foundation (CNCF) defines many standards and tools that support the building, deployment, and running of cloud-native applications. In many ways “cloud-native” is “software-as-a-service.” The Twelve-Factor App is a set of software design principles that help build reliable cloud-native applications. 

A lot of good programming languages will enforce good programming practices through the compiler; this helps support the disciplines that prevent common errors from getting into production code. In a similar way, we designed PortX to help you follow the 12-Factor principles in the applications you build. It’s built-in assurance that you are developing financial-grade software. Here are some example requirements:

  • All secrets must be stored in a secure secrets vault, externally from the main infrastructure configuration.
  • Health checks – Every service deployed to PortX needs to support liveness and readiness probes so that K8s can properly coordinate deployments in a resilient manner.
  • Resource limits – In order to make efficient use of cloud resources, you need to test your services and configure the min and max resource requirements for memory and CPU.
  • Observability – In order to properly manage your production applications you need visibility into the health and operation of your services. We require your services to publish logs as streams according to the 12-Factor principle and we collect those streams into work class observability tools.

Delivers on: secure, scalable, highly available, resilient, manageable

If you want to learn more about Docker and K8s, check out Are Envoy-Based Kubernetes Ingress Controllers the New API Gateway?

Open source

Open Source Software (OSS) does not have to mean sacrificing the same level of support that big, expensive “enterprise software” is known for. In reality, the reverse is often true – the best open source technologies have broad user and developer communities and are more actively evolving than many traditional proprietary technologies. And, as a customer, you often have the flexibility to purchase support for the areas where you really need it. Additionally, building on solid open source technology with broad adoption and participation allows you the freedom to run your software as you see fit, without being trapped by proprietary licensing agreements.

We’ve curated a set of broadly adopted, well-supported OSS tools and technologies that we feel best support building financial-grade integrations. This lets you hit the ground running, knowing that the different components have been chosen and tested to reliably work together for your solutions. However, unlike many integration platforms that lock you into hosting only their proprietary integration frameworks, our hosting infrastructure allows you to leverage other OSS components as long as you follow best practices utilizing Docker containers. 

Delivers on: affordable, portable, long-lived

Infrastructure-as-Code

Infrastructure-as-Code (IaC) is the discipline that requires all aspects of an application deployment, from the underlying infrastructure (servers, networking, load balancers, etc.) to the applications themselves, to be specified in “code” – never by an admin clicking manually on a user interface. The “code” used for IaC is typically Terraform, K8s manifests, Helm Charts, and others that are all widely adopted components of the Kubernetes ecosystem. GitOps extends IaC by making sure everything is driven through a Git repository. This gives you complete repeatability, security, and auditing, as well as the reversibility of deployments through pull requests.

PortX’s underlying hosting platform is built and deployed with GitOps from the ground up, providing consistency of platform upgrades and handling disaster recovery reliably. In addition, by requiring all solution deployments to go through FluxCD, we ensure that your applications will be IaC/GitOps as well. PortX simplifies this with samples and documentation so that you don’t need a Ph.D. in Kubernetes.

Delivers on: highly available, repeatable, secure, audited, portable

Standards-based contracts

A big part of ensuring portability is creating contracts based on industry standards at the boundaries. We’re not necessarily talking about the big “S” standards; often, de facto standards are more useful than de jure standards.

For example, public cloud providers can rise and fall over time, and you might decide to change hosting providers for a better price or better features or possibly even bring your infrastructure on-prem at some point. We believe that Docker and Kubernetes are now solid industry standards for deploying applications. As long as you can package your solutions as Docker images that can be configured and deployed into Kubernetes, you’ll have plenty of options for hosting your applications over time. 

Similarly, with a FluxCD Git repository as the contract for deployment into PortX, you have full control over your CI/CD process and tools. We like GitHub Actions for most things, but our products don’t dictate that. If you can push a quality Docker image to a container registry and put the K8s config in the FluxCD repository, PortX will host it.

PortX uses the same approach in its Identity and Access Management design, focusing on OAuth and OpenID Connect as the protocols and supplying our preferred open source components to implement it. Since PortX uses the same standard protocols as most identity and access management solutions, you can substitute for your preferred IAM system.

Delivers on: flexible, portable, long-lived

Multi-architecture

When it comes to organizing and architecting your applications, we provide some opinionated options that help you adhere to best practices, while maintaining the flexibility to support applications with a wide range of requirements. Today’s industry consensus is a preference for RESTful APIs and cloud-native deployments, but there are different application architectures that make sense under different circumstances or requirements. Here are the core architecture patterns we support:

  • API-led – This architecture is best if you want to achieve efficiency through reuse and you have a large number of Line of Business (LOB) applications without many RESTful APIs. It recommends a three-tiered architecture where all LOB systems are made more accessible through “system” APIs. The business logic is implemented in a middle layer called “process” APIs. Lastly, specific applications connect via an “experience” API layer that simplifies the interaction for the application. API-led architectures typically emphasize synchronous HTTP-based REST calls between APIs.
  • Microservices – This architecture emphasizes decoupling each service and aligning code with the data it uses so that each service can be evolved and deployed independently. Microservice architecture often makes less use of layers, essentially combining the process and system layers. This makes it easier to handle transactionality in a single layer because the data store is usually a database rather than a legacy LOB system. 
  • Event-driven – This architecture is a common refinement of the microservices pattern to leverage event streams using something like Kafka. It’s a way to decouple different cooperating APIs and better support asynchronous and parallel processing.

Delivers on: flexible

Where do we go from here?

Modern software principles and practices can be inspiring. The industry has made a lot of progress and promises of success. However, you and your team may become overwhelmed by everything there is to learn and master to effectively leverage these practices. Much in the same manner that fancy, trend-setting (yet often impractical) fashions designed in Paris or New York take time to enter mainstream use, not every software team has experienced the benefits of this evolution driven by pioneering developers in areas like Silicon Valley. 

At ModusBox, one of our goals is to help democratize these capabilities with our software. Our own team has spent years learning these principles and practices and helping our customers adopt them as well. Through these experiences, we’ve seen vastly differing levels of maturity, especially in our small-to-mid-size financial institution customers. That is why we built the PortX Integration Platform with both the technical capabilities and a firm commitment to these modern practices and tools. They act as guardrails to make it easier for our customers to develop and release financial-grade software solutions and progress as quickly as possible along the maturity curve.

Think of ModusBox and the PortX Platform as your Teaching Assistant – we’re working on our Ph.D. and using our learnings to help you on your journey. Over the coming months, we will continue to share in-depth articles on each of the six software design principles we follow for building financial-grade PortX solutions. To learn more In the meantime, visit our PortX platform overview page or contact a member of our team today.


Leave a comment