Multi-channel provisioning of public services - Department of ...

Discussion and evaluation
Considering the flexibility for change, the flexibility for the regular user is considered
as predefined, or as naturally limited by the complexity that arises when the number of
possible changes increase. The lead user will, as suggested by the requirements, go
beyond the scope of the lead user as suggested by Von Hippel (2005) and C2. The
requirements propose that the lead user not only has available the tools to create and
modify services based on the flexibility provided by the infrastructure, but that the lead
user additionally can create functionality that extends the infrastructure and its
flexibility. This suggests competencies within the role of the lead user that today would
be found in a high-level system developer. It is possible that these roles should be
separated, or remain integrated, depending on the future direction of software
development and the capabilities of future technology affordances (e.g. through support
for AKM, BPM or SOA approaches).
C4: A conceptual design for a national e-service infrastructure
The proposed citizen-centric process views design artefact is a conceptual model
constructed to support C1 - C3. The design artefact addresses RQ3 and is discussed in
P3, P4, and P8 and is influenced by P2, P5, and P6. It is additionally suggested based on
an investigation of RQ4. The discussion of C4 is limited to the iterative construction
and evaluation of the artefact up to its current state.
The initial version of the design artefact presents a model involving concepts related to
a process-oriented service delivery with several actors organised in a virtual
organisation around a process instance supported by an interactive process template.
Although a direct implementation is not discussed, the concept is proposed as
middleware, suggesting that its capabilities are found between existing systems
providing an extended SOA functionality. It is suggested that it can be used directly
through its own presentation layer, or plugged into an installed base through
connections that can be reused and shared once developed.
Although the initial version was followed up with case studies P5 and P6, few changes
were done to the model as presented in P4, besides the fact that P4 focused on a limited
view of the model. Feedback from presenting P3 and from the reviewers of P4 did
however affect the positioning of the contribution: i) Using the term middleware in
describing the design possibly brought negative connotations due to past experiences
among reviewers, suggesting a rebranding. ii) The information infrastructure, and thus
the socio-technical, aspects of the problem environment seemed too apparent to be
disregarded as part of the design. The current understanding of information
infrastructure has in this sense developed during the study. Even though the study
mainly perceives the design artefact as a technological platform for public service
delivery, it additionally presumes organisational arrangements so as to suggest that the
technological construct acts as a facilitator, and that the design solution lies in the
interplay of technical and non-technical stakeholders.
Through viewing the design artefact as an interwoven component of an information
infrastructure, its evaluation is perceived as problematic. Or as stated by Ciborra:
78