How does an API Blueprint help kickstart my Open Banking / PSD2 Program?

A Blueprint is a great way to kick start any API Program. You can read about it here and see the spec sheet here.

Each Blueprint is tailored to the needs of the customer, but a typical engagement will cover the many Best Practices. Below is a description of each session and how it may relate to a Banking API Program.

Apigee Product Overview

  • An introduction to the Apigee Ecosystem including Edge, Developer Portal, Analytics, Monetization and others.
  • Interested parties including Executive Sponsors, Development Team, Product Owners, Operations and Support are all welcome.

Accelerator Methodology Overview

  • An introduction to the Accelerator Methodology, starting with the Blueprint, that will allow you to adapt to changing requirements whilst meeting regulatory deadlines.
  • Development Team and Product Owners are required. Interested parties are welcome.

Delivery Methodology

  • A discussion on the delivery approach. This will cover Scrum vs Waterfall and Behaviour Driven Development. This session is a prerequisite for going into Sprints after the Blueprint.
  • Development Team and Product Owners are required. Interested parties are welcome.

governance

  • How to manage multiple API teams within your organization. This is essential when your API Platform grows to ensure that you balance Teacher, Policemen and Referee roles within your model. This session will allow you to enforce security/regulatory requirements across all teams, such as OAuth 2 Validation, Logging or Traffic Management.
  • API Platform Owners are required. Development team are recommended. Interested parties are welcome.

High Level Requirements Capture

  • Discussion of the requirements of APIs to be implemented in the first 3 sprints. This is likely to be PSD2 Compliant Identity and Banking APIs.
  • Product Owners and Development Team are required. Interested parties are welcome.

Functional Requirement Scoping

  • Discussion of the functional stories to meet the high level requirements. For PSD2 these will include ability for a user to delegate access to their banking data to a third-party, as well as a discussion on the resources to be exposed.
  • Product Owners and Development Team are required. Interested parties are welcome.

Non-functional Requirement Scoping

  • Discussion of the non-functional stories to meet the high level requirements. This will include any SLAs required for regulatory compliance, including maximum response times and % uptime.
  • Product Owners and Development Team are required. Interested parties are welcome.

Deployment

  • How to automate the deployment of an API Proxy to an environment using a build tool such as Maven.
  • Development Team are required. Interested parties are welcome.

Mocking

  • Discussion on mocking backend systems in order to remove dependencies and allow for rapid API development, as well as test isolation, It may also be required to mock the central registry whilst it is still under development.
  • Development Team are required. Interested parties are welcome.

Testing

  • The use of behaviour-driven and test-driven development to automate the quality assurance process.
  • Development Team and Product Owners are required. Interested parties are welcome.

Source Control Management

  • Storage of code and branching strategies, required to enable multiple developers to seamlessly work on the same codebase.
  • Development Team are required. Interested parties are welcome.

Continuous Integration / Delivery

  • The use of tools such as Jenkins to deploy and retest API Proxies on each code change. It is also possible to automate the promotion of code between environments.
  • Development Team and Product Owners are required. Interested parties are welcome.

Artifact Reuse

  • A discussion on the mechanisms used for sharing code and managing dependencies between multiple proxies whilst maintaining quality. This is very useful to ensure you don't reinvent the wheel when validating third-parties against a registry, validating access tokens or logging data from each proxy.
  • Development Team are required. Interested parties are welcome.

Traffic Management

  • A discussion on the use of Spike Arrest and Quota policies to manage the amount of traffic for an API Proxy. As your APIs will be on the public internet it is important to protect them from attacks. This topic is also important for understanding Monetization of your APIs.
  • Development Team and Product Owners are required. Security teams are recommended. Interested parties are welcome.

Analytics

  • A discussion on the types of data that are permitted to be stored in our Analytics engine. This allows you to analyze how Third Parties are using your APIs and respond accordingly.
  • Development Team and Product Owners are required. Interested parties are welcome.

Storage

  • The use of caches to improve API response times, which will reduce load for public APIs such as Branch Locators and Product Information. We also cover the use of Key Value Maps to store environment specific configuration.
  • Development Team are required. Interested parties are welcome.

Security

  • The use of OAuth 2 and Open ID Connect within Apigee, as well as North/Southbound TLS, Data Masking and Role Based Access Control. In my opinion this is the most important session of the week to establish the Best Practices to be followed.
  • Security and Development Team are required. Interested parties are welcome.

Organizations, Environments and Roles

  • How should organizations and environments be divided to ensure that Production access is restricted and that a suitable Development Lifecycle can be followed.
  • Development Team and API Platform team are required. Interested parties are welcome.

Auditing, Logging and Monitoring

  • A discussion on operations team's management of the APIs once they have reached production.
  • Operations and Development teams are required. Interested parties are welcome.

Maintenance and Support

  • A discussion on which elements of the solution are managed by your API development team and what the responsibilities and SLAs of the Apigee Support team are.
  • Operations and Development teams are required. Interested parties are welcome.

RESTful API Design, Versioning and Error Handling

  • How to build APIs that third party developers are comfortable using (probably without looking at your documentation!). The quality of your API Design reflects your brand and it is important to follow patterns that third-party developers will expect.
  • Existing standards such as ISO20022 existing for banking data interchange, however they are not RESTful. We will discuss the leveraging of these standards in a RESTful way.
  • API Architects and Development Team are required. Interested parties are welcome.

Performance Testing

  • In preparation for Go-Live, how can you be confident that your API will stand up to production traffic? What are the typical failure scenarios?
  • Development Team are required. Interested parties are welcome.

Developer Engagement

  • A discussion on the journey for a Third Party Developer to explore your APIs, test them in a sandbox and register from credentials using the Developer Portal. By publishing 'Innovation APIs' alongside mandatory APIs, you may attract more developers.
  • Product Owners and Development Team are required. Interested parties are welcome.

Executive Touchpoint

  • A reflection of the progress made throughout week to the Executive sponsor.
  • Interested parties including Executive Sponsors, Development Team, Product Owners, Operations and Support are all welcome.
Version history
Last update:
‎06-28-2017 10:23 AM
Updated by: