Middleware software does not exhibit the same characteristics as the MIS software to which it typically interfaces. Can FPA be used to count these types of applications?

While it is recognised that middleware applications each have their own unique characteristics, there are certain generic characteristics shared by the family of systems known as middleware applications. These include:

1. The primary role of middleware systems is to transfer data between applications, typically between Frontend and Backend applications, one or other of which, may be packaged applications. The data transfer may be in one, or both directions.
2. Middleware applications decouple the Frontend and Backend applications in order to enable changes to the Backend systems to be transparent to the Frontend applications and vice versa.
3. The primary functions of the middleware software are data generation, validation, authorisation, conversion, re-formatting, transaction mapping and logging. They add value to transactions that are initiated by Frontend systems and are intended for processing on Backend systems (and vice versa).
4. Application to application interfaces represent the majority of business functions in a middleware application.
5. Middleware applications receive input from external applications and provide a response, based upon internal processing performed or responses received from destination applications. Internal Logical Files (ILF), other than log and error files, are not maintained as part of this processing.
6. Processes (as opposed to files) are the major contributor to the application size.
7. Middleware processes tend to comprise multiple sub-processes. IFPUG guidelines apply at the elementary process level.
8. The middleware processes do not have a predominant role that defines the process type according to the IFPUG classifications of External Input, External Output and External Enquiry.
9. Middleware applications usually support online, real-time processing, as opposed to batch processing.

Given that the function/process profile does not conform to existing IFPUG transaction types, what type should be assigned to the transactions?

The functionality offered by middleware software can be counted using IFPUG 4.3 guidelines. The FP Analyst applies the IFPUG definitions to the transactions that enter and leave the application boundary and to the data stored within the application boundary.

However, not every data flow that crosses the boundary of the software, nor every 'process' applied to the data flow, is necessarily a unique elementary process. One function may involve multiple data movements, for example, request/response messages, and/or multiple sub-processes, for example, data generation, translation, formatting, and authorisation. The condition that the transaction "achieve a business goal and leave the business of the system in a consistent state" is relevant and should be applied.

The sole objective of a middleware application is to provide an interface between systems, which seamlessly transfers data.

Where they exist, the following may be counted as ILFs for the middleware application:

• Scheduling Files

Specify the processing events relevant to transactions, their sequence and timing.

• Reference Tables

The possibilities are many and varied. They may include:

• Regular reference tables
• Validation tables
• Data conversion/translation tables
• Message mapping tables
• Error message files
• Log/Event Files
Record data transfer traffic as it passes through the middleware application.
• Error Suspense Files

Record data transfer records that are in error. As per IFPUG guidelines, the error suspense files are only counted if the data is permanently stored and can be reported upon and/or modified.

• Queues/Transaction files

The middleware application may be required to keep a copy of all data transfers and update the status of these records. The software may also prioritise transactions.

• Security Files

System security files that define transaction authorisations. (See Section 3.2.5, Security.)

Where they exist, the following may be counted as EIFs for the middleware system:

• Reference Files

(Those that have not been counted as ILFs.)

• Master data files enquired upon

From a logical perspective, the middleware system may make enquiries upon Frontend/Backend systems' master data files. However, this is always done via a request/response sequence. The middleware systems analysts rarely know which logical files the information is coming from, they simple develop the required messages. The middleware system does not have the processing logic to directly inquire upon the Frontend/Backend system files.

As the actual file read is usually not known, a 'representative' file is added to the count file list. The naming standards for these files must identify the file as a 'representative' file. One logical file and one transaction FTR are counted for each unique 'request' made to another application for information to contribute to the current transaction processing.

Any user identifiable transactions required to create or maintain Internal Logical Files may be counted as EIs for the middleware system. Only one generic set of maintenance functions is counted for each unique Error Suspense File, Log File etc. See also Section 3.2.6, Error Files, Suspense Files, Event Logs, Journal Files, Statistics Files.

The IFPUG 4.3 rules do not adequately cover the functions processed by middleware systems. While there is clearly one business process for each transfer/message type handled, these processes do not conform strictly to the IFPUG guidelines for determining transaction type.

Where they exist, the following may be counted as EOs for the middleware system:

• Transactions that enter and exit the application boundary and have as their primary intent the processing (authorisation, translation, reformatting) of data originating in one application and the transfer of this data to a destination application.
• Transactions that transfer request/response messages between applications. For every Request for Transfer message received from an Originating/Frontend system, there is a corresponding Response to Transfer message generated by the Receiving/Backend system. (In the case of a time-out situation, the middleware software may generate the Response message.) The Request and Response messages cannot be separated; they constitute two parts of the same logical business function. One would never occur without the other. One elementary process is counted for each Request/Response message pair.

The output transactions of middleware software are counted as External Outputs rather than External Inquiries. While there may not be any calculated data within the data transfer, the data processing usually involves complex logical processing and therefore the data within the transaction record is defined as derived data.

The middleware transactions are logically one EO transaction. The sub-processes of this transaction may include:

• Ability to receive the same transaction data from multiple sources
• Transaction authorisation
• Validation
• Data Generation - the addition of extra data either from reference tables or data derived from the data elements within the record
• Reformatting
• Mapping of transaction types - the mapping of input transaction types sent by the source system to output transaction types recognisable by the receiving system and vice versa.