The Uncontrolled Distribution of Components

'The Uncontrolled Distribution of Components'

By . Jaap Schekkerman, B.Sc, 1996

The relation between the design process and architecture. 3

The importance of architecture of information systems. 5

“The quality of application partitioning architectures will vary widely, yielding some high-quality solutions and many significantly unusable implementations” (Gartner Group, 1995)

The rise of distributed information systems generates new challenges in system development. During the design phase one needs to answer the question “how do I partition my information system, where do I place the components and how do these components depend on each other ”. In order to solve this distribution problem, one needs to survey the entire information system, including its environment, and consider the additional design criteria from a distribution perspective. As a consequence, designing distributed information systems is considerably more complex than designing centralised information systems. By including the distribution aspects in the architecture of the information system, a structure is offered to manage this complexity. To design such an architecture, a method is required that covers all aspects involved.

Introduction

The increasing use of distributed information systems is related to a number of developments in information provision and in information technology, like:

· The growing need to deliver information and information processing closer to the (end-) user and consumer;

· The increasing penetration of information technology in organisations and society (e.g. personal computers, local networks, Internet);

· The growing need for flexible, modular information systems to support business changes;

· The rise of middleware which offers a transparent mechanism for distribution;

· The rise of CASE tools that offer distribution capabilities to the system developer.

Besides the increase in the number of distributed information system or applications, it appears that the measure of distribution is increasing too:

· From local-area, via wide-area to enterprise-wide information systems;

· From 2-tier Client/Server, via 3-tier Client/Server to co-operative network architectures.

Figure 1: Increase in the measure of distribution of information systems

Distribution of an information system means that one needs to consider an extra dimension in the development process: topography. This extra dimension has two major impacts. First, this dimension makes the design process more complex. The designer of a distributed system has a larger number of variables more than before. He himself will have to determine how to partition, and where to place the components, where earlier this was defined by the chosen technology and programming language. Due to the advance in technology, as with middleware and software components like Javabeans and ActiveX controls, the complexity of designing a distributed information system has not decreased, but increased for the designer.

Second, through the extra dimension of topography, a thorough design has become crucial. Incorrect choices can have severe impacts on management properties (global deadlocks) and user properties of the system (for instance: performance, manageability and flexibility). The distribution design has a big influence on the eventual quality of the information system.

For this reason, the question tied to the distribution design, “How do I partition my information system, where do I place the components and how do these components depend on each other?”, is the central topic in this article.

The main problem in answering this question is that existing methodologies and techniques for development of information systems do not or insufficiently support the (more complex) design of distributed information systems. The dimension ‘topography’ is not considered in the development process, criteria for partitioning of the system are absent and the confrontation with the technical capabilities is insufficient.

In this article, first the relation is defined, based on the previously posed question, between the design process and the concept 'architecture' that will fulfil a key role. Next, how to define the architecture of distributed information systems is discussed.

The relation between the design process and architecture

The introduction already stated the importance of the distribution design. A distribution design gives structure to the information system and forces order and discipline on the realisation of the information system. A structure for an orderly building process has been indicated for ages with the term “architecture”. Architecture is extremely important in the physical world of houses, cities, roads and bridges. Architecture is even more important in the ‘mental’ world like information provision, because maintaining overview is many times more difficult when matter is not tangible. For a closer introduction of the concept architecture see the frame ‘Architecture in the information provision’.

The relation between the design process and architecture is illustrated in the figure below. In the column on the left, the information provision is schematised. The organisation & (need for) information is supported by information systems based on the technical infrastructure. If a method is used in the development of the information system (middle column) that does not, or insufficiently handles certain design aspects, or insufficiently guarantees certain quality aspects, then architecture offers effective support. The architecture of the information system (right column) is determined by the confrontation of the architecture of the organisation & information with the architecture of the technical infrastructure. The information system architecture is further dictating the system design and determines the complete structure of the information system.

Figure 2: Relation between development process and architecture

Especially with traditional system development methods the risk of sub-optimisations exist: solutions that are introduced in the course of the functional and technical design, that damage the quality of the entire information system. During the design of the architecture, such risks can be identified in an early stage, which can prevent errors, impossibilities or superfluous work during the realisation phase. Due to the ability of an architecture to warrant usability, durability and feasibility for the entire object, an architecture offers a solid structure as a foundation for the succeeding design process of the information systems.

Architecture in IT

Architecture is a frequently and widely used concept. For orientation purposes, we form a short definition of the concept architecture and discuss the usability features of architecture. Next, the sub-architectures of information provision are distinguished, as used in this article.

Architecture is a feasible and durable description of an object that is useful in a specific situation. In general an architecture embraces the object style, structural engineering and construction doctrine of the object:

· The object style defines the shape, the exterior of the object. Deciding for the shape is the function that the object will fulfil, and the way in which it will be experienced by the user (look-and-feel). In this way, the object style defines the usability of the object.

· The structural engineering defines the coherence and internal structure of the object. It defines which provisions are necessary to ensure that the object remains. In other words, structural engineering defines the durability.

· Finally, the construction doctrine describes how to transform the desired object into a concrete object. The object style and structural engineering together define what is to be built. The construction doctrine defines the feasibility of the object.

The usability features of architecture are:

· Architecture can function as a roadmap for management. In this context, the term ‘Development plan’ can also be used. It defines a vision; a complete overview of the future object. It can consequently serve as a guide for investment and migration.

· Architecture can be used for complexity control. It illustrates the shape, content and relationships, and hence offers the structure or ‘blueprint’ of the object.

· Architecture can be used as a frame for realisation of the object by offering standards & guidelines. It is a means of communication, both for internal and external use, which can enforce the desired order and discipline in the realisation phase.

Since information provision embraces multiple abstraction levels, and is viewed from different angles, a single architecture is not practical. In this article we use three sub-architectures on which we further discuss architecture design with distributed information systems, namely (see also the figure below):

· Organisation & information architecture: describes the process and information components of the desired information provision. Typically the result of a process/information modelling stage. This is the working area of the information-architect.

· Architecture of the technical infrastructure: describes the components of the technical infrastructure and their relationships, including the standards and products (hardware, system software) to be used.

· Information system architecture: describes data and the application components (modules) of the information system, their location and their mutual relationships. The information system architecture describes therefore the portions of the information system (the ‘software’) and consequently the compromise between the organisation architecture (what we want) and the architecture of the technical infrastructure (what we can).

Figure 3: Sub architectures of information provision

This article focuses on the design of information system architecture for distributed information systems. For the design of a distributed architecture of the technical infrastructure, design methods exist, but are not discussed in this article.

The importance of architecture of information systems

The introduction already mentioned that the topography dimension causes the complexity of the distributed system design: the location of the various components of the information system and their relations.

This dimension enlarges the contradictions between functional requirements (‘want’) on one side, and technical possibilities (‘can’) on the other side. These contradictions become clear in the criteria that are used to determine the correct place of the component of the information system in the technical infrastructure. The criteria can be divided in the following main groups:

· Location: who needs it, where is it located, who is the owner, ...

· Time: when, frequencies, response times, volumes, ...

· Quality: availability, manageability, reliability, ...

· Relation: what type of mutual interdependency, what type of functional relation, …

These criteria in itself are conflicting. Distribution criteria like ‘location’ are mainly functional criteria. The criteria ‘time’ and especially ‘quality’ and 'relation' are however severely depending on technical feasibility. One can imaging that a criterion like ‘time’ (e.g. response time) needs an entirely different distribution design than a criterion like ‘location’. Besides, a criterion like response time, where it is necessary to place a component on the user’s desktop, can contradict a quality criterion like manageability or security that force the designer to place the component on a central system (server).

Relation is a relative new criterion and is strongly related to interdependencies. If applications, processes or components have interdependencies and these applications, processes or components are located for example around the globe, it is very difficult for a system manager to control these components and to know the interdependency.

If one of these components fails, a global deadlock situation can occur which is difficult to detect and to manage.

Interdependency is one of the criteria for the distribution problem.

So the technical capability’s are a major factor in the distribution design, and therefore in the quality (feasibility and usability) of the information system. The determination of the location of the components of the information system consequently has to be considered much earlier in the development process than with centralised information systems. Architecture offers a good aid to handle, already in an early stage, the contradictions between the criteria location, time, quality and relation and with that fights the risk that later in the development process the design might not be feasible.

Besides the distribution design, there are other aspects with distributed systems where a complete structure in the form of an architecture design offers support:

· Increase of flexibility. Distributed systems have a higher penetration in the organisation and stand closer to the user. Due to the increasing pace of change in business this results in higher dynamics. The required flexibility to support these dynamics demands a well-considered architecture as foundation.

· Including the aspect management and security in the design. With distributed systems, the strategy for management and security has to be determined beforehand since these are a major factor in the design. Within the architecture design-process, the technical capabilities and consequences related to such aspects can also be considered.

· Heterogeneous environment. Distributed information systems imply often various processing environments (e.g. personal computers and midrange servers) with different quality requirements. This may mean for the development process that the information system has to be realised with multiple methods, techniques and tools. In that case, an early and durable partition of the information system is necessary to assign components to a distinct processing environment.

· Uncontrolled distribution of related components. The uncontrolled distribution of related applications, processes or components can create a deadlock situation, especially when these components or process are geographically located around the globe and the system managers do not have control over all the related servers and processes or components. The described situation is called 'Global Deadlock'. The global deadlock situation can easily occur today when using components like Javabeans and ActiveX controls, especially when we do not no their mutual relations and their geographic locations.

Methodology for architecture design

Now that the importance of a well-considered architecture for information systems had been discussed, the tension between the organisation architecture (‘requirements’) and the architecture of the technical infrastructure (‘capabilities’) can be further elaborated. The main aspect in a distributed information system architecture that has to be solved, is finding the most optimal location for the identified components of the information system from the angle of the business goals, needs, conditions and technical capability’s. The question remains: What are the properties of a method that can perform an architecture design of distributed information systems in an effective way?

An architecture design of a distributed information system can be characterised in the following way:

· Severely conflicting design criteria which makes it hard to find an optimal compromise;

· A large volume of design information that has to be dealt with;

· Various perspectives along which optimisations of the distribution can take place like functionality, systems management, security and performance;

· Relations with other system development activities where design information and consequences have to be exchanged continuously.

The architecture design of a distributed system, without structuring, quickly becomes an uncontrollable and

lengthy process where the quality of the result cannot be argumented. To handle the previously mentioned issues efficiently and effectively, a design process is needed that contains, besides the standard criteria for a solid system development method, the following properties:

· Multiple abstraction levels: Offers the ability, through step-by-step decomposition, to handle the large volume of design information to reduce the complexity of the decision process by splitting it up. For our purpose, we identify in the architecture process the following abstraction levels:

· Conceptual: On the conceptual level, all required design information is collected including important business conditions, strategies, targets, requirements and desires. Next, this information is modelled and structured to the topography as preparation for the logical level. ‘What’ is the main concern of this level.

· Logical: On the logical level an optimal design is made, based on the most important design principles, without having to take physical software or hardware limitations into consideration. Decomposition takes place so that the various information system components form distributable units. Next, a couple of scenarios are laboured based on functional and qualitative perspectives. For each scenario, the behaviour of the various system components in relation with each other are analysed and evaluated. ‘How’ is the main concern of this level?

· Physical: On the physical level, the final link is made with components from the technical infrastructure; hard- and software products, tools and utilities. Technology choices are made where multiple scenarios with different solutions can be chosen. One scenario is further elaborated and its behaviour is analysed and evaluated in relation with the available technology. ‘In what way’ is the main concern of this level.

· Scenarios: These serve for execution of ‘what-if’ analysis, through which different angles can be judged. 3 to 4 scenarios are chosen based on the most important design principles. As an example: a scenario starting from the qualitative requirement manageability, and a scenario starting from ‘performance’ requirements. The most optimal compromise can be selected from these scenarios.

· Iterations: Both within and between the different abstraction levels, iterations enable new views and the consequences of design decisions, made based on the scenario’s, to be processed.