OIAm Quality Attributes


previous : Infrastructure architecture and the architectural process	up: table of contents	next: The OIAm Building Blocks Model

Adaptability

A solution’s adaptability determines how easy or difficult it will be to make a change to the solution. Adaptability can be achieved by designing modular systems (using standard components), applying standardized protocols and tools and limiting the complexity of offered functionality (services).

Scalability

A solution’s scalability determines how easy or difficult it will be to alter the capacity of the solution. Infrastructure solutions have both an internal and an external scalability. Internal scalability is achieved by the expandability of individual components making up the solution, whereas external scalability can be achieved by using components in parallel. When determining the scalability of a solution, it is advisable to devote extra attention to interfaces and aggregation points, because this is where most bottlenecks and integration issues will occur.

Availability

A solution’s availability determines the guarantee that the solution will correctly and adequately work within the constraints of time, depending on the input provided. This does not just mean that the functionality "will work", but also that the specified performance will be achieved, based on the expected input. The guaranteed availability of infrastructure is usually increased (in terms of performance and accessibility) by using several instances of the service. To utilize this higher level of availability, the application architecture must be aligned accordingly.

Integrity

A solution's integrity determines to what degree it is armed and protected against abuse, tampering, vandalism and/or malicious input. The more countermeasures are taken, the higher the degree of integrity is that can be guaranteed. However, applying many provisions to safeguard integrity often has an important drawback: The ease of use (the 'utility-value') of a facility/product will be reduced severely. Therefore, selecting a solution with a certain Integrity rating should be in line with the risks that are expected/applicable. Possible measures to increas integrity are

authentication/authorization: based on identity, a user/administrator will be given access and assigned a role, enabling him/her to access and edit certain data
accounting/auditing/logging: actions by users/administrators are logged to be able to trace misuse;
barring: confidential data will be usable/viewable only by authorized users/administrators;
guaranteed authenticity/non-repudiation: demonstrably shows that data originating from a source the user/administrator trusts is authentic and has not been tampered with.

Integrity measures are often complementary, and in many models availability is an element of integrity. Therefore, "CIA" encoding is often used to classify data, enabling data and applications to be categorized according to availability, integrity and confidentiality. OIAm respects this categorization, but has opted to use its own categorization of the architectural process, to assure a complete implementation of the "availability" quality attribute.

The biggest risk with integrity is that it will be seen as a goal and not a means to achieve a goal, thus unnecessarily frustrating usage and management requirements through overly stringent security measures. Security requirements should therefore always primarily be related to everyday practice and the standards that apply in that setting. This will put the technical security measures into the right perspective.

Manageability

A solution’s manageability determines how difficult or easy it will be to keep a system operational. Standardized safeguards (monitoring and alerting) can help to enhance manageability whilst consideration must be given to the additional expertise needed by system administrators, as well as the standardization and complexity of managed service interfaces and tools.

Accountability

A solution’s accountability determines how easy it will be to measure and charge usage costs. Defining units, such as building blocks and elements, and their related costs (procurement, operating and removal costs) will facilitate the accountability of a solution.

Quality attribute wrap-up

OIAm does not prescribe any particular quality attributes and the attributes above give no more than an indication of possible definitions. Each organization may assign its own definition to quality attributes. The six quality attributes here are the ones most appropriate to the "infrastructure as utility" objective, but other quality attributes may also be meaningful within a certain context or a certain organization. Provided that quality attributes are not imposed by other specialized areas, but are inherently suited to their own area of specialization, they will be legitimate. Extraneous quality attributes may appear to work within the dialogue, but will ultimately prove meaningless when engineering workable solutions.

It often proves difficult to provide a complete list of quality attributes at the outset of a project. During the architectural process, quality attributes will be weighted and given the appropriate priority. Therefore, during the engineering process (when the focus is a specific solution in a specific context), it may be necessary to further elaborate on relevant quality attributes. Ideally, the infrastructure test plans will also be drawn up in the engineering phase, which will result almost automatically in a more detailed specification of the quality attributes.

OIAm gives quality attributes an explicit role within the Building Blocks Model. This meta-model aids a logical, functional description of infrastructure facilities, as demonstrated in the following section.


previous : Infrastructure architecture and the architectural process	up: table of contents	next: The OIAm Building Blocks Model