GP.Workspace: Difference between revisions
m (Jan Schoonderbeek moved page GP.User Workspace to GP.Workspace) |
(smaller pic) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{Maturity| | {{Maturity|4}} | ||
{{Pageheaderbox4GP | {{Pageheaderbox4GP | ||
|name= | |name=Workspace | ||
|sector=Commons | |sector=Commons | ||
|version=0. | |version=0.5 | ||
|owner=J.A.H. Schoonderbeek | |owner=J.A.H. Schoonderbeek | ||
|summary=This Pattern models the | |summary=This Pattern models a gateway between the physical and digital world, such as a user workspace. | ||
}} | }} | ||
This Pattern models the generic user workspace. The goal of this pattern is to | This Pattern models the generic (user) digital workspace, which acts as a gateway between the digital and physical world. The goal of this pattern is to provide a digital consumer (applications and/or other ICT systems) a means to interact with the physical world, including the human users of ICT. | ||
By and large there are three types of workspace: | While the Pattern can be used to model many systems varying from smart watches to multifunctional workgroup printers, its main application is in the modelling of a user workspace. | ||
# A "fat client": a workspace that delivers its | By and large there are three types of user workspace: | ||
# A " | # A "fat client": a workspace that delivers its consumers (most or all) computational resources from the location of the human user, resulting in less dependence on the organization's central IT. However, the consumers running on the workspace may well make use of centralized resources such as shared file storage, and the workspace itself may be serviced from a centralized facility, e.g. applications may be deployed from a remote deployment service. The applications running locally, and the human user working the applications, can have all necessary rights and abilities to manage the workspace, or these rights and abilities can be partially or wholly restricted, e.g. by centrally managed policies | ||
# A " | # A "virtual desktop" providing consumers with a centralized personal workspace: the workspace has all the properties of a fat client, except that the computational resources are delivered from one or more centralized locations. At the physical location of the human user, an extra workspace is required for handling the actual physical input and output, using connectivity to the centralized location to transmit the digital input/output. This may involve only a minimal device ("thin client"). | ||
Note that while the fat client and thin client characterizations point toward "traditional" computers, this Pattern is equally suitable to model different form factors, purposes and information delivery, ranging from tablets and mobile devices through gaming consoles and wearable IT. The different form factors and other properties of these clients are then represented in the | # A "shared applications environment" providing access to a centralized shared workspace: the workspace has the properties of the centralized personal workspace, except that groups of human users share the same workspace, with limited or no personalization, and little or no flexibility in installing applications for the user itself. Every update or new application is handled at the centralized location, resulting in uniform workspaces between users in the same group, and predictable maintenance load for the centralized facility. | ||
Note that while the fat client and thin client characterizations point toward "traditional" computers, this Pattern is equally suitable to model different form factors, purposes and information delivery, ranging from tablets and mobile devices through gaming consoles and wearable IT. The different form factors and other properties of these clients are then represented in the Input and Output functionality, and in Workspace Accommodation if need be. | |||
While Workspace implementations often use the desktop computer metaphor, OIAm's use of the term is not limited to facilities that can deliver a user the desktop experience. Other devices and systems may also be modelled, as long as either user input and/or output are present. Examples are multifunctional workgroup printers (a single printer directly attached to a single user workspace is better represented as an Output function instance), surveillance camera systems, telemetry platforms, CNC ([http://en.wikipedia.org/wiki/Numerical_control Computer Numerical Control]) systems and most any other system that interacts with the physical world. | |||
The Pattern often depends on many adjacent services, only some of which have been included in this Pattern Type description. | |||
{{Pattern Realizes | {{Pattern Realizes | ||
|service=GS. | |service=GS.Workspace | ||
}} | }} | ||
{{Pattern Graphic | {{Pattern Graphic | ||
|graphic= | |graphic=GP.Workspace.png | ||
|source=GP. | |source=GP. | ||
|size= | |size=600px | ||
|kind=Generic | |kind=Generic | ||
}} | }} | ||
{{Generic Pattern Composition}} | {{Generic Pattern Composition}} | ||
{{Generic Pattern Composition Row | |||
|function=GF.Workspace Engine | |||
|choice=Must | |||
|reason=This function provides the main functionality of the pattern: the support of applications. | |||
}} | |||
{{Generic Pattern Composition Row | |||
|function=GF.Presentation Engine | |||
|choice=Must | |||
|reason=Output to, and input from the physical world will surely require appropriate formatting and/or processing. For example, camera images presented by [[GF.Input|Input]] may require a form of compression (not separately included in the Pattern), while force feedback output will require adaptation to the format in use at the targeted [[GF.Output|Output]] device. | |||
}} | |||
{{Generic Pattern Composition Row | |||
|function=GF.Output | |||
|choice=Must | |||
|reason=This function provides the actual output to the physical world. | |||
}} | |||
{{Generic Pattern Composition Row | |||
|function=GF.Input | |||
|choice=Must | |||
|reason=This function provides the actual input from the physical world. | |||
}} | |||
{{Generic Pattern Composition Row | |||
|function=GF.Controlling | |||
|choice=Must | |||
|reason=This function models the manner in which the Pattern's administrators, and possibly authorized clients, can administer the Workspace. Among the administrative tasks can be the following: | |||
* Administering look & feel of the Workspace as it presents itself to a (human or ICT) consumer; | |||
* Configuring input & output parameters; | |||
* Administering updates, policies, logging, and other operational and security related parameters. | |||
Care must be taken to limit access to this function to users that are sufficiently knowledgeable and authorized, as misconfiguration likely impacts both operational efficiency and IT security. | |||
}} | |||
{{Generic Pattern Composition Row | |||
|function=GF.Workspace Accommodation | |||
|choice=May | |||
|reason=Accommodation covers mainly physical traits of the workspace, including how the workspace is projected from the place of generation (e.g. server farm) to the location of use (e.g. a user's office). Accommodation is regularly used to describe the functionality of a "thin client", negating the need to separately model this client as a physical Workspace that supports a centralized virtual Workspace. | |||
}} | |||
{{Generic Pattern Composition Row | |||
|function=GF.Logging | |||
|choice=May | |||
|reason=As the interaction with the physical world and with human users gives greater rise to incidents, good logging is recommended for both operational and security purposes. | |||
}} | |||
{{Table Ending}} | {{Table Ending}} | ||
{{Pattern Adjacent Services}} | {{Pattern Adjacent Services}} | ||
{{Generic Pattern Adjacent Service Row | |||
|service=GS.File Storage | |||
|choice=Must | |||
|reason=The way in which the Workspace stores data and other files may be either local to the physical device (in which case it can be included in an applied version of this Generic Pattern), or relegated to a centralized service. | |||
}} | |||
{{Generic Pattern Adjacent Service Row | |||
|service=GS.Authentication+Authorization | |||
|choice=May | |||
|reason=Often the normal interaction with human users will require Authentication, as in the case of a regular user workspace (but not in the case of, for instance, a kiosk system). But even if this is not the case, then still Authentication & Authorization is recommended for the [[GF.Controlling|Controlling]] functionality. | |||
}} | |||
{{Generic Pattern Adjacent Service Row | |||
|service=GS.Facilities Monitoring | |||
|choice=May | |||
|reason=Workspaces often form a significant load on operational support, and are also regularly a concern for security personnel. Monitoring (often subdivided into operational and security monitoring) helps inform these groups of incidents, status and general use of Workspace instances. | |||
}} | |||
{{Generic Pattern Adjacent Service Row | |||
|service=GS.Facilities Deployment | |||
|choice=May | |||
|reason=Workspace facilities may be instantiated many times, as can be seen with user workspaces. In that case, use of a Facilities Deployment service may reduce operational effort and response times, while increasing quality and uniformity. | |||
}} | |||
{{Table Ending}} | {{Table Ending}} | ||
{{Text Footer GP}} | {{Text Footer GP}} |
Latest revision as of 22:10, 19 April 2015
Page maturity This page has maturity level 4 (mature) |
GP | Workspace | Version: | 0.5 | ||
---|---|---|---|---|---|
Document type: | Generic Pattern | Owner: |
This Pattern models a gateway between the physical and digital world, such as a user workspace. |
Description
This Generic Pattern belongs to "Commons". This Pattern models the generic (user) digital workspace, which acts as a gateway between the digital and physical world. The goal of this pattern is to provide a digital consumer (applications and/or other ICT systems) a means to interact with the physical world, including the human users of ICT.
While the Pattern can be used to model many systems varying from smart watches to multifunctional workgroup printers, its main application is in the modelling of a user workspace. By and large there are three types of user workspace:
- A "fat client": a workspace that delivers its consumers (most or all) computational resources from the location of the human user, resulting in less dependence on the organization's central IT. However, the consumers running on the workspace may well make use of centralized resources such as shared file storage, and the workspace itself may be serviced from a centralized facility, e.g. applications may be deployed from a remote deployment service. The applications running locally, and the human user working the applications, can have all necessary rights and abilities to manage the workspace, or these rights and abilities can be partially or wholly restricted, e.g. by centrally managed policies
- A "virtual desktop" providing consumers with a centralized personal workspace: the workspace has all the properties of a fat client, except that the computational resources are delivered from one or more centralized locations. At the physical location of the human user, an extra workspace is required for handling the actual physical input and output, using connectivity to the centralized location to transmit the digital input/output. This may involve only a minimal device ("thin client").
- A "shared applications environment" providing access to a centralized shared workspace: the workspace has the properties of the centralized personal workspace, except that groups of human users share the same workspace, with limited or no personalization, and little or no flexibility in installing applications for the user itself. Every update or new application is handled at the centralized location, resulting in uniform workspaces between users in the same group, and predictable maintenance load for the centralized facility.
Note that while the fat client and thin client characterizations point toward "traditional" computers, this Pattern is equally suitable to model different form factors, purposes and information delivery, ranging from tablets and mobile devices through gaming consoles and wearable IT. The different form factors and other properties of these clients are then represented in the Input and Output functionality, and in Workspace Accommodation if need be.
While Workspace implementations often use the desktop computer metaphor, OIAm's use of the term is not limited to facilities that can deliver a user the desktop experience. Other devices and systems may also be modelled, as long as either user input and/or output are present. Examples are multifunctional workgroup printers (a single printer directly attached to a single user workspace is better represented as an Output function instance), surveillance camera systems, telemetry platforms, CNC (Computer Numerical Control) systems and most any other system that interacts with the physical world.
The Pattern often depends on many adjacent services, only some of which have been included in this Pattern Type description.
Services realized
This Pattern realizes the following service(s):
- Workspace (This Service delivers a (generic) digital workspace, which acts as a gateway between the digital and physical world.)
Functional and Integration view
This is the graphic representation of the functional model of this Generic Pattern:
Generic Pattern Composition
This pattern is an aggregation of the following (mandatory and optional) functions, expressed in Generic Functions:
Icon | Function | Inclusion | Rationale |
Workspace Engine | recommended | This function provides the main functionality of the pattern: the support of applications. | |
Presentation Engine | recommended | Output to, and input from the physical world will surely require appropriate formatting and/or processing. For example, camera images presented by Input may require a form of compression (not separately included in the Pattern), while force feedback output will require adaptation to the format in use at the targeted Output device. | |
Output | recommended | This function provides the actual output to the physical world. | |
Input | recommended | This function provides the actual input from the physical world. | |
Controlling | recommended | This function models the manner in which the Pattern's administrators, and possibly authorized clients, can administer the Workspace. Among the administrative tasks can be the following:
Care must be taken to limit access to this function to users that are sufficiently knowledgeable and authorized, as misconfiguration likely impacts both operational efficiency and IT security. | |
Workspace Accommodation | optional | Accommodation covers mainly physical traits of the workspace, including how the workspace is projected from the place of generation (e.g. server farm) to the location of use (e.g. a user's office). Accommodation is regularly used to describe the functionality of a "thin client", negating the need to separately model this client as a physical Workspace that supports a centralized virtual Workspace. | |
Logging | optional | As the interaction with the physical world and with human users gives greater rise to incidents, good logging is recommended for both operational and security purposes. |
Services connected with this Generic Pattern
This Generic Pattern has the following mandatory and optional relations with adjacent Generic Services.
Service | Adjacency | Summary | Rationale |
File Storage | recommended | This service offers clients the ability to store, retrieve and modify data in loosely structured form. | The way in which the Workspace stores data and other files may be either local to the physical device (in which case it can be included in an applied version of this Generic Pattern), or relegated to a centralized service. |
Authentication & Authorization | optional | This service can validate an identity claim, and it can validate the permissions required for an action, as part of an Authentication & Authorization process. | Often the normal interaction with human users will require Authentication, as in the case of a regular user workspace (but not in the case of, for instance, a kiosk system). But even if this is not the case, then still Authentication & Authorization is recommended for the Controlling functionality. |
Facilities Monitoring | optional | This service allows its users to monitor IT facilities with the aim of guarding operational continuity or security. | Workspaces often form a significant load on operational support, and are also regularly a concern for security personnel. Monitoring (often subdivided into operational and security monitoring) helps inform these groups of incidents, status and general use of Workspace instances. |
Facilities Deployment | optional | This Service can deploy the software part of an IT systems, and/or configurations thereof. | Workspace facilities may be instantiated many times, as can be seen with user workspaces. In that case, use of a Facilities Deployment service may reduce operational effort and response times, while increasing quality and uniformity. |
Applied Patterns based on this Generic Pattern
The following Applied Patterns are based wholly or in part on this Generic Pattern: