Coordination Support System in a Distributed
Collaborative Community
The requirements identified in the case study are synthesised and summarised into composite requirements for the purpose of convenience and brevity. As such, each composite requirement consists of both the functional and the non-functional requirement attributes from both macro and micro contexts. This infers that, for a
168
system to be successful, it is necessary to concurrently meet the functional requirement in conjunction w the non-functional requirement. Of course they remain tagged for traceability purposes, so as to pin point exactly what aspect needs to be accounted for, to fulfil the non-functional requirement of a function. Essentially, to find the variant that is required to satisfy the quality requirement, whether it reflects availability, capacity or continuity for instance.
The composite requirements tagged ‗RQ‘ in Table 5.4 brings together requirements with comparatively similar objectives for fulfilling a particular function. For example, a requirement of the ‗Enabling environmental‘ factor, as part of the macro context analysis in Table 5.1, the ‗socio economic‘ item suggests the need to facilitate resource finding and sharing (FR1 and 2), similarly, the strategy item of the management component, in Table 5.3, that forms part of the micro context analysis, suggests the need to ‗facilitate dynamic, collaboration opportunity identification (FR24)‘, thus are composed under RQ1 in Table 5.4. RQ1 suggests the need to facilitate streamlined coordination and more focused collaboration. Another example involves the ‗organisation/institutional factors‘, item 2.1 ‗work pattern‘, which calls for autonomous and loosely coupled work, and somewhat relates the non-functional requirement the management component item 1.2 ‗control‘ in Table 5.3, which suggests the need to preserve autonomy (NFR17), thus are classified together in RQ8. Furthermore, RQ2, suggests facilitating contact initiation (FR5) which reflects the requirement of item 1.6 ‗geographical distribution of workforce‘ in Table 5.1, which maps the need to facilitate ‗communication‘ FR29 of item 1.4 Table 5.3, for example. The section generally advocates that to ensure reliability and effectiveness of the proposed system both functional and the non-functional requirement must be accounted for. Thus, are composed in Table 5.4
The findings present several implications for designs to support coordination in a distributed environment. For instance, the findings suggest that the loosely coupled work patterns afford municipalities the authority and flexibility to deal with the unpredictability of the work setting without consulting others. As such, one effect for design is that the flexibility and autonomy afforded by loose-coupling must be preserved, as entities must contend with the unpredictability and uncertainty that the work settings present, often resulting in dynamic and unique requirements. The requirements presented in Table 5.4 should characterise designs that aim to support coordination in a distributed environment. A suggestion of possible solution characteristics is presented in the next chapter.
169
Table 5.4: Abstracted Summary Requirements
DESIGN REQUIREMENT REQUIREMENT DETAILS DESCRIPTION
RQ1: Identify/Match shared interests NFR1, 4; FR2,23,24 Facilitates streamlined and focused collaboration RQ2: Facilitate contact initiation FR5,29 NFR1,13,6 Facilitates interaction between possible collaborating entities
RQ3: Components interoperability NFR28,33; FR60,61 Promoting Open systems, Technology/semantic uniformity, Agreement /standardisation towards integration among different representations RQ4: Real-time federated data analysis
and forecasting (predictive/feasibility assessment) for decision making (
NFR,14 16,19,24,35; FR39
57,63,67, Facilitates decision making through streamlined analytics and forecasting RQ5: Seamless semantic/process/tools
integration FR14, R22,45,54,55,61
Facilitates ubiquitous accessibility of data and transcends beyond problems with exchanging data between applications to semantic integration of understanding those data.
RQ6: Agile process
definition/modularisation and
configuration FR6,11,18;58; NFR7,10,38
Represent the ability to respond to changes quickly to a given cooperative business process circumstances.
RQ7: Spontaneous communication NFR11,20 FR29,68 Support synchronous/asynchronous discussions and negotiation RQ8: Support autonomy and loose
coupling NFR2,5,6,17 Support jurisdictional constraints and desirable preferential connections. RQ9: Subscription/ Personalised
notification and recommendation FR1;2,4,27,28,47,49,50; NFR,30 Prevent information overload through tailored and streamlined service provision RQ10: Access control/compliance FR23,25,51 NFR17,18,27,31 Preserve logical autonomy, protect information integrity Clear-cut roles and responsibility
domains RQ11: Augment Shared workspace with
Cooperative Object sharing and
documentation support. FR2, 6,7, 68
Asynchronous/synchronous information transfer. Support the realisation that cooperative business processes leads to artefacts (documents, tools) which need to be shared among project community members.
RQ12: Dynamic and adaptive process composition (structured +unstructured) scheduling and execution
FR11, 12, 21,40, 41; 59; NFR2,12, 25,
The ability to compose services at various levels of granularity, with event-driven and
asynchronous styles of interaction that can account for various use scenarios
RQ13: Unified service access point FR55,56,57, NFR32 Single sign on point and access to resources and attain instant visibility into the entire workflow chain via a graphical, user-friendly dashboard. RQ14: Information diffusion, Context
awareness and reporting NFR1,3,4,8;R14,26,27,37,39 FR30,31,34,36,39,59,62;69
From organisational mindfulness, to taking cognisant of objects and their state of affairs in terms of teams and their subsequent activities, resource, and schedules among others, towards informed proactive behaviour.
RQ15:
Flexibly/Scalable/extensible/reusable/ distributable
NFR1,2,5 9,26,23, 34; FR42,66
Accounting for a greater degree of variability to support varying scenarios regardless of context + individual participation in shared processes regardless of location using smart endpoints. RQ16:Knowledge base support,
Content management (Smart Archiving/Knowledge sharing)
NFR10,29,31,35;37; FR39,48, 53,65
Managing and storing information, tailoring of content and advertising to a user's specific characteristics based on user information + support and augment, repository with semantic/ontology based indexing, search and retrieval features.
RQ17: Support for usability with User
interface adaptation NFR,32; FR54,57,42
Allow user interfaces to adapt to various contexts and thereby enabling a flexible and multi-purpose environment.
RQ18: Adaptive/Ad-hoc group
formation (structure ) FR3, 10, 3033; NFR7
Support dynamic formations of groups to augment governance models and clearly defined policies.
RQ19: Automation and customisation FR41,42,R43,44; NFR32
Support levels of customisation and process automation to streamline accelerate and standardise processes (e.g. complex procurement/deployment procedures). RQ20: Dynamic object administration,
tracking and configuration FR3,13,15,19, 20,25,30,31,32,33
The ability to design and document goals and administer objects through specifications, monitoring and evaluation, and rules to guide behaviour.
170
5.6 Conclusion
In this chapter a multidimensional requirement elicitation instrument was used as the basis to identify requirements that characterise coordination in a distributed environment. The case study illustrated the applicability of the instrument to gain insight into the requirement. Based on the instrument, the case study highlighted the characteristics that made explicit the requirements associated with coordination in a distributed environment. The analysis revealed the challenges associated with collaboration in the distributed environment, greatly influenced by the loose coupling pattern of work. The results provide evidence that the elicitation instrument is particularly useful in revealing obstacles to coordination from the case study. The findings imply that the technological inadequacies of the artefact or people and process can affect coordination. The problem of coordination is identified as crucial in the public sector. Existing tools for coordination in the sector, for instance phone, e-mail or fax, are limited with respect to the issues identified; especially relative to certain issues, viz. it is not always clear what has been already done by whom, what is currently going on and what the next steps are.
The need to coordinate has conditioned various government agencies to expect up-to- date information regarding training. Unfortunately, these expectations are not being adequately fulfilled, as the existing information technology tools, architectures and frameworks of the government are not comprehensive, sufficient or suitable. In fairness, efforts have been made towards organising communication, information flow and decision making structures, whether formal or informal structures; however, the problem is perceived in terms of effectiveness and efficiency. Unfortunately, the current state of the information sharing between agencies, institutions, and other third parties, as well as the level of tools to query, infer, and reason intelligently over the cumulative data, do not meet these expectations adequately. Essentially, there are no tools to make intelligent queries or reasonable inferences from the applicable data. The case study approach provides significant benefits relative to features that should be considered in design to account for coordination in a distributed environment.
The requirements suggest the need for a solution that is context sensitive, and capable of providing coordination support for activities of collaborating organisations in dynamic situations. Given the requirements identified the research advocates that a virtual community perspective provides great potential, as it can be leveraged as a decentralised coordination support collaborative infrastructure. The identified requirements suggest a perspective that should be leveraged to inspire collaboration, guide improvement and enable the alignment of cooperative strategies in conjunction with their execution, visibility into the impact of decisions, collaborative opportunities,
171
the execution of decisions and actions, and the ability to track deviations from goals. The subsequent chapter looks to satisfying the requirements identified in this section, by designing a model to support the coordination of a distributed collaborative community through leveraging the virtual community infrastructure from a service perspective.
172
PART C
Taking into consideration the requirement sourced in ‗Part B‘ and the lessons learnt from the evidence based knowledge revealed in ‗Part A‘, ‗Part C‘ concerns the formative development of the solution model, towards an IS design theory. The solution artefacts provide knowledge-driven guidance as to how to design and support an IS solution for coordination support in a heterogeneous and distributed environment. The primary contribution of ‗Part C‘ constitutes a model artefact and supporting architecture, predicated in design support principles identified in Part A. Therefore, ‗Part C‘ resolves the query: ―What are the elements/constructs that characterise the solution space and how can they be interwoven to support coordination in the SA public sector?‖
The answer is divided in two chapters. Chapter 6 provides the conceptual foundation of the solution artefacts, while Chapter 7 supplies a more detailed, comprehensive discussion regarding the functions of the proposed artefacts, their constructs and relationships.
174
CHAPTER 6
MODEL CONCEPTUAL FOUNDATION
After defining the research objectives, reviewing related work and examining relevant technologies the thesis now moves on to propose a solution. The primary question to be answered in this chapter is: What functionality should characterise a model aimed at supporting coordination in a distributed environment? With this query, the current chapter overviews the model aimed at addressing the problem of coordination in the distributed South Africa public sector, with the model definition progressing from a conceptual aspect to a more comprehensive, detailed view.
The model is prescriptive, in that it defines the core features and functionality, from which an implementation can be developed. The core is drawn from previous research and relevant technology architectures. The characteristics that influence the design of the model are derived through analysis of the distributed environment. The correlation and combination of proven theories and existing technologies, with specific focus on facilitating coordination, allows the achievement of a unique combination; thereby facilitating and producing a novel approach to the research problem.
The current chapter provides a conceptual overview of the model. In order to provide an overview of the situation, the next section reviews the problem domain from a high-level perspective. This is followed by an introduction of the model and its components. Thereafter, the functional scope of the architecture is described, defining the core features and functionality of the supporting architecture. This is succeeded by the design consideration and a discussion of the underlying design principles, followed by an overview of the primary constructs and relationships which form the building blocks for the model, and thus the subsequent chapters. The model is then summarised, followed by the conclusion of the chapter.