The Payment System vision/scope presented below is a fictitious solutions concept for a fictitious company ([Nakatomi]), that calculates and makes payments to third parties. It's purpose is to demonstrate my consulting abilities, engaging with all stakeholders to formulate and drive project vision and scope, to elicit requirements and manage risk, thus enabling successfull outcomes for the client.
Whilst this document describes an imaginary payment system, it draws on my industry experience - from aerospace and defence, to retail, finance, public sector, telecommunications, and medicine, amongst others.
Any errors in this document are my own.
The [Nakatomi] Payment System proposes the development a single solution that calculates and makes payments in response to payment requests from third-party payees.
The payment system should:
The diagram below depicts the conceptual architecture of the proposed Payment System. It identifies high-level system components and their relationships, discussed in greater detail below.
Figure 2.1 - Conceptual Design
The proposed solution consists of the following -
Client applications present user interfaces. They are web-based, and are to be hosted within the extant on-premises hosting environment.
The application sub-systems implement [Nakatomi]'s core business processes required to manage, validate and process payment requests. Each system is implemented as a service with a distinct end point. Individual services are tied together using the messaging service (see below), which routes payment requests to the appropriate endpoints.
System components manage general, cross cutting governance and security concerns for all components of the Payment System.
The proposed solution is based on a messaging model, in order to provide the greatest flexibility and to support system extensibility. The collection of messages within the Payment System represents the state of the Payment System at any time. A message consists of an envelope containing message-handling meta-data, and the message payload (a payment request).
A message is unaware of its payload, which is encrypted. However, messages are routed based on the message-handling meta-data, which might indicate message state, its point of origin and destination, and the message access control list.
Figure 2.2 - Message Structure
The item type and status are used to route a message through the Payment System. Item types conist of -
Status-based routing scenarios for messages include the following:
Each message has an access control list, which authorizes access to the enclosed item, and an item status which, when changed, instructs the messaging system to route the message to the appropriate endpoint within the system.
A message can be saved to a database, or serialized to a file system. Because the message payload is encrypted, anyone opening a message cannot read its content without first authenticating him- or herself with the Payment System, and then being authorized by the access control list.
Payments vary in structure and content, based on payment type. Payment request forms may also change over time, and the workflow and business rules associated with payment request forms and payment validation may change over time.
To address the requirements of flexibility and extensibility, and in anticipation of later change requests, payments forms will be based on form templates. Templates describe the content of payments in terms of name/value pairs. The name provides a label for the value, which is entered by the payee. Name/value pairs can be linked to business rules, which are used to validate payments.
Payments also require meta-data, required to route payments, validate their content, and to apply payment rates during payment calculation.
Lastly, to facilitate payment assessment, payments must be annotatable, images and supporting documents must be added to payments as attachments, and a log must be maintained to track changes to a payment request over time.
This payment data, including its meta-data, is contained within a single logical entity. The entity is defined, as described above, by a template. The figure below provides a logical representation of payments, and the extensible template that defines them.
Figure 2.3 - Payment Structure
Web applications enable browser-based access. The browser creates HTTP requests for specific URLs that map to resources on a Web server. The server renders and returns HTML pages to the client, which the browser displays. The core of a Web application is its server-side logic. The application can contain several distinct layers. The Payment System will make use of a typical three-tiered architecture comprised of presentation, application, and data layers. Figure 3.1 below illustrates a typical Web application architecture with common components grouped by areas of concern.
Figure 3.1 – Client applicationsThe Payment System contains the following web-based client applications, discussed in further detail in the sections that follow:
A service is a public, typically web-based interface that provides access to a unit of functionality. Services provide programmatic functionality to the caller, who consumes the service. Services are loosely coupled and can be combined within a client, or combined within other services, to provide functionality that is more complex. Services are distributable and can be accessed remotely as well as locally.
Services within the Payment System are message-oriented, meaning that service interfaces are defined by WSDL files, and operations are called using Extensible Markup Language (XML)-based message schemas that are passed over a transport channel (the network). Services support a heterogeneous environment by focusing interoperability at the message/interface definition layer. Assuming a successful authentication and authorization, if components can understand the message and interface definition, they can use the service regardless of their base technology. Figure 3.2 below shows an overall view of the services application architecture proposed for the Payment System:
Figure 3.2 – Service applications
[Nakatomi]'s Payment System contains the following applications and services, discussed in further detail in the sections that follow:
The Registration client application provides a user interface for payee registration.
The Payment Submission Application is a multi-purpose web client application that allows its users to submit payments, correct and re-submit faulty payments, monitor payment progress through the system, and obtain financial and usage reports. The Payment Submission Application is a web application that consists of user interface, application and data access components. The application makes use of payment submission and validation workflows. It submits payments to the payment submission system (see section 3.7 below), and displays all notifications and reports required by payees, and their respective assistants or representatives to manage payments.
The Payment Assessment Application is a web client application used by auditors to validate and verify the completeness and correctness of payments.
[Nakatomi]'s auditors use the Payment Validation Application to:
In addition to the above, [Nakatomi]'s assessors use the Assessment Application to mark and annotate payments, add supporting documentation, view payment history, and to send messages to other stakeholders (other assessors, domain experts, amongst others).
The Assessment Application is a web application that consists of user interface, application and data access components. The application makes use of payment assessment and validation workflows. It retrieves payments from the validation system (see section 3.8 below), and displays all notifications and reports required by assessors to validate payments.
This is the system that ties all Payment System components together. The Messaging System routes payments, messages and notifications, and supporting information between assessors, payment system, and supporting systems such as document management and archiving.
Figure 3.3 - Message Channels channel
As described in the Information Architecture above, messages contain two types of information – the message-handling meta-data and the message content (payload). A message is unaware of its payload. However, messages are routed based on the message-handling meta-data, which might indicate the state of the payment, the payment type, its point of origin and destination, and the message access control list.
Figure 3.4 - Dead letter channel
The Messaging System makes use of the Security Service to encrypt and decrypt message content. It makes use of the Operational Management Service to log changes made to message content, and to log a message’s progress through the Payment System.
Messages that cannot be routed to an appropriate endpoint within the Payment System (due, possibly, to missing meta-data or unexpected message corruption) are sent to a dead letter channel, where an administrator can inspect the message and take appropriate action.
The Registration is responsible for on-boarding payees, and consists of tradional add/change/archive/delete functionaltiy.
The Payment Submission Service accepts new and re-submitted payments from payees. The system also provides second-line, automated payment validation by checking payments for completeness and correctness. Payments that contain missing information are returned to the payee. Payments that meet its quality objectives, or require manual assessment, are forwarded to the Payment Validation System.
The Payment Submission Service also validates payments received from external systems, such as [External System Name].
A payment has a finite lifecycle – assuming all goes well, it is created, submitted, validated, submitted for payment, paid, and ultimately archived. The diagram below describes the payment lifecycle from a systems perspective, and shows the states a payment undergoes during its life cycle.
Figure 3.5 - Payment Processing System
The Payment Processing System effects payments based on payment instructions obtained from the Payment Calculation Service. Payments are submitted to the [AcmeBank] system for payment.
The Monitoring and Reporting application is used by [Nakatomi] administrators to view system telemetry, and operational and financial reports.
The Administration Application is used by administrators to manage the Payment System. Payment System management includes:
A form builder is required to create various payment types. The form-builder is used to create one or more payment templates to each payment type. The form builder will allow administrators uses to define payment data fields and required payment meta-data. The image below provides an overview of how such a form builder might look:
Keys indicate encrypted data.
Figure 3.6 - Payment Form Builder
The Document Management System stores and tracks electronic documents used to validate and effect payments. It is also capable of keeping track of the different versions of supporting documentation created by submitters and assessors.
The Operational Data Store is used to aggregate data from multiple sources to support the payment submission, validation and payment calculation processes. Data in the Operational Data Store is shared with the Data Warehouse for reporting.
The Data Integration Service is responsible for aggregating, maintaining (where possible), and importing data required for the successful operation of the Payment System. The Data Integration Service imports data from external data sources, and/or provides real-time access to such data, depending on the capabilities of the external system the data is held in.
The Payment System will not provide Business Intelligence (BI) services. However, BI functions will be facilitated through [Nakatomi]'s existing data warehouse and BI capabilities. The Payment System will provide an appropriate connector or other data export mechanism to make its data available to the incumbent data warehouse.
The Payment System will not provide an archiving service. It will, however, make use of the BSO’s existing data archiving services.
Security within the Payment System is multi-faceted – the term encompasses:
The Payment System will authenticate users using two-factor authentication. The authentication model is based on federated identities, in which the corporate authentication gateway, an identity provider external to the Payment System, is used to securely authenticate users.
To support the above, the Payment System issues identity cards and user accounts, and delegates authentication of users to the corporate authentication gateway. A trust relationship exists between the corporate authentication gateway and the Payment System.
In this approach, user account and smart card details are held in three systems –
Using figure 3.7 as a reference, users are authenticated as follows:
Again using figure 3.x above as a reference, users and smart cards are provisioned as follows:
The diagram below, and the text that follows describes the protocol used to provision and authenticate users.
A trust relationship exists between the identity provider and the Payment System. The steps required to authenticate for access to the Payment System are as follows:
Operational Management components allow business and technology owners to manage and monitor the overall health of the Payment System. Operational management includes:
The logical deployment, shown below, shows how solution components are distributed across physical servers. To aid traceability the colours used in Figure 4.1 below correspond to those used for the same components in the conceptual design, described in Section 2 above.
The (preliminary) physical deployment model shows how the solution might be deployed into a data centre. This model has been included to provide an indication of deployment scale, and is subject to change in line with on-going project analysis. The Payment System will be deployed into both data centers, and will run in an active/active configuration. Web servers will run on a separate network to the application servers. Individual servers within each data centre can be load-balanced, subject to load and performance metrics obtained during testing.
The SoURs (statement of user requirements) do not provide sufficient detail to construct meaningful payment forms. Sample payment forms indicating data structure, as well as sample payments for each type would produce a more coherent architecture and increase the accuracy of the estimate.
Little is known about [Nakatomi]'s proposed payee registration system. The assumption is made that it is responsible for on-boarding and retiring payees.
Data integration end points described by this document have been inferred from the SoURs and additional research conducted online. However, a definitive list of external data sources would strengthen the architecture and increase the accuracy of the estimate.
Information required includes:
While many of the business rules required by the Payment System can be inferred from requirements, a complete or at least representative list or scope of business rules would be useful in driving the estimation process.
Little information about payment calculation rules and rates is available in the SoURs. The Statement of Financial Entitlement is available online, however guidance on whether this is the correct source of payment calculation rules, or not, is required. Additionally, it would save considerable effort and cost if the current rates and rules were already defined electronically, in a format suitable for use with a business rule engine.
In order to save development and operational cost, the assumption has been made that identity will be federated, and managed independently of the Payment System.
Consequently, the proposed architecture presented in this document assumes that an existing identity provider and smartcard infrastructure can be used.
|n/a||Start of feasibility study||n/a||n/a||n/a|
|n/a||Feasibility study complete||n/a||n/a||n/a|
|n/a||General requirements complete||n/a||n/a||n/a|
|1||Detailed requirements complete||105||0%||n/a|
|105||High level design complete||122||57%||38%|
|227||Detailed design complete||73||43%||22%|
|422||Start of user-oriented system test||68||80%||70%|
|490||Development and test complete||37||93%||89%|
|527||Payment system accepted||n/a||100%||100%|
The graph below contains planning options. They are derived from the nominal effort and schedule produced by the Monte Carlo simulation. Each of these options is considered to be equally achievable in the configurations shown.
The nominal planning option, the planning option recommended before constraints and priorities are considered, is marked with a rectangle. The optimum planning solution, the option that best meets constraints and priorities, is shown in red. The non-shaded portion of this graph shows the range of schedule and effort solutions that are allowed under the specified schedule and effort constraints.
Estimates can be constrained to hold results within numeric values for cost, effort, schedule, and peak staff. The table below shows the constraints used to create this estimate:
|Maximum schdule allowed||24 months|
|Maximum effort allowed||240 man-months|
|Maximum cost allowed||n/a|
|Maximum peak staff allowed||20|
Priorities are used to determine the optimal project plan. The table below shows the priorities used to create the Payment System estimate:
|Peak staff||[not prioritised]|
|Mean time to defect (MTTD)||Absolute priority|
Estimates vary in the quality of assumptions used to create them. However, some of these characteristics can be evaluated programmatically. This estimate is rated using a five-point verbal scale:
The overall quality of the estimate: Fair.
All content copyright © Michael Wittenburg 1995 to 2023. All rights reserved.
Merch (t-shirts designed by my twin)