Required and Optional Viewpoints – What Is Included in ... - CiteSeerX

Telecom Business Research Center Lappeenranta Working Papers 10

Kari Smolander, Kimmo Hoikka, Jari Isokallio, Mika Kataikko, Teemu Mäkelä, Heikki Kälviäinen

Required and Optional Viewpoints – What Is Included in Software Architecture?

Telecom Business Research Center Lappeenranta Lappeenranta University of Technology P.O.BOX 20, FIN-53851 LAPPEENRANTA, FINLAND http://www.lut.fi/TBRC Lappeenranta 2001

ISBN 951-764-575-9 (paper version) ISSN 1456-9132 ISBN 951-764-576-7 (URL: http://www.lut.fi/TBRC)

Required and Optional Viewpoints: What is Included in Software Architecture? Kari Smolander1, Kimmo Hoikka2, Jari Isokallio3, Mika Kataikko4, Teemu Mäkelä5, and Heikki Kälviäinen1 1

Lappeenranta University of Technology, Telecom Business Reseach Center (TBRC), Department of Information Technology, Laboratory of Information Processing, P.O. Box 20, FIN-53851 Lappeenranta, Finland, {kari.smolander|heikki.kalviainen}@lut.fi 2

3

Digital Information Architects Inc. Digia Oy., Laserkatu 6, FIN-53851 Lappeenranta, Finland, [email protected]

TietoEnator Corporation, Kumpulantie 11, FIN-00521 Helsinki, Finland, [email protected] 4

Sonera Corporation, Laserkatu 6, FIN-53851 Lappeenranta, Finland, [email protected] 5

Sonera Corporation, P.O.Box 145, FIN-00051 Sonera, Finland, [email protected]

Abstract Software architecture is conventionally concerned with the structures in a high abstraction level describing the main constituents of a software system. However, there seems to be no common agreement of what these structures exactly are. This paper acts as an attempt to define the viewpoints from which we see the structures. The rationale of having different viewpoints is reflected and a framework of the relationship between software architecture design and information systems development (ISD) methods is presented. The framework is based on the ideas found from method engineering and metamodelling. It is noted that the selection of viewpoints is contingent and based on the prevalent architectural practices in an organization and on the requirements from the project at hand. The paper includes a brief case study on the experiences from three different telecom-area software organizations that end up using different sets of viewpoints in their software process.

2

1

INTRODUCTION

One of the most used definitions for software architecture is the following: “The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them” (Bass et al. 1998, p. 23). The definition, however, leaves at least one big question to be answered: what are the relevant structures of a system? When making building architecture, there are several structures (like electrical wiring, plumbing, heating and air conditioning) and abstraction levels expressing different amount of details (like exterior view, interior view and floor plan). These structures are described separately but at least to some amount consistently because they are all mapped to the same constraining physical space. The different structures and abstraction levels are very standardized and based on long practice and experience. In software architecture, however, there seem to be no agreed set of structures and abstraction levels that are described when a system is being designed. This is actually admitted in the “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems” (IEEE 2000), which makes no commitments on what viewpoints or structures are relevant for software architecture. The question is important, however, because without an explicit definition on what viewpoints are relevant to software architecture, the whole meaning of software architecture stays ambiguous. In practice, this means that different people and different stakeholders participating in the software development process have different meaning for software architecture and therefore the communication and understanding between the participants becomes inefficient and in some cases even impossible. In this paper we seek ways to clarify the situation and to define the boundaries and the nature of software architecture and software architecture design. We approach software architecture in the context of information systems development (ISD) in contrast to the control and embedded systems that have dominated software architecture research and literature at least this far. We start from a short description of the rationale of why different viewpoints are needed and what can be found from the standards and literature (Chapter 2). We make a framework of the relationship between software architecture and

3 ISD methods and aim at clarifying the context of viewpoint selection (Chapter 3) and describing the effects of contingent viewpoints to ISD methods (Chapters 4 and 5). The framework is validated using examples of viewpoint selection from three telecom-area organizations (Chapter 6).

2

VIEWPOINT MODELS AND SOFTWARE ARCHITECTURE

By viewpoint model we mean a framework that defines the relevant aspects or concerns that must be taken care of when designing software architecture. Usually the viewpoint models include several viewpoints defining the concepts and models that can be used when dealing with the particular concern. These viewpoint models are either explicitly presented or implicitly included in a software process and method description. Explicit viewpoint models have appeared in standards (e.g. ISO 1996) and in literature (Kruchten 1995; Sowa and Zachman 1992; Soni et al. 1995) . An example of an implicit viewpoint model is, for example, the UML standard (OMG 2000) where no explicit viewpoint model is presented but where the viewpoint model can be inferred by analysing the available diagram types and modelling elements. 2.1

Why viewpoint models are needed?

We can observe and build software architectures from many points of view. To form an aggregate view on architecture, we must have either an implicit or an explicit framework that defines all the relevant aspects we need to consider. Based on our analysis, we can find several environmentally determined factors that affect on the selection of architectural viewpoints. These factors include at least the following: •

Different stakeholders and participants need different architectural viewpoints to enable communication and their own work – a marketing person needs a different architecture description than a programmer.

•

Different application areas have different quality requirements (like performance, reliability and maintainability, (cf. Bosch 2000) and therefore different aspects may be emphasized in the architecture design phase requiring different viewpoints.

4 •

Different technical development environments necessitate different architectural viewpoints (for example component-based development versus traditional compile and link development).

•

The practice in the division of work in an organization may affect on the required viewpoints. Different working units may take care of different viewpoints.

•

Development methods and process models are usually based on certain viewpoint model (like Rational Unified Process is based on 4+1 view model, Kruchten 1999; Kruchten 1995).

We can also point out practical reasons (related to the way of working) of using and selecting a viewpoint model for a software development organization: •

The need to manage complexity and organize system models according to the selected viewpoint model.

•

The need to organize and divide work according to the viewpoint model in large projects.

•

The need for guidance in the development process and modelling work. The viewpoint model may state the order of modelling – a certain viewpoint may have other viewpoints as its prerequisites.

2.2

Available viewpoint models

As the reasons for using a viewpoint model are numerous, there are also numerous viewpoint models available in standards and literature. The standards in this area seem to be at their early stage, but some models in the literature have gained popularity in practice. In the following, we shall summarize some of the available viewpoint models. IEEE standard 1471-2000 “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems” (IEEE 2000) claims to define the content of an architectural description, but actually, it stays on a very high abstraction level and takes no account on what really should be included in an architectural description. The real contribution of this standard is to admit that an architectural description includes several views conforming to defined viewpoints. The viewpoints cannot be standardized but they must be selected or defined according to the environment and the situation. The core of the standard is a conceptual model defining that an architectural description selects one or more viewpoints. The selection is based on the needs of the stakeholders. The

5 stakeholders have concerns (like performance, reliability, security, distribution, and evolvability) that determine their needs. The standard offers a general way to organize architectural descriptions and models to relevant viewpoints. However, it does not state anything about the contents of the viewpoints, nor define a concrete viewpoint model. Another standard in the area is the reference model of open distributed processing (RMODP), which is an ISO and ITU-T standard reference model for systems distribution, interoperability, portability, and integration (ISO 1996). The RM-ODP is developed to provide a coordinating framework to support open distributed processing and it identifies five viewpoints that separate concerns to separate models. The five viewpoints in RMODP are enterprise, information, computational, engineering and technology viewpoints. RM-ODP offers a way to organize the models according to the viewpoints and even defines some kind of a description language for each viewpoint. Other standard-like viewpoint models are included in US Department of Defence frameworks TAFIM (Defense Information Systems Agency 1996) and C4ISR (DoD Architectures Working Group 1997), but their scope is limited to military information systems. Also, UML (OMG 2000) has implicit assumptions on what are the relevant viewpoints in modelling. The 4+1 view (Kruchten 1995) is perhaps the best-known model defining architectural viewpoints. It specifies four viewpoints – logical, process, development, and physical viewpoint – accompanied with unifying scenarios. Although the terminology has changed, the basic model has been adopted, for example, in the UML user guide (Booch et al. 1999) and in the Rational Unified Process (Rational Software Corporation 2000). Another well-known viewpoint model is presented in Hofmeister & al. (1999; originally in Soni et al. 1995) where software architecture is constructed using four interacting viewpoints, conceptual, module, execution, and code architecture viewpoints. The Hofmeister & al. viewpoint model usage leads to a certain structure in the architectural model and it also guides the modelling process very explicitly emphasizing software production aspects. A different approach can be found from the Zachman framework. It has grown from the ideas in Zachman (1987), which were then extended in Sowa & Zachman (1992). The framework is a construction that tries to describe all the relevant aspects of information systems from an enterprise perspective. The framework has its roots in IBM’s

6

Target System perceives

Problem Context ?

Solution Context Architecture

ISD Group Requirements uses

defines a viewpoint on

represent Course - cou rseI d : int - cre ditUnits : int

application results in

Technique = Notation + Concept Structure



- desc riptio n : Stri ng

ResultSet

- cou rseNa me : Strin g + op enRe gistra tion( )

+ isLast ()

+ dele te( )

+ closeR egist ratio n()

+ up date ()

+ assig nLec tur er( )

+ inse rt( )

Statem ent (fro m jav a.sql)

+ dele te( )

-theR esultSet

+ up date ()

+ next ()

+ inse rt( )

+ close ()

-cur rentSt ate ment 1

-cur rent Object

+ exec uteQ uer y()

CourseRS

Connec tion

+ op en( )

ResultSetCo ntr oller

+ close ()

CourseA pp

+ getN ext( ) + op en( )

+ getC urr ent Object () + get Ope nCou rses( )

+ close ()

+ getAllCo urse s()

+ getC onn ection ()

Process

(fro m jav a.sql) -theC onne ction + close ()

+ initialize ()

+ close () + getN ext( ) + getC urr ent Object ()

Method

Databa seObj ect

(fro m jav a.sql)

+ close () + first ()

1

+ com mit( ) + cre ateSta tem ent ()

+ getC ours esInEv aluati on( )

+ pr epa reStat eme nt( )

+ dele teCa ncelledC our ses( )

+ rollb ack( )

+ getC ours eById ()

IS Specifications

Figure 1: Information systems development method information management culture as opposed to software engineering frameworks from Kruchten (1995) and Hofmeister & al. (1999). The Zachman framework organizes the system documentation very explicitly but its scope is quite broad and therefore it may lead to unnecessary complexity and tedious modelling efforts. Other frameworks, which have some properties of a viewpoint model, include for example ARES CFSA (Jazayeri et al. 2000), the list of useful software structures in Bass & al. (1998), and the viewpoints in the business component factory by Herzum & Sims (2000). Also, all systems development methods include at least implicitly a viewpoint model and the number of these methods can be counted at least in hundreds (Iivari et al. 1999).

3

SOFTWARE ARCHITECTURE IN INFORMATION SYSTEMS DEVELOPMENT

Before we can argue about the necessary viewpoints, we must define the place for software architecture in the context of information systems development. Information systems development can be described as a change process, which aims at changing the

7 target system1 according to some objectives (see Figure 1, Welke 1981; Lyytinen 1987; Smolander et al. 1991; Tolvanen 1998). The target system consists of the phenomena perceived by the ISD group and it identifies the target of change (Lyytinen 1987). The final aim of the development group is to implement the change in the user organization or community according to the objectives. This change usually includes composition and installation of formal artefacts (such as software and hardware) and changes in the rules and practices in the user organization or community. The whole process takes place in a set of environments, including organizational, technical, and social environments. The viewpoints in ISD are determined by the development method used. The development group carries out the change process, perceives and describes the phenomena in the target system using the description languages and conventions offered by the ISD method. The method includes a definition of the process and a set of techniques that define the notation and the concept structure to be used in the specification work. These notations may be formal, semiformal, or even informal and they express a viewpoint on the target system. In our work, we have divided the target system into the problem and solution contexts. Typically, information systems development starts from the problem context. We might talk about user needs, business requirements, use cases, functional requirements, etc. When doing so we are approaching the system in terms of a problem and the primary need for an ISD group is to understand the problem. On the other hand, we might see the system as a set of technical constructs, formal rules, organizational principles, procedures, algorithms, data structures, data communication patterns, and so on. We then see the system as a solution to the problem and the main constituents of the system are then the constructs and the structure in the solution context. The primary objective for an ISD group in the solution context is to find out a viable structure for the solution (cf. Jackson 1994). Software architecture guides the ISD group by offering possibilities and setting constraints on how the problem context may be perceived when stating the requirements according to the objectives. Architecture forms the visible part of the solution context when perceiving the problem context. On the other hand, the requirements model

1

We use here the term “target system” instead of “object system” in (Welke 1981) and (Lyytinen 1987) to avoid confusion with the particular meanings of “object” in software engineering and programming.

8

Abstract

Problem context

Requirements analysis model

defines

Business requires

imposes requirements on

Solution context

Concrete

offers possibilities, sets constraints on

Software Architecture Design Software Architecture Description

prescribes

offers business services and opportunities

Software architecture implementation

is described by Software architecture

Figure 2: Abstract and concrete in software architecture naturally determines the software architecture by imposing requirements on the architecture. We can say that requirements and architecture approach the development from the opposite directions and hopefully meet at some point. We have discovered similar thoughts in Nuseibeh’s Twin Peaks model (Nuseibeh 2001), which emphasizes the interaction between requirements and architecture. We see software architecture as a part of the solution, which needs to be prescribed and described. Our framework in Figure 2 distinguishes between abstract and concrete. By concrete we mean something in the world that can be observed directly (i.e. not from a model), like a software architecture implementation running in a certain hardware instance, or a business process going on in a company. Abstract means here something that is an abstraction of an ultimately concrete thing for prescription or description purposes. A requirements analysis model is an abstraction of the concrete business needs and a software architecture design model is an abstraction and a prescription of a forthcoming software architecture implementation. A software architecture description is also an abstraction that describes a software architecture implementation. Software architecture is composed of both its abstract and concrete counterparts residing in the solution context. We need both counterparts because all the properties of software

9 architecture, like logical subsystems or the high level architectural decomposition, cannot be directly observed. They are merely abstractions that cannot be extracted from the running system. Business requires certain functionality from the architecture implementation, which then offers business services and opportunities for new business. Figure 2 can also be read as a cycle starting from the business defining new requirements to be implemented. The requirements are then designed to software architecture that is then implemented. The implemented architecture then offers the needed business services and in some cases new business opportunities. This kind of connection can be observed, for example, in electronic commerce, which requires the implementation of a certain kind of architecture with distribution and integration characteristics. On the other hand, the existence of this kind of architecture also facilitates the company in expanding its business to new areas. We can approach the architectural viewpoints by defining the target of the viewpoint. Many of the architectural viewpoints are concerned about the concrete solution, i.e. the software architecture implementation. Such viewpoints are, for example, hardware topologies and concurrent processes. Some of the so-called logical architectures are on the other hand describing the abstract solution. We may also have a model on the functional requirements or business processes, but it is questionable if these models belong to software architecture.

4

RELATIONSHIP BETWEEN METHODS AND ARCHITECTURE

We defined above software architecture as a part of the solution and divided it into abstract and concrete counterparts. Also, we noted that the development group uses a method, which defines the viewpoints. The relationship leads us to look closer on ISD methods and viewpoints. In the following, we will investigate the meta-structures of methods and architectures and find out that they have considerable similarities. An ISD method defines at least the conceptual structure and the notation or the language that is used when making IS specifications. It may also include more vague properties like the definition of the development process, participation and roles, development objectives and decisions, and values and assumptions (Tolvanen 1998). A common way

10 to specify a method is to model its conceptual structure as a metamodel, which is a higher-level abstraction of the method (cf. Smolander et al. 1991). A well-known example of metamodelling is the UML metamodel (OMG 2000). The relationship between a metamodel and a model is analogous to the relationship between information schema and information. Figure 3 shows the three meta-levels and an example of their population. A metamodel defines the modelling language, which is used in modelling i.e. representing the target. UML standardization, which is taken here as an example, has used metamodelling extensively. The UML metamodel describes the constructs that are used in the system specification. Then, an information system is implemented according to the specification, which represents the target. Metamodel

Example: the UML metamodel

defines the modelling language

Example: a system specification modelled using the UML

Model represents

Target

Example: an information system

Figure 3: Metalevels We can observe that software architecture has a similar meta-abstraction than in metamodelling. This is represented in Figure 4 where the top level is called metaarchitecture (cf. HP 2001). Meta-architecture2 resembles architectural style, which according to Monroe & al. (1997, p. 45) “characterizes a family of systems that are related by shared structural and semantic properties”. Similarly, we could define a metamodel as a definition of a family of models that are related by structural and semantic properties. Also, Monroe & al. (1997) list four things that styles typically provide: a vocabulary of design elements, design rules that determine which compositions are permitted, semantic interpretations of the design elements, and analyses that can be performed on systems built in that style. This definition comes also very close to the concept of a metamodel. 2

By meta-architecture we do not refer to the run-time reflection techniques found in many object-oriented programming languages.

11

Meta-architecture

Example: the three-tier model

defines the ”building block” types

Software architecture design/description

Example: an architecture design conforming to the three-tier model

represents

Software architecture implementation

Example: an architecture implemented according to the design

Figure 4: Levels in software architecture Meta-architecture defines the concepts and the language that is used when designing and describing software architecture and guides the architects in the architecture specification work. For example, meta-architecture may consist of: •

The building block types of which architecture is composed. Examples of these building block types are pipes and filters, or the tiers in the three-tier model.

•

The rules that specify how these building blocks may interact together. These rules may be specified, for example, in the form of patterns. These rules may include, for example, the interaction with databases, or patterns related to security, such as authentication and authorization routines.

•

The definition of architectural viewpoints (cf. 4+1 view) describing the relevant structures for an architect. This includes also the description techniques for each viewpoint, for example, the defined modelling conventions and stereotypes for the different viewpoints when using the UML.

•

The technological context in which architecture is designed, including reference architectures, component architectures, COTS products, and other relevant systems and products.

•

The organizational context, which includes, for example, participation and role patterns, competitors, partners, suppliers, business values, assumptions, and experiences from the history.

It is possible to combine these two level-models as one model. Figure 5 defines that meta-architecture should be included in the ISD method definition when engineering methods for use in an organization. A software architecture implementation is a part of an information system and a software architecture design/description is unquestionable a part of an IS specification. We can go further this line of thought and argue that meta-

12 architecture is also a part of an ISD method definition, which defines both the modelling language and the building block types. The ISD method is not complete without the definition of meta-architecture. Some parts of the method are architecture-independent, but some other parts must be adapted to the meta-architecture.

Meta-architecture

ISD Method Definition

Metamodel

defines the modelling language with ”building block” types

Software architecture IS Specification Design/Description

Model

represents

Software architecture implementation

Information System

Target

Figure 5: The combined model The consequence of this argument is that no method or description language (like UML) is usable as-is. Changes in meta-architecture define different types of building blocks and viewpoints and therefore some form of method engineering (cf. Kumar and Welke 1992) is needed in adapting the method and the meta-architecture together. Building block types are contingent and depend on the meta-architecture. Also the selection of architectural viewpoints (as in IEEE Std 1471-2000) changes the meta-architecture as a part of the ISD method definition.

5

VIEWPOINTS AS AGREEMENTS

In the Figure 2 we drew two axes that were abstract/concrete and problem/solution and noted that architecture resides in the solution context having both abstract and concrete counterparts. We know the concrete existence of the physical world, but when striving to implement an information system, the modelling path from requirements to the physical implementation is based on agreements between the participating people. We see the role of software architecture as a mediator between what we really know (the concrete world) and what we must agree on (the abstract world). The concrete world can be

13 observed and its entities can be identified but abstractions are agreements between people. They aim at communication and understanding, and, in the design, eventually at composition and generation of physical artefacts. When selecting the architectural viewpoints, we can extract some concrete structures from the “real” world that we feel intuitively relevant. These include, for example, the hardware topology, concurrent processes, source code structure, data storage structure, and the relationships between binary components and executables. We must however note that even when we can extract the entities from the concrete world, we must make an agreement on how they should be modelled. A model of the concrete world is an abstraction and therefore it is another agreement to make between people. Architecture is not only concrete. It also consists of abstractions or conceptual structures, which are based on agreements specifying the concepts and the language for presenting the selected viewpoint. For example, the abstract viewpoint in a software architecture description, which is typically based on a component-connector structure, is an agreement concerning at least the selection of the component and connector types, their allowed relationships, and the notations associated to the types. The consequence of seeing viewpoints as agreements between people is that we cannot say any set of viewpoints as being better than another. Instead, we must fit the set of viewpoints to the characteristics of the environment where the software architect works. This implies that we define the meta-architecture according to the characteristics of the target system and the working environment. In defining the meta-architecture, we must take several factors into an account, including: •

The systems development method in use, which defines most of the viewpoints. Some of these viewpoints may be considered as necessary and some optional.

•

The application domain defining some extra viewpoints. For example, in some domains, security may require a certain method to be used and therefore a specific architectural viewpoint to be described, and in some others, performance aspects may need extra attention. Also, the building block types may change according to the application domain. If we can agree that the system will mostly be composed of UI forms and database entities organized in subsystems then it can be easiest to make the modelling using these concepts directly.

14 •

Technical environments that determine some of the viewpoints. For example, component architectures (CORBA, COM, EJB) have defined sets of concepts and terminology leading to the usage of certain viewpoints and certain kind of models like a description of EJB entity and session objects and their dependencies.

•

Work organization and division. For example, if reusability of software components is recognized as an important objective in a software producing organization, attention must be paid on defining the relevant viewpoints enabling reuse. We see here reusability more as an organizational and cultural issue than a technical one.

•

The business area of the organization. For example, if the business is to run software services, it requires detailed descriptions of the production organization and production architecture. Also, if the expected lifetime of a product is very short (e.g. less than 2 years), it affects on the amount of effort put on architecture design and therefore on the selection of the viewpoints, too.

•

The skills and experiences of the ISD group constraining or enabling the selection of viewpoints.

The definition of the meta-architecture is an organizational process, where some parts (and also some viewpoints) are specific to a development project, but where most parts can be applied to the whole organization. We cannot objectively agree on the best possible set of viewpoints. Instead the process and its decisions will be at least partly based on organizational values, assumptions, and experiences. The fitting of metaarchitecture is actually a form of method engineering and some lessons can be learned from that field.

6

SELECTED VIEWPOINTS IN SOME TELECOM SOFTWARE ORGANIZATIONS

In the following, we shall look on a case study of three different software-producing organizations and draw conclusions on their usage and conception of architectural viewpoints. The objective of the study was to clarify and interpret (cf. Klein and Myers 1999) how the conceptions of architects about architectural viewpoints differ and what might be the reasons for the differences. This study serves as a starting point for a more

15 thorough qualitative research concerning tool and method usage rationale in software architecture design. The motivation of the study is to provide insight and preunderstanding about the subject so that further research design is possible. An exploratory research approach is required for a relatively unexplored research area like this. The study started with a general investigation on architectural practices in the three telecom-area software organizations participating in the Com2Bus research project. The lead author conducted interviews and discussions with a questionnaire containing general open-ended questions to four head architects (the co-writers of this paper) in these organizations. The questionnaires were sent to the architects beforehand and the representative architects prepared a presentation about their architectural practices from their point of view. The questionnaires and presentations were processed in two intensive one-day workshops with all representatives from the three companies present. The purpose of these questionnaires and workshops was to achieve background information and understanding about the situation, and to serve as the basis for interpretations. After these workshops, the lead author made a short report on the current architectural practices in the companies and the report was then discussed in another one-day workshop. The actual lists of the architectural viewpoints were made directly by the architects working in these organizations. They collected experiences from available projects and identified the explicit and implicit viewpoints that were typically used in the architecture development. The architects used also introspection and their own experiences in determining the actual and needed viewpoints. After resolving the lists of viewpoints, the lead author participated in analysing and interpreting the rationale for the viewpoint selection. The possible reasons for the viewpoint selection were analysed based on the information from the previous workshops. It must be noted here that the observations below will reflect at least as much the differences between the conceptions of architects as they reflect the differences in architectural practices. This research, however, makes no distinction between conceptions and actual practices, which is a subject of another study.

16 6.1

Case 1: a systems integrator

Short description The first case is an organisation working as an IT solution provider for telecom operators and manufacturers. The organisation has a wide range of customer-oriented services and it works as a systems integrator delivering tailored applications and systems to the customers. Typically, the delivered systems are integrated into customer’s existing infrastructure and legacy systems. Used viewpoints The architecture descriptions in Case 1 usually contain views conforming to the following viewpoints: •

Logical viewpoint, which defines the subsystems and their responsibilities, interdependencies, and interfaces.

•

Physical viewpoint, which describes the hardware topology.

•

Process viewpoint, describing the concurrent processes and their responsibilities, communication between processes, and process distribution.

•

Technical viewpoint, which is ambiguously either an extension of the logical viewpoint with product specific information or very close to the physical viewpoint. The technical viewpoint shows the software components, their detailed interfaces and their placement to the physical topology. This viewpoint may also include product specific information, layering, used libraries, and third party components.

All projects in Case 1 do not use the viewpoints similarly. Some viewpoints are used more than the others. The most often used viewpoints are the logical and the technical viewpoint, whereas the process viewpoint is used only in some occasions. Rationale for the viewpoint selection The viewpoint model in Case 1 is a very generic one. A possible explanation to this can be found from the type of organization’s business and the systems that the organization is building. A systems integrator must adapt to changing environments and infrastructure with flexibility. This need for flexibility is reflected in the software process and it was

17 observed that the process model in use determined the viewpoints to a great extent. Other mentioned reasons for selecting the viewpoints in Case 1 were: •

Avoiding unnecessary description – only those viewpoints are used which were seen important in the situation. All projects do not use all the viewpoints listed above.

•

Expected lifetime of the systems – the systems with long lifetime expectancy were described with more viewpoints than those systems with a short one (e.g. web services with hard time-to-market requirements).

•

Quality requirements may require, for example, the description from the process viewpoint.

•

Communication between different people working in different phases in the development project.

6.2

Case 2: a mobile software company

Short description Case 2 is specialized in making application software for mobile terminals (like mobile phones) and especially for the EPOC platform. The business is very focused on the mobile software and the organization often acts as an OEM partner or subcontractor for telecom operators and companies. The organization is relatively young and its software development processes are developing rapidly. Used viewpoints The identified architectural viewpoints in Case 2 are: •

Static structure viewpoint, which includes components, their dependencies and interfaces, and used resources and system services. Also the analysis model with use-case relationships is considered as a part of the static structure viewpoint.

•

Information viewpoint, including users/actors, data structures, databases, files, and persistency aspects.

•

Dynamic structure viewpoint, describing information flows, instantiation and resources, threads and processes, and data communications.

18 •

Business viewpoint, which describes aspects like cost efficiency, development speed, strategic partnerships, subcontractors, needed COTS components, intellectual property rights and patents. The business and product management especially need this viewpoint.

•

Engineering viewpoint, describing aspects like quality, complexity, reusability, repeatability, and used tools and methods.

•

Technology viewpoint, which describes, for example, competence aspects, product life cycle and lifetime estimate, technology complexity and stability, the relationships between the licensor and licensees, standards and regulations, RAM/ROM budget and measurements.

Rationale for the viewpoint selection The set of viewpoints is very different from the generic one in Case 1. This is because the development platform (EPOC) and mobile networks bring certain requirements to the viewpoints. For example, the technology viewpoint becomes important because the mobile world brings in mobile standards and regulations and a limited amount of memory in the devices. Also, the product lifecycle and lifetime is often short because of the rapidly changing technology. The rapidly changing mobile business affects on the viewpoint selection too. The business viewpoint is needed because of the complex strategic and legal issues that the organization is constantly facing. The business must be explicitly analysed when developing software in this case. 6.3

Case 3: a telecom service provider

Short description The third case is an internal development organization of an international telecom service provider. The organization is specialized in producing services for mobile telecommunications, and indirectly, producing platforms supporting the services. The development work is strongly project based, with only few product-like releases. The lifetime estimate of telecom services is only some years, due to the rapid development both in technology and in the end-user base.

19 Used viewpoints The viewpoint model applied in the case organization can be divided into two segments (Figure 6): the system and extra-system viewpoints. In addition, there are viewpoints for arguing about miscellaneous concerns, not pertaining with same weight to every project, such as security, capacity, and usability.

Enterprise

System Design Element * consists-of

Logical

Development

Development Organization

Scenarios 1-*

Processes

Physical

Production

Figure 6: Viewpoint Model in Case 3 The systems engineering is organized hierarchically into design elements, which can be recursively developed (much like in Bachmann et al. 2000). Each design element is described by five viewpoints as in 4+1 model (Kruchten 1995). The design elements fall to different abstraction levels, starting from the whole system with increasingly narrow focus, ending to module-level design elements, that can be directly implemented in the target language. The enterprise viewpoint is concerned about the context in which the system is to operate. It focuses on the customer and production organizations, their policies and earning logic, and the expected purpose of the system. The purpose is typically depicted as a service concept, and in more detail, as scenarios, requirements, and constraints. The development organization viewpoint views the system in terms of the applied resources, process, and project models, and in terms of how the system relates to product lines and the organizational memory and reuse. Finally, the production covers the technical issues of the system’s life cycle after the release. Concerns range from maintenance and extensibility to day-to-day operations. The projects have very little authority on selecting the viewpoints to apply, excluding the supplementary viewpoints. Nevertheless, the emphasis they give to particular viewpoints

20 varies, so that some viewpoints are described only briefly, whereas some are described more completely. Rationale for the viewpoint selection The construction of the viewpoint model in Case 3 has been an organizational learning process, at the time guided by a “what feels good” attitude, rather than clear rationale. Now, after the fact, it is possible to identify some factors that have shaped the work. Firstly, the organization is fairly young and in the process of finding its place among the company’s other development organizations. Many of these are oriented on specific products and relate directly to a certain business. The overall strategy in the case organization has been to emphasize its role as an in-house software developer. This shows in the inclusive and detailed approach of the viewpoint model. Another cause for a comprehensive viewpoint model is the high degree of integration among systems and services. Managing it requires careful planning. Furthermore, the structure-oriented decomposition is well suited to project management’s concerns and work breakdown structures. The organizational structure and the telecom service domain are directly portrayed in the extra-system viewpoints. The enterprise viewpoint aims to describe the relevant aspects of the system’s context, so that the development group has enough knowledge to solve the right problem. Especially the service concept and earning logic models are described in detail to help this analysis. The systems are mostly operating on the server-side and therefore the production organization becomes also a principal stakeholder. If their concerns are not answered, the system can hardly get any acceptance. Lastly, the primary interest of the customers of Case 3 is only in getting a proper software solution to their needs, not in reflecting how their needs relate to other solutions developed. Without any pro-active work, this easily leads to incompatible, one-time systems that are always built from scratch. However, there are often similarities between the solutions. For example, solutions targeted at the same problem context share many features. It is therefore the responsibility of the organization to transparently manage the reuse. By forcing all projects to consider the systems as a hierarchy of design elements, which are then described in detail, reuse of design elements becomes possible. An explicit mapping of the design elements to the development organization viewpoint as product lines and other reusable assets makes reuse more probable. Explicit design

21 elements also help in identifying commonalities and variance between projects. This knowledge is needed to support the service platform development, which is essential in this case. 6.4

Summary of the cases

The three cases show differences but also similarities. In the heart of their viewpoint models are some kind of a component-connector model or a static structure model with components, subsystems, and like. In particular, Case 1 and Case 3 have taken clear influences from the 4+1 model, however, with modifications and additions. The meta-architecture including aspects concerning the business, technology, and organization explains largely the viewpoint model qualities. Based on the three cases, it seems that especially the ways of doing business affects on the selection and forming of the viewpoint model. For example, Case 1 as a systems integrator produces diverse applications with diverse technologies and infrastructure and therefore the viewpoint model is very generic and lacks specialized viewpoints. The viewpoints included in the viewpoint model must be applicable to a major part of the projects and therefore more specialized viewpoints are not included in the process definition. On the other hand, Case 2 focuses on certain technologies and its business is very specialized, which leads to a more detailed viewpoint model. System characteristics are not varying so much as in Case 1 and therefore more specialized viewpoints can be used commonly. Also, Case 3 as an internal development organization of a telecom service provider whose business is largely based on software services is in a different situation. To keep track of the business it needs to be explicit in business viewpoints also when dealing with architecture. Also the run-time architecture and the production organization become important when building server-side telecom services. The mentioned factors affecting on the selection of architectural viewpoint included both technical aspects (like quality requirements) and non-technical aspects (like communication needs or the organization of the software production). It seems that the importance of non-technical aspects is higher than the importance of the technical aspects, but we cannot make any definite arguments based on this study. We feel that more research must be made before making any further arguments of the factors, their interrelationships, and their relative importance. However, this study serves as a good starting point for further and more thorough research where the focus is, for example, in

22 finding out the relative importance and relationships between the affecting factors, or determining the explicit rationale for architectural descriptions and communication involved in architecture design in practice. A suitable method for such research is, for example, the discovery of grounded theory (Glaser and Strauss 1967; an example of usage in Calloway and Ariav 1991), which uses qualitative content analysis when constructing a theory on the phenomenon under study. This study provides the necessary pre-understanding for the research design and for the initial interpretation and analysis of the research data.

7

SUMMARY

In the beginning we asked, what are the relevant structures of a system and made a comparison with building architecture, where the structures are well defined. We, however, came to a conclusion that the viewpoints as specified in IEEE 1471 are actually agreements between people depending largely on the organizational and project environment. We reflected on the rationale of having different viewpoints and presented a new framework of the relationship between software architecture design and ISD methods. The framework is based on the meta-level hierarchy that can be found, for example, from method engineering. The selection of architectural viewpoints is contingent and based on the prevalent meta-architecture in an organization and in the project at hand. The paper included experiences from three different telecom-area software organizations that ended up using different sets of viewpoints in their software process. Especially the way of doing business in the organization affected on the needed viewpoints to a great extent. All three cases had different viewpoint models with much in common but also with much difference. All viewpoint models contained some form of a componentconnector model but the other viewpoints varied much according to the metaarchitecture. We found that the context for the viewpoint definition is in practice larger than the usual software engineering context (Kruchten 1995; Hofmeister et al. 1999). Also the technological, competitive, and resource environment must be taken into an account when selecting viewpoints. By doing so we achieve a holistic view to the contingent architectural viewpoints in information systems development.

23 In the future, the case study must be continued and extended to include deeper analysis about the factors affecting on the viewpoint formation and selection. Also, we need to know empirically what are the practical rationales of architectural descriptions and how viewpoints relate to them. Another interesting research topic would be how architect’s conceptions and interpretations about architecture and architecture design differ from the conceptions and interpretations of other stakeholders (cf. Orlikowski and Gash 1994).

ACKNOWLEDGEMENTS This work is a part of the Com2Bus project (Component Based Software Architecture in Global Telecom Service Business) formed by Sonera Corporation, TietoEnator Corporation, Digia Inc., and Lappeenranta University of Technology. We wish to thank professors Anne Eerola (University of Kuopio) and Matti Rossi (Helsinki School of Economics and Business Administration) for their valuable comments.

REFERENCES Bachmann, F., L. Bass, G. Chastek, P. Donohoe and F. Peruzzi (2000). The Architecture Based Design Method, Software Engineering Institute, CMU/SEI-2000TR-001. Bass, L., P. Clements and R. Kazman (1998). Software Architecture in Practice, Addison-Wesley. Booch, G., J. Rumbaugh and I. Jacobson (1999). The Unified Modeling Language User Guide, Addison-Wesley. Bosch, J. (2000). Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach, Addison-Wesley. Calloway, L. J. and G. Ariav (1991). "Developing and Using a Qualitative Method to Study Relationships among Designers and Tools". Information Systems Research: Contemporary Approaches and Emergent Traditions. H. E. Nissen, H. K. Klein and R. Hirschheim, North-Holland: 175-193. Defense Information Systems Agency (1996). Department of Defence Technical Architecture Framework for Information Management. http://wwwlibrary.itsi.disa.mil/tafim/tafim3.0/pages/acro.htm, accessed 10.4.2001. DoD Architectures Working Group (1997). C4ISR Architecture Framework, Version 2.0. http://www.fas.org/irp/program/core/fw.pdf, accessed 10.4.2001.

24 Glaser, B. and A. L. Strauss (1967). The Discovery of Grounded Theory: Strategies for Qualitative Research. Chigago, Aldine. Herzum, P. and O. Sims (2000). Business Component Factory - A Comprehensive Overview of Component-Based Development for the Enterprise, John Wiley & Sons. Hofmeister, C., R. Nord and D. Soni (1999). Applied Software Architecture, AddisonWesley. HP (2001). Meta-Architecture. http://www.architecture.external.hp.com/Overview/arch_meta_architecture.htm, accessed 21.5.2001. IEEE (2000). IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems, IEEE, IEEE Std 1471-2000. Iivari, J., R. Hirschheim and H. K. Klein (1999). "Beyond Methodologies: Keeping up with Information Systems Development Approaches through Dynamic Classification", Proceedings of the 32nd Hawaii International Conference on System Sciences. ISO (1996). ISO/IEC 10746 Reference Model of Open Distributed Processing, ISO. Jackson, M. (1994). "Problems, Methods and Specialization". IEEE Software 11(6): 5762. Jazayeri, M., A. Ran and F. Linden (2000). Software Architecture for Product Families: Principles and Practice, Addison-Wesley. Klein, H. K. and M. D. Myers (1999). "A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems". MIS Quarterly 23(1): 67-94. Kruchten, P. B. (1995). "The 4+1 View Model of Architecture". IEEE Software 12(6): 42-50. Kruchten, P. B. (1999). Rational Unified Process: An Introduction, Addison-Wesley. Kumar, K. and R. Welke (1992). "Methodology engineering: a proposal for situationspecific methodology construction". Challenges and Strategies for Research in Systems Development. W. W. Cotterman and J. A. Senn, John Wiley & Sons: 257-269. Lyytinen, K. (1987). "A Taxonomic Perspective of Information Systems Development: Theoretical Constructs and Recommendations". Critical Issues in Information Systems Research. R. J. Boland, Jr. and R. A. Hirschheim, John Wiley & Sons: 3-41. Monroe, R. T., A. Kompanek, R. Melton and D. Garlan (1997). "Architectural Styles, Design Patterns, and Objects". IEEE Software 14(1): 43-52. Nuseibeh, B. (2001). "Weaving Together Requirements and Architectures". IEEE Computer 34(3): 115-117.

25 OMG (2000). OMG Unified Modeling Language Specification, Version 1.3, Object Management Group. Orlikowski, W. J. and D. C. Gash (1994). "Technological Frames: Making Sense of Information Technology in Organizations". ACM Transactions on Information Systems 12(2): 174-207. Rational Software Corporation (2000). Rational Unified Process. Online documentation. Smolander, K., K. Lyytinen, V.-P. Tahvanainen and P. Marttiin (1991). "MetaEdit-A Flexible Graphical Environment for Methodology Modelling". Advanced Information Systems Engineering, Proceedings of the Third International Conference CAiSE'91. R. Andersen, J. A. Bubenko jr. and A. Solvberg. Berlin, Springer-Verlag: 168-193. Soni, D., R. L. Nord and C. Hofmeister (1995). "Software Architecture in Industrial Application", Proceedings of the 17th International Conference on Software Engineering, April 24-28, 1995, Seattle, WA USA, ACM press, 196-207. Sowa, J. F. and J. A. Zachman (1992). "Extending and Formalizing the Framework for Information Systems Architecture". IBM Systems Journal 31(3): 590-616. Tolvanen, J.-P. (1998). Incremental Method Engineering with Modeling Tools. Jyväskylä Studies in Computer Science, Economics and Statistics 47, University of Jyväskylä. PhD Dissertation. Welke, R. J. (1981). IS/DSS: DBMS Support for Information Systems Development. Hamilton, McMaster University. Zachman, J. A. (1987). "A Framework for Information Systems Architecture". IBM Systems Journal 26(3).

PUBLICATIONS OF TELECOM BUSINESS RESEARCH CENTER (TBRC)

Research Reports

1. A State-of-the-Practice Survey on Requirements Engineering in Small- and Medium Sized Enterprises. Nikula, Uolevi; Kälviäinen, Heikki; Sajaniemi, Jorma, 2000 2. Imatran

seudun

IT-alan

yritysten

verkostoitumisen

resurssi-

ja

ydinosaamispohjainen tarkastelu. Ahola, Jyrki; Blomqvist, Kirsimarja; Tuimala, Aija; Salmi, Pekka, 2000 3. Tietoliikennetoimialan

PK-lisäarvopalvelutuottajat

Suomessa

–

Tutkimusraportti. Puumalainen, Kaisu; Varis, Jari; Saarenketo, Sami; Niiranen, Jukka; Blomqvist, Kirsimarja; Kuivalainen, Olli; Kyläheiko, Kalevi; Porras, Jari; Virolainen, Veli-Matti; Äijö, Toivo; Savolainen, Petri, 2000 4. Elicitation of Customer Requirements with Group Methods in Software Engineering. Reinikainen, Lea, 2001 5. Requirements Elicitation Using a Combination of Prototypes and Scenarios. Mannio, Markus; Nikula, Uolevi, 2001

Working Papers

WP1: International Strategies of Telecommunications Operations. Äijö, Toivo, 1999 WP2: Analyzing Core Competence and Value Add of Small Software Firms in Telecommunications. Torkkeli, Marko; Virolainen, Veli-Matti; Niiranen, Jukka; Tuominen, Markku, 1999 WP3: Asymmetric Partnerships – Different Characteristics and Motivation of Small and Large Technology Firms. Blomqvist, Kirsimarja, 1999 WP4: Networking as a local development strategy: Leadership in Network Organizations. Ahola, Jyrki; Tuimala, Aija, 2000 WP5: Application Visions and Business Opportunities of Bluetooth - A Wireless Technology for Local Data Transfer. Sainio, Liisa-Maija; Niiranen, Jukka; Sikiö, Taina, 2000

WP6: The Possibilities of IP Networks in Strategic Partnership Development. Puska, Tiina, 2000 WP7: Industrial Districts and Regional Development: Towards a Knowledge-Based View. Blomqvist, Kirsimarja; Ahola, Jyrki; Kyläheiko, Kalevi; Salmi, Pekka, 2001 WP8: Immateriaalioikeuden lähtökohtia. Hurmelinna; Pia, 2001. WP9: Sähköisen

liiketoiminnan

liiketoimintamallien

patentointi

Euroopassa.

Karkulahti, Miikka, 2001 WP10: Required and Optional Viewpoints: What is Included in Software Architecture? Smolander, Kari; Hoikka, Kimmo; Isokallio, Jari; Kataikko, Mika; Mäkelä, Teemu; Kälviäinen, Heikki, 2001