CSPA Use Cases - CSPA Roles and Usage Scenarios
1.
The following Use Cases have been developed by Statistics Netherlands (CBS) to assist their
development and implementation of Statistical Services. In particular, they include internal
resources, catalogues and roles, which they have found useful. These Use Cases are provided to
assist implementation efforts, they are not formal CSPA artefacts.
2.
The Use Cases describe which stakeholders are involved in the use of CSPA and which user
scenarios are relevant to these stakeholders. The CSPA Services Catalogue mentioned in these Use
Cases refers to level 4 of the Global CSPA Catalogue described in Chapter VIII-A, Catalogues.
3.
The term “service” may mean different things to different people. The CSPA glossary
provides the following definitions
Business
Service
A defined interface for accessing business capabilities (an ability that an
organization possesses, typically expressed in general and high level
terms and requiring a combination of organization, people, processes
and technology to achieve)
Capability
Capabilities provide the agency with the ability to undertake a specific
activity. A capability is only achieved through the integration of all
relevant capability elements (e.g. methods, processes, standards and
frameworks, IT systems and people skills).
Service
A service is a logical representation of a repeatable business activity that
has a specified outcome and is self-contained, fulfils a business need for
a customer (internal or external to the organization) and may be
composed of other services.
GSIM
Statistical Network BA
definition
Statistical Network BA
definition (adapted
from TOGAF G113)
Figure 1.1 Glossary
To elaborate this point further, let’s compare a CSPA process to a production facility (a factory),
and make a distinction between:
a. The “machinery”, i.e. a technical facility, empty of people, but with all the technical
equipment, machines, conveyor belts, power, etc., maybe with maintenance staff, but
without any staff to operate it, and
b. A fully equipped and staffed facility, ready to go, just waiting for the input (the orders).
4.
It will be clear, that, unless the “machinery” constitutes a fully automated facility, the first
alternative will not be able to produce any useful output without the people necessary to operate “the
plant”.
5.
This metaphor can be applied to a statistical process as a whole, but also to individual
process steps. In the metaphorical factory, we could have both fully automated machines and
machines that need human operators. To make the picture complete, we also need a mechanism to
transport the parts and products from one machine to the next. In a job shop, each class of products
has its own route through the factory. On a production line, all products follow the same route.
6.
Now let’s apply this metaphor to CSPA, where the depth and breadth of a CSPA service is
still a matter of opinion. In line with the first alternative, a CSPA service can be seen as an IT
service, i.e. a piece of functionality that is delivered by an IT system. In this case, we can talk about
Software as a Service (SaaS) when this service is available to consumers through some form of
contract with a service provider. If there is manual labour involved in operating the service, the
consumer (user of the SaaS) has to provide and train the people that will be assigned to operate the
service system. As an example, take the manual editing of micro data. Assuming that a system is
used to edit the digital data, this system can be delivered as a service. Through a process, external to
the service, data may be fed into the service. But, since it is manual editing, people are required to
do the actual editing, using some kind of user interface (GUI) provided by the system. These people
are not part of the software system and are not provided by the service provider.
7.
On the other hand, a service may also be a full business service, where the service provider
provides everything that is needed to “run” the business, including any manual labour.
8.
The difference also impacts other roles. After all, if a service provider does not deliver the
manpower to run the system, someone else will need to do so. The next in line for this task is the
Assembler. Unless, of course, the Assembler role is restricted to providing a technical facility only,
in which case the task of staffing the services and the process falls onto yet another role. In the
current CSPA model, this would be the process owner (a User), to whom the Assembler delivers the
assembled process (the “factory minus the staff”, the “machinery”)
9.
When reading the following user stories, please bear in mind that these have been written
mostly under the assumption that CSPA services are fully automated (business) services.
I.
(Re)Designing a statistical process
10.
A. Purpose
To design a new statistical process or to redesign an existing process
11.
B. Primary stakeholder
Designer.
C. Secondary stakeholders
12.
Investor, User (process owner), Builder, Service Provider, Assembler, Configurer
D. User story
13.
The process for which the Designer is going to create the design, eventually will be used by
a process owner (a type of User). This User in fact is the ultimate customer of the Designer. The
process owner may or may not be the same person as the Investor. Usually, in our organisation, the
2
Investor is at a more senior management level. As the process design will have to meet many
different requirements, the Designer’s task is not an easy one.














The Designer defines the output of the statistical process, which is the starting point for the
process design;
The Designer defines the inputs to the process;
The Designer defines the business functions necessary to create output from input;
The Designer determines the appropriate architectural pattern for this process;
The Designer translates the business functions into process steps;
The Designer determines the statistical services that should perform the necessary process
steps. The Service Catalogues (local and global) are used to identify candidate services. The
Designer browses the Service Catalogue(s), looking for suitable statistical services.
The Designer studies these statistical services and determines which ones are best suited for
performing the envisioned business functions in the architectural pattern chosen. Whether a
statistical service is suited depends on how well its function and its inputs and outputs match
the context of the process being designed. The Designer may need to check with the
Assembler in order to decide whether an envisioned service is or can be made accessible
from the (local) process environment. If not, the Assembler will have to take measures to
find a new Service Provider. From here, several scenarios are possible:
One of the statistical services found is exactly what is needed to perform the business
function. This statistical service is selected;
One of the statistical services found is more or less what is needed. The Designer will try to
adapt the statistical process design and if necessary the related inputs and outputs to fit the
available statistical service;
None of the existing statistical services is close (enough) to performing the required
business function. The Designer will either change the statistical process design
fundamentally or will specify (a) new statistical service(s) and confer with Investor(s) and
Builder(s) to evaluate the business case for having these created;
If a service exists for the required function, but not for the required pattern, the Designer
may request a re-wrapping of the existing service to make it suitable for the other pattern.
Again, the Builder will need to check with the Investor and the Builder will have to create a
new (version of the) service;
The Designer repeats this process until the entire statistical process is mapped to (existing
and/or feasible) business functions and statistical services;
For any new service, the Designer will create a Service Definition and Service Specification
in the Local Service Catalogue. In addition, these will be promoted to the Global CSPA
Service Catalogue in order to inform the international community of the new need,
indicating the status of the development;
After finalization of the process design, an Assembler is requested to realize the statistical
process according to the design. This realization will probably involve multiple iterations
that may involve adaptations and amendments to the designed process and required
statistical services in collaboration with the Designer and Builder(s). Also, the Investor may
need to be involved.
3
E. Stakeholder implications
14.
The way of working described here requires that both the Designer and the Investor change
their attitude as compared to more traditional approaches. The Designer also needs to "think" in
terms of GSIM objects: outputs, business functions, process steps, etcetera. One of the major
challenges is determining the granularity of process steps and distinguishing between "generic"
aspects of a process and local, specific, aspects.
15.
Another important aspect is the shift from “batch” to “single entity”: processes should be
designed to improve throughput by processing entities as soon as possible instead of waiting and
collecting batches. There will, however, be steps in the process that, by necessity, do require sets of
entities. But even aggregation can be designed to be performed entity by entity, improving the
quality of the aggregate by each entity added.
16.
Furthermore, this approach requires that existing statistical services can be accessed from a
local environment (in which the process orchestration is to be executed) and that new statistical
services can be created if necessary. This requires availability of the Assembler and Builder roles
and expertise.
17.
Contemplating, designing and building new services may involve international collaboration.
Organisations (Investors, Designers and Builders, but also Service Providers and Assemblers as well
as Users responsible for overall statistical processes) will need to adapt to this new way of working.
II.
18.
Building a new service
A. Purpose
To implement a new statistical service that has been designed by a Designer.
B. Primary stakeholder
19.
Builder, Service Provider
20.
C. Secondary stakeholders
Investor, Designer, Assembler
D. User story
21.
The task of the Builder is to create the software solution in accordance with the service
definition and service specification provided by the Designer. It goes without saying that in this
context, the solution of course will comply with the CSPA guidelines. However, the Builder may
also have to take into account the technological requirements and constraints of the target
environment. This may require discussions with any envisioned Service Provider(s). CSPA
promotes portability, but this comes with a price. So the Builder may have to take advice also from
Investor and Designer as to any requirements in that respect.

The Builder receives a service definition and a service specification from a Designer.
4





The Builder verifies that no implementation for this combination of service definition and
service specification already exists.
The Builder builds a software component that performs the required function based on the
designed inputs, input parameters, results and output parameters, with the following
guidelines:
The component is implemented in such a way that it is as independent as possible from other
components that have to be available on the local environment it runs on and even as
independent as possible from any specific local environment. This should make it as easy as
possible to run the service with this specific implementation on any local environment. This
involves the following considerations:
o Using platform independent programming languages;
o Using as least references components / libraries as possible;
o If other components / libraries are necessary, choose components / libraries that are
available on different operating systems;
o Not using inputs (files, databases, etcetera) and outputs other than the inputs and
outputs defined by the service;
o Comply with UNECE “Principles and Guidelines on Building Multilingual
Applications for Official Statistics” and international coding standards;
o List to be further elaborated.
The Builder creates a Service Implementation Description containing the following artefacts:
o A description of how the statistical service was implemented;
o Requirements on the execution environment (which operating systems are supported,
hardware characteristics, …)
o An installation and deployment manual describing how to implement the service in a
specific local environment.
The Builder updates the Local and Global CSPA Service Catalogues, updating the Service
Definition and Service Specification where needed, adding the Service Implementation
Description and, if applicable, the source code and (references to) binary components.
To be expanded in order to include:
·
Guidance on how to avoid introducing unintended dependencies
·
Granularity, handling service layering and service composition
·
Licensing issues
·
Existing examples
E. Stakeholder implications
22.
Builders are software engineers or technical methodologists that will develop software
components based on a precise statistical design in terms of GSIM objects. Furthermore, they will
have to deal with the specific constraints of running services in a CSPA context, like using
standardized CSPA inputs and results and having international deployability (platform and
country/language independency) in mind.
III.
Providing a service using an existing implementation
5
23.
A. Purpose
To provide a service for which an implementation is available (either locally or globally).
24.
B. Primary stakeholder
Service Provider.
C. Secondary stakeholders
25.
Builder, Assembler, User
D. User story
Initial setup
26.
A Service Provider will only start providing a given service if there is some need. The first
service offering will, as a minimum, have to match that need. But a Service Provider should
anticipate future needs and implement the service in a way that takes scalability requirements into
account.









If the service has more than one implementation, the Service Provider chooses the
implementation best suited for the current needs and for the local environment on which it
has to run;
The Service Provider performs a Quality Check on the chosen implementation and, if the
check is passed, adds it to the Local Service Catalogue;
After the Quality Check has been performed on the Service Implementation, the Service is
added to the production environment, performing a Transition to Production process:
Adding the service to the production environment automatically adds it to [[Service
Availability Control]];
The Service Provider retrieves the Service Implementation Description;
The Service Provider retrieves the binaries of the service component and any referenced
components / libraries;
The Service Provider deploys the service and its components on the infrastructure using the
installation instructions from the Implementation Description;
The Service Provider updates the local Configuration Management Database (CMDB);
The Service Provider publishes a standard Service Level Agreement for the new offering.
Operational phase
27.
Assemblers and Service Providers will enter into service agreements in order to ensure
operational availability of the service for particular processes. Assemblers need to specify the nonfunctional requirements such as availability, performance, data volumes, etc.
28.
Once operations are started, the Service Provider must ensure that the service meets the
agreed service levels at all times. This means normal, professional , operational service
management, including regular contacts with the process owners of the processes that use the
service.
6
29.
During the operational phase, new versions of the service software may become available.
The Service Provider must ensure that migrations from one service version to the next are
coordinated with the process owners of the processes that use the service. During such transition
periods, Service Providers must be able to support two or more consecutive versions in parallel.
Service Providers should provide feedback to Investors, Designers and Builders about the functional
and technical experiences gained during initial setup and operation.
30.
In order for services to be available over time, to live up to Service level Agreements and
generally to keep the functional and technical performance of the service up-to-date and in line with
current practices and requirements, Service providers need to actively maintain the services they
provide.
31.
This involves; Service lifecycle management, technical ownership of the local Statistical
Service(s), monitoring and solving any technical problems regarding the execution of individual
statistical services. Additionally, it involves keeping in touch with Designers, Builders and
Assemblers in order to anticipate developments.
32.
On the one hand, the Service Provider will be focussed on the technology side of the service,
looking at stability, performance, etc. On the other hand, the Service Provider will be focussing on
functionality, keeping an eye on new or changing requirements, availability of new versions
provided by Builders, etc.
33.
In general, best practices in this field such as ITIL and BISL can be found in literature.
Capacity Management


The Service Provider monitors performance and load of the service software application and
the underlying infrastructure, such as servers and disk usage on file servers;
When any of these exceed set thresholds, a process is triggered to increase capacity or to
discuss the cause with the process owners (Users) of processes using the service.
Life Cycle Management
Issue / Incident Management



Errors or deviations from agreed service levels may be detected by monitoring, or reported
by process owners (users of the service).
If applicable, the Users of all applications (processes) using the malfunctioning service are
alerted of the problem;
The Technical Service Provider investigates the problems and identifies whether they are
infrastructural, programming bugs or methodological bugs in the service component.
Analysis of log files and other information may be needed to determine the cause(s) of the
problem. In case of...
7




infrastructural problems, a server problem or network problem may have to be solved;
a local developed service, in case of...
o programming bugs, the Builder is requested to analyse the problem and solve any
bugs in a new version of the statistical service implementation. This new version gets
a new Patch version, according to Semantic Versioning;
o methodological bugs:
 The Designer is requested to supervise the correction of the design and
specification of the Statistical Service, which may result in new versions of
Service Definition and/or Service Specification;
 The Builder is requested to provide a new Minor version of the Service
Implementation according to the changed specification.
a service not developed locally, the bug is reported (including requested resolution priority)
in the Global CSPA Service Catalogue issue registration, including the Service Provider’s
understanding of the nature of the bug. If an agreement can be reached on an acceptable
resolution time, the resolution is awaited. Otherwise, a new version of the service is
requested from a Local Service Builder, as if it were a locally developed service.
In case a new version of the service has been developed, it is updated in the local and
possibly Global CSPA Service Catalogue.
E. Stakeholder implications
34.
The Service Provider as described here in many organisations is a new role. At least in Stats
Netherlands, statistical process owners are not used to relying on other parts of the organisation to
provide services that are crucial to the reliability and performance of the overall process. It will take
time to build trust and to prove that sharing a service with others in the same organisation or even
across organisations is possible and worthwhile. Service Providers that take on this role initially will
have a difficult time building that trust. In addition, Designers, Builders and Service Providers will
have to find ways to handle “exotic” requests from process owners in order for services to remain
generic (enough) and stable.
IV.
35.
Building a new statistical process
A. Purpose
To implement a statistical process as specified by the Designer.
B. Primary stakeholder
36.
Assembler.
37.
C. Secondary stakeholders
Designer, Service Provider(s), Environment Provider, Configurer, User.
D. User stories
38.
The task of the Assembler is to build the statistical process according to the design provided
by the Designer. (Note: that the Assembler, like the Designer, is acting for and on behalf of the
8
process owner (a type of User) in that the process owner will be the main stakeholder in the
operational phase of the statistical process.)
39.
First of all, starting from the assumption that the required services have been built already
and are available as software packages, the Assembler will need to make sure each of the selected
services are indeed available for the new process. This means finding suitable Service Providers for
each of these services, ensuring that the service provided is indeed accessible from the (local)
environment in which the process is supposed to run. (Note: that this does not necessarily mean that
all services must run locally, but if one is not, additional security considerations may come into
play.)
40.
Quality Control ensures that all used services are of the latest available version.
41.
Suitable service level agreements will have to be negotiated with each Service Provider in
order to ensure availability and performance of the resulting process.
42.
Finally, the services will need to be integrated into the process by building the process
integration using the communication pattern selected by the Designer. For this, the Assembler will
either use the functionality of the Communication Infrastructure provided by the local Environment
Provider, or build custom software to serve this purpose.
43.
Thus having created the technical facilities, the Assembler usually turns this over to the
process owner, who then will take care of implementing the necessary human activities in and
around the process, ensuring these are embedded in the organization.
Assembling statistical services using an orchestrator
44.
This scenario assumes the presence of a generic communication infrastructure, provided by
an Environment Provider that can be used to build and run process orchestrations.








The Assembler starts the orchestration tool and connects to the local Service Catalogue;
The Assembler selects the statistical services specified by the Designer;
The Assembler configures the flow of control, taking care that conditions are evaluated
where necessary in order to decide on alternative routings;
For each service input, the Assembler defines a map to a (preceding) service output. Direct
mapping is only possible if the metadata on both ends match. If there are any discrepancies,
transformations may need to be performed between service calls.
The Assembler specifies values for any static parameters of the statistical service;
The Assembler maps dynamic input parameters onto dynamic output parameters;
The Assembler stores the statistical process (orchestration) definition;
The orchestration tool generates any user interfaces required to execute the process.
9
Assembling statistical services using custom software
45.
This scenario assumes a less sophisticated or mature organisation, where no central
communication infrastructure is available. Even where such a central infrastructure is available, this
scenario may be used for simpler or ad-hoc processes or in a test phase.
46.
In this scenario, the Assembler creates the communication layer that orchestrates the services
for the process as a custom-built piece of software. In this case, each process is a separate system,
that depends on and uses loosely coupled services.








The Assembler creates or reuses a similar software program and inserts a web service call for
each statistical service. Before executing the call, an input parameters package has to be
constructed dynamically, which contains the following:
For each of the service inputs, a value or a URL to a file in CSPA standardized format;
A value for each of the input parameters of the statistical service.
In case the web service call is asynchronous, the Assembler must create a web service entry
point connected to an event handler that is activated by a call back from the statistical
service. The URL to this call back entrypoint must be added to the input package.
Just like in the synchronous case, the event handler must accept the service response
package, which contains the following:
For each of the service results, a value or a URL to a file in CSPA standardized format;
A value for each of the output parameters of the statistical service.
At the transition of the custom software to the production environment, the used services
(including version numbers) are mentioned in the application dependencies chapter of the
custom software.
Assembling services for the event-driven pattern
 The Assembler adds subscriptions to the appropriate event message types for the selected
services into the orchestration infrastructure.
E. Stakeholder implications
47.
The way of working greatly differs whether the Assembler uses an orchestration tool to
"plug and play" a statistical process or whether custom software is developed.
48.
In case of an orchestration tool, the technical environment must be very mature (as there is
little room to "glue" services together). There will probably already be a lot of services available,
because otherwise it will be impossible to create a complete statistical process.
49.
In case of custom software, there is much more room for improvising. Especially on the
roadmap towards a mature use of CSPA, this scenario is most realistic. This means that the
Assemblers are software engineers that must be prepared to use statistical services as much as
possible, even though they may not be used to it, when an Investor has made the decision to invest
in a ‘fit for purpose’ solution.
10
V.
50.
Executing a statistical process
A. Purpose
To execute an entire statistical process.
B. Primary stakeholder
51.
User (“process operator”).
52.
C. Secondary stakeholders
Service Provider, Environment Provider, Configurer, User (“worker”)
D. User stories
53.
There may be multiple users involved in executing a statistical process. In a very simple
case, where the process is completely automatic, the only user involved may be the person starting
and monitoring the execution of that automatic process (here referred to as the process operator).
54.
Usually, this will be a statistician. In a more complicated situation, the process may run for
longer periods, involve multiple people in the monitoring and control and may even have “workers”
inside the services to operate or even execute manual operations. Workflows may be used to inform
and coordinate the activities of human operators.
55.
Process Operators, i.e. Users monitoring and controlling the process, interact with the
communication infrastructure, whether that was implemented using a generic or a custom built
solution (ref. Chapter 4).
Executing an assembled statistical process
 The process operator uses the user interfaces generated by an orchestration tool to execute a
statistical process, given certain parameters (like: period, region, etc.).
 The process operator receives feedback about the process from the user interface.
 If errors occur, the process operator browses the log files generated by the communication
infrastructure to determine the cause(s).
Executing services using custom software
 The process operator runs the “custom software”, which makes calls to one or more
statistical services "under the hood";
 The custom software must handle any errors and report them to the operator.
56.
Whatever the implementation of the process orchestration layer, any errors in the
orchestration itself or in the (communication to the) services that the process relies on must be
logged and reported. The process owner or operator of the process must regularly check these logs
and reports and handle all incidents and problems.
11
57.
If the error originated from a technical failure inside a service, the process operator contacts
the Service Provider. In certain cases, it may be necessary to contact a Service Provider also in order
to dig deeper into the logs of particular services.
E. Stakeholder implications
58.
The User, who is a statistician, must bear in mind that generic tools are designed to ensure
the design-once-execute-anywhere paradigm. These tools have features to support statistical tasks,
but in most cases they will not be configured to be tightened to any specific statistical process. They
must be operated to combine the outputs from each task in the best suited way to obtain the desired
output.
VI.
59.
Creating a technical environment (communication infrastructure)
A. Purpose
To implement a local infrastructure for orchestrating services.
B. Primary stakeholders
60.
Environment Provider
61.
C. Secondary stakeholders
Designer, Assembler, Configurer, User
62.
D. User story
Needs further work, should include:


guidance on selecting main architectural pattern for NSI or part (domain) of an NSI
Criteria for selecting, Business case for selecting that pattern
E. Stakeholder implications
12