Work

Home | Work | Play | Photos | Contact | About

Payment System

Home > Work > IT Consulting \ Sample Documentation -- Payment System

Contents:

  1. Introduction
  2. Objectives
  3. Solution Overview
  4. Information Architecture
  5. Estimate summary

1. Introduction

The Payment System is a fictitious solution that calculates and makes payments to third parties.

This page documents the following:

^ Back to top

2. Objectives

The architecture is based on stated business objectives, functional and non-functional requirements, and discovery workshops held with [Client].

2.1. Business Objectives

The Payment System should:

2.2. Technology Objectives

2.3. Quality Objectives

Quality objectives articulate performance expectations of the solution, and are assessed using operational metrics and measurements.

^ Back to top

3. Solution Overview

3.1. Architecture

The diagram below depicts the conceptual design of the proposed Payment System. It identifies high-level system components and their relationships, discussed in greater detail below.

Payment system architecture

Figure 2.1 – Payment system design

3.2. Client Applications

Client applications are the system's user interfaces. They are typically web-based, and ideally hosted within the Microsoft SharePoint collaboration platform.

3.3. Application Sub-Systems

The application sub-systems implement the core business processes required to manage, validate and process payments for claims. Each system is implemented as a service with a distinct end point. Individual services are tied together using the messaging service, which routes claims and payments to the appropriate endpoints.

3.4. Messaging Sub-Systems

The messaging system provides a message routing service to other solution components. This allows solution components to operate independently, thereby separating concerns of operation, and increasing system performance and flexibility. The messaging system facilitates the introduction of new components, or the exchange/upgrade of individual components within the solution without affecting other components.

Persisted messages could be XML or other format suitable for EDRM (records management).

3.5. System Components

System components provide general, cross cutting governance and security services to all other components of the Payment System.

^ Back to top

4. Information Architecture

4.1. Messages

The proposed solution is based on a messaging model, in order to provide increased 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 is an envelope containing message-handling meta-data and the message payload (a claim, notification, report, and so forth).

A message is unaware of its payload, which is encrypted. However, messages are routed based on the message's message-handling meta-data, which might indicate the payload (item) type, item state, item sub-type (such as the payment type), its point of origin and destination, and the message's access control list.

Message Information Architecture

Figure 2.2 – Message Structure

The item type, sub-type and status are used to route a message through the Payment System. Where the item type is “Payment request”, possible sub-types might include:

Status-based routing scenarios for messages with an item type of “Payment request” could 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.

4.2. Payment Requests

Payment requests vary in structure and content, based on the payment request type. Payment request forms, the workflow and business rules associated with payment requests, and payment request validation are subject to change over time.

To address the requirements of flexibility and extensibility, and in anticipation of later change requests, payment request forms will be based on payment request form templates. Templates describe the content of payment requests in terms of name/value pairs. The name provides a label for the value, which is entered by the payment requestor. Name/value pairs can be linked to business rules, which are used to validate payment request content.

Payment requests also require meta-data, which is required to route payment requests, validate their content, and to apply payment rates during payment calculation.

Lastly, to facilitate payment request assessment, payment requests must be annotatable, images and supporting documents must be added to payment requests as attachments, and a log must be kept to track changes to a payment request over time.

This payment request 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 payment requests, and the templates that define them.

Message Information Architecture

Figure 2.3 – Payment request Structure

^ Back to top

5. Estimate Summary

The sections that follow present an estimate for the delivery of the Payment System. Additional and supporting information is contained in section 6, below. The current estimate is based on a lack of understanding of the requirements as detailed in the gap analysis in section 5, below. The estimate therefore makes a conservative assumption about the specified gaps, and accounts for their impact.

Work in progress. To be continuted....

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