111. TOGAF provides the following useful definitions:

• Application - A deployed and operational IT system that supports business functions and services; for example, a payroll. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application.
• Architecture - 1. A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010:2007). 2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
• Application Architecture - A description of the major logical grouping of capabilities that manage the data objects necessary to process the data and support the business.
• Technology Architecture - The logical software and hardware capabilities that are required to support deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.

112. CSPA uses the following definition that blends several important elements from these definitions:
"Application architecture is a description of the major logical grouping of capabilities that manage the data objects necessary to process the data and support the business - it details the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time."
113. As described in Section II, The CSPA Application Architecture is based on an architectural style called Service Oriented Architecture (SOA). This style focuses on Services (or CSPA Services in this case). A service is a representation of a real world business activity with a specified outcome. It is self-contained and can be reused by a number of business processes (either within or across statistical organizations). 
114. CSPA Services have invocable interfaces that are called to perform business processes. SOA emphasizes the importance of loose coupling. CSPA Services are independent, that is, they do not talk directly to each other. Organizations will need a technology solution to support communication between CSPA Services. This solution (for example a communication platform) will not affect the interfaces. It should be noted that SOA is not the same as Web Services, although they are often used in SOA.
115. In the discussion that follows, it is important to note that the Application Architecture is a descriptive (not prescriptive) framework that must support flexible approaches within individual statistical organizations while providing a basis for collaboration and sharing of standardized service components.
116. The CSPA Application Architecture must provide a means of expressing statistical production as an assembly of statistical services, aligned with design principles and guidelines and taking advantage of design patterns.
117. CSPA Services can be one of two types – a statistical function service or a statistical entity service.
118. Statistical function services must be defined at an appropriate level of granularity. In Section III B (Business Architecture) we describe the following guidance in the section on design principles:

• CSPA Services are defined at an appropriate level of granularity [...] defined at the level of a GSBPM sub-process they support, and
• CSPA Services are relevant to the business [...] large enough for the business to understand, and are not low-level services used by IT.

119. An alternative approach to determining the size and complexity of services is microservices. Microservices are small, specialized and autonomous services, which collaborate to complete a process. Given their characteristics, microservices are well suited to enable a more fine grained development of the application landscape to achieve business value.
120.One of the advantages of this approach is the granularity that can be obtained when scaling only services that have a high demand. From the example, if an organization has a huge demand to collect information from multiple sources it only needs to create new instances of the collect service, and not the others so demand of resources is more efficient. Using this approach will add further requirements to the production platform.
121. Statistical entity services are an important and related set of services. These services provide reliable access to statistical information entities (objects) in order to support statistical production processes. Sometimes statistical entity management is included in a statistical function service. However, sometimes the entities are managed outside the service. Statistical entity services might include:

• Classification services - for the management and use of statistical classifications
• Register services - for the management and use of business, address, and household register information
• Geography services - for the management and use of geographic information
• Statistical metadata services - for the management and use of relevant statistical metadata throughout GSBPM statistical production

122. The IT departments of Statistical organizations will also be concerned with IT-specific services, which we term Utility Services, that provide important reusable service components of a non-statistical nature to create solutions. These are out of scope of CSPA, but informal sharing of common utility services where useful is encouraged amongst the statistical community.
123. The Figure 6 below shows the relationship between these "layers". The CSPA Application Architecture supports the identification of services, their definition, specification, and implementation, and their assembly into statistical production solutions. It is focused on expressing the statistical task (function) and entity services and how they are combined, under the direction of the business process layer which represents an instance of a GSBPM context (or alternatively, through an event-driven approach to be discussed below). Note that the bottom two layers are part of IT Community Sharing (libraries, tools, experiences) and are not part of the CSPA Application Architecture - they do in part touch on elements that may be part of the CSPA Technology Architecture.

Figure 6: Service layers (both within and external to CSPA)

Patterns 

Architectural Patterns

124. In general terms, an architectural pattern is a description of a widely recognized, re-usable, proven solution to a specific class of recurring design problems. It is often expressed as a problem context, system of forces, and a resolution of those forces into an effective solution.
125. The benefits of using architectural patterns can be described by using the analogy of an expert chess player. To play chess, you must learn the rules and the principles (for example the value of different pieces). However, to improve and become a really good player, you need to learn the patterns used by more experienced players and apply them to your game. In the same way, you could use the principles and non-functional requirements of CSPA, but to get the maximum benefit, it is worthwhile to learn the architectural patterns applicable to your field of work. There are many architectural patterns described in literature. Service Designers, Service Builders and Assemblers in particular can benefit from studying these patterns. The Service Designer or local Solution Architect is encouraged to investigate SOA Patterns such as those found on the website SOAPatterns ¹ .
126. Solution and Application Architects tasked with designing statistical production solutions will be most effective if they are able to select the most appropriate patterns for the different parts of GSBPM. Over time we expect that the community will identify and share patterns that are particularly effective, and we see this as an on-going process arising from community collaboration.
127. Current statistical organization experience has identified two patterns that have important implications in different parts of GSBPM. These have to do with the means by which information and process control flows throughout the solution and how service invocation is triggered.

• In an event-driven approach, services subscribe to event streams (publish-subscribe pattern) and are triggered in an asynchronous fashion as events occur.
• In a process-driven approach, explicit process control functions (workflows) sequence the execution of a collection of services and the flow of data amongst them.

128. The selection of approach depends on a number of factors, often driven by the specific context of the statistical organization. Ultimately the Solution and Application Architects (as well as Information Architects and Technology Architects) within a Statistical organization will arrive at a set of design decisions based on these and other patterns, and will look to design and assemble solutions based on them. There may be important architectural considerations on the part of service designers to ensure compatibility of services with either of these two patterns. Architects should consult the specific guidance on this topic when making their decision. For further information see CSPA implementation guidance.

Service Invocation and Identity

129. In order for CSPA to have a robust capability dealing with entities, we define the concept of a global identifier which uniquely identifies entities in the statistical production space. Service messages (request / response) or event-driven messages may include these identifiers in their messages, and the supplying service is able to use them in carrying out its functions - e.g. to relate a piece of metadata and data for a processing step. The message may also supply the location. The identifiers exist independent of the local environment.
130. The best approach to obtaining the required information is to require that the invoking service (or orchestration) provides the necessary data and metadata objects (with their GUID's) at invocation or at a previous occasion in the case of the event driven pattern. The invoked service may respond with additional entity references to the invoker, who is then able to address any additional information needs (through its business logic).

Protocols for passing data by reference

131. In certain circumstances, services require large data sets as inputs. Examples of this could include administrative data files or large survey response files. The problem is similar to a "pass by value" situation in that the input data is passed to the service via in-message approaches.
132. This issue is solved by the Claim check pattern. A short explanation can be found here: {+}http://www.enterpriseintegrationpatterns.com/patterns/messaging/StoreInLibrary.html+
133. The implementation of a data store is local to each organization and may be implemented as part of the communications platform. Organizations may choose to implement a utility service, a repository, a file cache, or some other mechanism. URI management is also a part of local operation.

Application Design Principles

134. The design principles have been selected to maximize the flexibility of the Statistical Services wrapped or developed in the context of CSPA. The flexibility of the Statistical Service directly impacts the level of reuse, the flexibility required of the industry vision and the ease with which a statistical organization can implement a Statistical Service.
135. Principle: Maintain independence between design and implementation
Statement: The descriptions of CSPA Services are layered in conceptual (CSPA Service Definition), logical (CSPA Service Specification) and implementation (CSPA Service Implementation Description).
136. Principle: Use available standards
Statement: The design of CSPA Services should align with, and harness, relevant existing standards and frameworks wherever possible.
137. Principle: Use architecture patterns
Statement: Follow architecture patterns depending on best fit to requirements.
138. Principle: Implement using GSIM
Statement: Manage standardized service contracts based on CSPA Logical Information Model (LIM)
139. Principle: Minimize coupling
Statement: Enable services to be loosely coupled externally and be aware of internal coupling.
140. Principle: Maximize Service Autonomy
Statement: Maximize service autonomy (completeness) to enable share-ability and reusability (External & Internal)
141. Principle: Include non functional requirements
Statement: Non-functional requirements form a key input in design decisions.

Non-Functional Requirements

142. In the context of CSPA, a non-functional requirement is a requirement that relates to the operation of a system. While functional requirements define what the services does (for example, error localization), the non-functional requirements describe a performance characteristic of a system (for example, authorization of who can access the resources and functions of the service). That is, non-functional requirements determine how a service behaves rather than what it should do.
143. Non-functional requirements are important to be captured in the design of the services. They have a significant influence on the software architecture of a service. The Designer [1] of a CSPA Service should identify the non-functional requirements that are relevant to that service when they are designing it. The implementation of a CSPA Service provides some functional value when assembled into a value chain within an organization. The non-functional requirements of a CSPA Service address other concerns or behaviours of the service such as performance, security, process metrics and error handling. This section provides some guidance on these concerns.

Multilingual Support

144. The CSPA Services must be able to support input and output in multiple languages where applicable. If the service includes manual operations, it also must be possible to change the language of the GUI. Preferably, even the presentation style should be adaptable. Additionally, services must be documented at least in English in addition to the local language(s) of the organization developing the CSPA Service. It is highly recommended that organizations that have made translations of the documentation of a CSPA Services in additional languages make them available to the community.

Security

145. CSPA Service Security needs to address the following key concerns:

• A service implementation must not contain any internal vulnerabilities that might pose risks to a local Statistical organisation environment
• The statistical information (data, metadata) must be able to be protected at a level consistent with the needs of the local Statistical organisation
• The service must not be vulnerable to attack where it may be used for wrong purposes

146. In order to address information access, it is necessary to validate the user (invoker) through authentication, and to address access privileges through authorization controls.
147. The challenge in implementing security features in a service lies in the fact that in general different Statistical Organisations will have different (but similar) approaches.
148. Invoker Authentication may involve validating the identity of a user (person) or an invoking service. These can be mediated with certificates (tokens) or directory services (for users).
149. Access authorization involves resolving the rights of the invoker (person or service) and granting access to the relevant information and service resources based on these rights. The rights may be managed centrally (e.g. in Active Directory) or local to the service (in internal rights resources).
150. For the purpose of this document, the security concern relates to controls that are put in place to mitigate the risk that a CSPA Service or the data it controls is misused. This section provides some basic guidance on some of these controls. However, in general it is strongly advised that each CSPA Service implementation complete a Risk Assessment and document a Risk Mitigation Plan for high and extreme risks identified in the assessment.

Data at rest

151. Data at rest is of particular interest when a Statistical Service needs to defer state (see discussion in "Service Statelessness" in section V D). Under this circumstance, the security (e.g. encryption requirements or access control) of the data are entirely the responsibility of the Statistical Service. Where a CSPA Service already has a functional dependency on underlying technologies or platforms, it would be reasonable to make use of security functions available in those technologies.

Data in transit

152. Security of data in transit (e.g. contained within a message flow as part of a service invocation) will be considered in future iterations of CSPA.

Data Sensitivity

153. Sensitivity of statistical data varies amongst organizations and at this stage the architecture does not attempt to converge on a standard definition or treatment.

Machine to machine certification

154. Guidance for this will come in a future iteration of CSPA. Organization specific implementations based on assembly time infrastructure can assure security for service communication (for example, use of a VLAN).

Performance

155. No specific guidance is provided on the performance characteristics. However, they should be declared in the CSPA Service Implementation Description and it is recommended that examples of performance level are included.

Process Metrics

156. A CSPA Service will generally capture metrics related to the function that it performs. To all intents and purposes, these process metrics are treated by the CSPA Service as just one of its outputs and should be reflected as such in the CSPA Service Specification.

Error Handling

157. Error handling, in this case, relates to situations where the service fails. The service must report this to the communication infrastructure if applicable. Error handling is left to the communication platform to handle as required. Generally there will be protocol specific requirements for flagging errors. The error codes and their meanings need to be documented in the CSPA Service Implementation Description.
158. In the case of publish/subscribe pattern, it is suggested that a standard error event that all CSPA compliant services should be listening for in order to be able to handle relevant errors.

CSPA Service Definitions, Specifications and Implementation Descriptions

159. The level of reusability promised by the adoption of a SOA is dependent on standard definitions of the services. CSPA has three layers to the description of any service. These layers are described in the following paragraphs and in Figure 7.

CSPA Service Definition

160. The CSPA Service Definition is at a conceptual level. In this document, the capabilities of a Statistical Service are described in terms of the GSBPM sub process that it relates to, the business function that it performs and GSIM information objects which are the inputs and outputs.
161. A template of a CSPA Service Definition can be found in Annex 1.

CSPA Service Specification

162. The CSPA Service Specification is at a logical level. In this layer, the capabilities of a CSPA Service are fleshed out into business functions that have GSIM implementation level objects as inputs and outputs. This document also includes metrics and methodologies.
163. A template of a CSPA Service Specification can be found in Annex 1.

CSPA Service Implementation Description

164. The CSPA Service Implementation Description is at an implementation (or physical) level. In this layer, the functions of the CSPA Service are refined into detailed operations whose inputs and outputs are GSIM implementation level objects.
165. This layer fully defines the service contract, including communications protocols, by means of the Service Implementation Description. It includes a precise description of all dependencies to the underlying infrastructure, non-functional characteristics and any relevant information about the configuration of the application being wrapped, when applicable.
166. A template of a CSPA Service Implementation Description can be found in Annex 1.

Figure 7: Service interfaces at different levels of abstraction
167. In general, there will be one Service Specification corresponding to a Service Definition, to ensure that standard data exchange can occur. However, it is recognised that there may be occasions where an additional Service Specification is required, it is likely that this will be associated with variations in the methodology encapsulated within the statistical service. At the implementation level, services may have different implementations (software dependencies, protocols, supported methodologies) reflecting the environment of the supplying organization. Each implementation must rigidly adhere to the data format specified in the Service Specification. The CSPA Architecture Working Group is the final approver for CSPA service documentation (Service Definition, Service Specification and Service Implementation Description), and is responsible for publishing through the Global Artefact Catalogue. The role of the CSPA Architecture Working Group is detailed in the Governance section of this document.
168. There are a number of roles identified in CSPA (see Section VII) which are involved in the definition, specification, and implementation of CSPA Services. These roles can be considered as operating at different levels of abstraction. Figure 8 illustrates the relationship between these levels and roles for instances where there is one Service Specification for one Service Definition. Figure 9 illustrates the case where more than one Service Specification is required for one Service Definition.

Figure 8: Minimal Linkages between CSPA Service Definition, Specification, and Implementation

Figure 9: Possible Linkages between CSPA Service Definition, Specification, and Implementation

1. Website: http://www.soapatterns.org ↩