Home | Work | Play | Photos | Contact | About

[Nakatomi] Payment System

Home > Work \ Documentation


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.


  1. Introduction
  2. Conceptual Design
  3. Logical Design
  4. Deployment Model
  5. Requirements Gaps
  6. Estimate summary

1. Introduction

1.1. Purpose

The [Nakatomi] Payment System proposes the development a single solution that calculates and makes payments in response to payment requests from third-party payees.

1.2. Business Objectives

The payment system should:

^ Back to top

1.3. Technology Objectives

^ Back to top

1.4. Quality Objectives

^ Back to top

2. Conceptual Design

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.

Payment system conceptual design

Figure 2.1 - Conceptual Design

The proposed solution consists of the following -

^ Back to top

2.1. Client Applications

Client applications present user interfaces. They are web-based, and are to be hosted within the extant on-premises hosting environment.

^ Back to top

2.2. Server Applications

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.

^ Back to top

2.3. System Components

System components manage general, cross cutting governance and security concerns for all components of the Payment System.

^ Back to top

2.4. Information Architecture


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.

Payment system message structure

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.

Payment structure

Figure 2.3 - Payment Structure

^ Back to top

3. Logical Design

3.1. Architecture Overview

^ Back to top

The logical architecture describes the components and the interactions required to build the solution. All client and applications will be based on the accepted application architecture archetypes, described below:

3.2. Web Client Applications

^ Back to top

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.

Web client applications

Figure 3.1 – Client applications

The Payment System contains the following web-based client applications, discussed in further detail in the sections that follow:

^ Back to top

3.3. Service Applications

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:

Web service applications

Figure 3.2 – Service applications

[Nakatomi]'s Payment System contains the following applications and services, discussed in further detail in the sections that follow:

^ Back to top

3.4. Registration System

The Registration client application provides a user interface for payee registration.

^ Back to top

3.5. Payment Submission Service

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.

^ Back to top

3.6. Payment Validation Service

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.

^ Back to top

3.7. Messaging Service

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.

Web service applications

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.

Web service applications

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.

^ Back to top

3.8. Registration Service

The Registration is responsible for on-boarding payees, and consists of tradional add/change/archive/delete functionaltiy.

^ Back to top

3.9. Payment Submission Service

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.

Payment Lifecycle

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.

^ Back to top

3.10. Monitoring and Reporting Application

The Monitoring and Reporting application is used by [Nakatomi] administrators to view system telemetry, and operational and financial reports.

^ Back to top

3.11. Administration Application

The Administration Application is used by administrators to manage the Payment System. Payment System management includes:

^ Back to top

3.12. Payment Form Builder

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:

Payments Form Builder

Keys indicate encrypted data.

Figure 3.6 - Payment Form Builder

  1. Tags – Tags desribe a payment’s meta-data. Tags are labels that have been linked to a payment form. The form builder facilitates the specification of optional and required label groups that are applied when a payment based on a valid template is created.
  2. Fields - Selection of a payment type label as described above will populate a payment form with fields (name/value pairs) based on the associated payment template.
  3. Field types – fields are simple name/value pairs, and can be alphanumeric, numeric, dates, yes/no fields, or lists, from which one or more items are chosen by the user.
  4. Tables – In order to present table data as sub-forms, such as payment header or payment details, the form builder must support tables, which are displayed as rows and columns.
  5. Attachments – The form will allow payment submitters and assessors to add documentation, images and other supporting files to the payment.
  6. Annotations – The payment form will allow payees and assessors to add comments and annotations to payments and/or their content.
  7. Event Log – All changes made to a payment are recorded in the payment audit trail (event log). The log identifies any changes made to payments, the source of the change, and the date/time/location of the change. Changes are digitally signed.

^ Back to top

3.13. Document Management System

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.

^ Back to top

3.14. Operational Data Store

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.

^ Back to top

3.15. Data Integration Service

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.

^ Back to top

3.16. Business Intelligence

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.

^ Back to top

3.17. Archiving System

The Payment System will not provide an archiving service. It will, however, make use of the BSO’s existing data archiving services.

^ Back to top

3.18. Security

Security within the Payment System is multi-faceted – the term encompasses:

^ Back to top

3.19. Identity and Access Management

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 –

Payments Form Builder

Figure 3.7

Using figure 3.7 as a reference, users are authenticated as follows:

  1. The user requests access to [Nakatomi]'s internet-facing Payment System, represented by proxy as Public Internet. The Internet DMZ looks for an authentication token to verify the user authentication.
  2. If no token is present in the request, the user is redirected to the Authentication server for authentication.
  3. The Auth-N server authenticates the payee using a two-factor authentication mechanism like Chip & PIN Claggenge/Response.
  4. If the authentication in step 3 succeeds, the payee is directed to the payment system.

^ Back to top

3.20. User Account and Smart Card Provisioning

Again using figure 3.x above as a reference, users and smart cards are provisioned as follows:

  1. A user requests access to the Payment System. If access is to be granted, an administrator will create a user account, and issue a smart card and PIN to the user.
  2. The user account and smart card number are provisioned into the public authN server via a demilitarized zone.
  3. The user account is provisioned into the user directory in the Internet DMZ

The diagram below, and the text that follows describes the protocol used to provision and authenticate users.

Payments Form Builder

Figure 3.8

^ Back to top

3.21. Authentication Process

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:

  1. The user engages the Payment System by requesting access to the Payment System web site.
  2. The Payment System returns a policy which states that it requires the user to be authenticated and that it will consider for authentication only those subjects presenting an identity issued by the public authN server.
  3. The user then requests an identity from the public authN server.
  4. The public authN server verifies the existence of the user in its directory, and returns a policy that states that a two-factor authentication token is required to authenticate the user.
  5. The user completes a two-factor authentication using a smart card.
  6. The token issued by the smart card, if valid, is authorized by the public authN’s hardware security module (HSM).
  7. If the authentication is successful, the user receives an identity token from the public authN server.
  8. The user presents the token issued by the public authN server to the Payment System.
  9. The user is granted access to the resource requested in step 1 (the Payment System).

^ Back to top

3.22. Operational Management

Operational Management components allow business and technology owners to manage and monitor the overall health of the Payment System. Operational management includes:

^ Back to top

4. Deployment

4.1. Logical Deployment Model

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.

Payments Form Builder

Figure 4.1

^ Back to top

4.2. Physical Deployment Model

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. Payments Form Builder

Figure 4.2.

^ Back to top

5. Requirments Gaps

5.1. Payments

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.

^ Back to top

5.2. Registration System

Little is known about [Nakatomi]'s proposed payee registration system. The assumption is made that it is responsible for on-boarding and retiring payees.

^ Back to top

5.3. Data Integration

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:

^ Back to top

5.4. Busines Rules

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.

^ Back to top

5.5. Payment Calculation

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.

^ Back to top

5.6. Identity

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.

^ Back to top

6. Estimate

6.1. Project Schedule

Milestone Estimated
Duration (Days)
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%
300 Features/code complete 122 57% 38%
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%

^ Back to top

6.2. Planning Options

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.

Plannning options

Figure 6.1

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.

^ Back to top

6.3. 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:

Constraint Value
Maximum schdule allowed 24 months
Maximum effort allowed 240 man-months
Maximum cost allowed n/a
Maximum peak staff allowed 20

^ Back to top

6.4. Priorities

Priorities are used to determine the optimal project plan. The table below shows the priorities used to create the Payment System estimate:

Priority Value
Schedule [not prioritised]
Effort [not prioritised]
Cost [not prioritised]
Peak staff [not prioritised]
Mean time to defect (MTTD) Absolute priority

^ Back to top

6.5. Estimate Quality

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.


^ Back to top

All content copyright © Michael Wittenburg 1995 to 2024. All rights reserved.
Merch (t-shirts designed by my twin)