5. Representations Extensions
5.1.2. Graphical representations applied to a generic framework
framework composed by the levels technology, applications, data, business and strat- egy. Since a specific framework is not analyzed, it is not possible to state exactly what are the modeling languages used in each level. Anyway, considering the definition of each level, it is possible to identify some representations used. For each representa- tion, it will be shown a possible way to extend it, in order to highlight the main issues related to the shift in a cloud environment. The extensions we propose, appear in each representation as icons of different colours. Each icon identifies one issue related to the cloud readiness of the company.
A list describing each icon, follows.
Application Credential Protected: the credentials of the ap- plication must be protected.
Encryption System Conform to Standard: the encryption sys- tem used should conform to the existing standards.
Storage & Usage of Data Encryption: data must be secured - that is, encrypted - during the storage and the usage. Encryption of Keys: encryption keys must be protected - that is, encrypted.
Assets Audits: assets should be subjected to periodical au- dits.
Risk Analysis: a risk analysis of the assets and applications should be performed.
Encryption needed: encryption of data and applications
needed.
Redesign Needed: application redesign needed, to guaran- tee portability and interoperability.
Service Availability: service availability issues.
Compliance: compliance with existing privacy regulations.
Multiple Access: presence of multiple access of a resource.
Customized: applications and data formats are customized, that is not in accordance to any standardm or adapted from a standard specification.
Standardized: applications and data formats are standard- ized, that is, they are in accordance to a specific standard.
Personally identifiable information: privacy type of a datum.
Sensitive information: privacy type of a datum.
Information categorized as sensitive: privacy type of a da- tum.
Usage data: privacy type of a datum.
Unique device identities: privacy type of a datum.
Technology
The technology level deals with the description of the infrastructure of the company. Software and hardware elements that support the application layer are represented to- gether with their interrelations, as shown in Figures 5.9 and 5.10 (adapted from Hinkel- mann (2011)). The main elements that can appear in this level are physical devices, networks or software, like operating systems, middleware or databases.
This level is mainly affected by the area of governance and risk management. In partic- ular, the company has to be compliant to laws and internal regulations. For this reason, the assets represented in this level, that need to be inspected should be marked. The different types of inspection is strictly related to the company. In general terms, there can be identified at least two different types of control. The former deals with the ne- cessity to perform, periodically, assets audits. The latter deals with the analysis of the risk associated to specific assets, considering different scenarios.
The presence of databases, anyway, could lead to the necessity to indicate that there are data that must be managed carefully because of privacy concerns. If there is a database which includes a datum that belongs to one of the category described in Chap. 4, it has to be marked with a symbol expressing the presence of privacy issues.
Figure 5.9.: Graphical representation of the technology level adapted from Hinkelmann (2011)
Concerning the applications, in the current level, they just inherit their features de- scribed in the application level. All the symbols used to mark a specific application will be reported in this level.
Applications
The application level describes the applications used by the company. This includes their internal behavior and structure, as shown in Figure 5.11 and 5.12 (adapted from Hinkelmann (2011)), the interrelations between them, as well as how they are used by other applications.
The main graphical extensions for this level deal with different issues. First of all, con- sidering the area of application security and encryption, each application should be marked in order to show their level of security should be increased, in order to go into the cloud. It is also necessary to perform risk analysis determined by laws or inter- nal regulations. Moreover, each application should be classified considering the level of standardization. Applications can use interfaces which are standardized or cus- tomized. The type of the interface used by an application is reported in the graphic of the application itself. If the interface is customized, then the application needs a re-
Figure 5.10.: Graphical representation of the technology level adapted from Hinkel- mann (2011)
design. The necessity of a redesign is communicated by using a special icon. Please notice that a scenario in which an application needs a redesign and it uses a standard- ized interface, must not happen.
In addition to that, it is also necessary to consider the need to encrypt the files used by the applications. This can be done, for instance, by adding a symbol in the represen- tation of the interactions of a specific application.
If an application deals with data considered as private, then the application itself should be labeled with the privacy icon (see Figure 5.11).
Data
The data level, intuitively, aims to represent the data used by the company. They can be represented in many ways, by using different models. Anyway, talking in general terms – that is without considering a specific framework and, thus, a specific represen- tation for the current level – the data used by the company and the relations between them can be described, for instance, with a UML diagram. It can be hypothesized that another alternative would be to use a terms and fact types representation or an E/R diagram.
Nevertheless, each datum used by the company has some specific values considering its sensitiveness. As already explained in Chapter 4, data can be grouped in different categories, which are personally identifiable information, sensitive information, infor-
Figure 5.11.: Graphical representation of an internal behavior of an application adapted from Hinkelmann (2011)
mation categorized as sensitive, usage data and unique device identities.
The graphic representation used in the current level, without considering the specific language or standard chosen, will include some symbols expressing the features of a specific data. There will be as many symbols as the number of the different categories of data. In this way, it will be possible, for instance, to understand the type of a specific datum that an employee is managing. If a datum is referenced by a model of another level, all its features will be included in the representation. As an example, if a business process description has a reference to a specific datum that is classified as “sensitive information”, the business model will include the datum used, marked with the special symbol expressing the category it belongs to.
Business
As can be seen in Figure 5.8, the business level is mainly affected by the service avail- ability problem. A possible representation which deals with this layer is the description of a business process. The representation proposed in Figure 5.14 is based on the Business Process Modeling Language. Anyway, the approach used to mark specific tasks or elements used in the process, is independent on the language used.
Figure 5.12.: Graphical representation of a structure of one or more applications or components adapted from Hinkelmann (2011)
if a specific process is at risk of service availability. For this reason, the overall pro- cess should be marked with a symbol expressing the degree of service availability that should be guaranteed. The definition of the degree and a proposal of the symbols can be found in the knowledge representation section. As explained later on, it’s important to take into account that the problem of service availability is strictly related to a specific cloud provider. This means that it is not possible to say if a process is highly risky or is safe without considering the capabilities of the cloud vendor or the service offered by it.
Nevertheless, there are some features of the process, still related with service avail- ability, that can be represented in any case. As explained in the next section, these features are related to the presence of a deadline and multiple access to a resource. Each activity which requires multiple access to a resource, will be marked with a special symbol. The same applies when an activity is managed by the presence of a deadline. The description of business processes can include also some documents or data stor- age used during the activities described. Even if they are represented, in a more detailed way, at different levels of the architectural description, it would be preferable to add some indications of their characteristics – if necessary. This means that if a business process uses a document that is considered as sensitive in the data level, this information should be reported also in the description of the business process. It is possible to hypothesize that, once the features of a specific datum are defined at the data level, they can be automatically reported in the business process description, by simply referencing that specific datum. This is why in Figure 5.14 the document used
Figure 5.13.: UML graphical representation for the data level
has a symbol showing that it’s sensitive.
Strategy
As is possible to see in the matrix in Figure 5.8, the strategy level is the unique level not affected. It does not need a graphical extension. It can be hypothesized that possible representation models would be the Business Motivation Model or organization mod- els. In this level the company expresses which goals it would like to reach and what are the actions needed to do it. Of course, the decision of the usage of an encryption algorithm or the categorization of the data used, impact this level. Nevertheless, sym- bols expressing possible cloud computing issues don’t give any additional value in this level, since it just describes the strategy that the company would like to have.
As already shown, the symbols used are quite specific and they express possible dan- gers related to assets, data or information used, features of the processes. This is the reason why they are used in the lower levels of the generic framework considered.