Patricia Lago, Hans van Vliet. Vrije Universiteit Amsterdam, The Netherlands. {Patricia, Hans}@cs.vu.nl. Abstract. Modern software development increasingly ...
A Grid for Architectural Knowledge: Issues in Getting Global Patricia Lago, Hans van Vliet Vrije Universiteit Amsterdam, The Netherlands {Patricia, Hans}@cs.vu.nl
Abstract. Modern software development increasingly often takes place in a geographically distributed context involving multiple development groups with different backgrounds and roles. Part or most of software systems is provided through COTS components, outsourcing, open-source, multi-party collaboration and distributed development teams. The software architecture plays an increasingly important role to manage the complex interactions and dependencies and to provide a central artifact that can be used for reference by the stakeholders. Existing notational and documentation approaches to software architecture typically focus on the components and connectors and fail to document the design decisions that resulted in the architecture as well as the organizational, process and business rationale underlying the design decisions. This results in high maintenance cost, high degrees of design erosion and lack of information and documentation of relevant architectural knowledge. This paper advocates the use of architecture as communication base in global development, and discusses a list of problems and possible solutions aimed at building a grid for global architectural knowledge.
Introduction The notion of software architecture is one of the key technical advances to the field of software engineering over the last decade. The advantages of using explicit software architecture include early interaction with stakeholders, its basis for a work breakdown structure and the early assessment of quality attributes [1]. Although considerable progress has been made, we lack techniques for capturing, representing and maintaining knowledge about software architectures. In this context, architectural knowledge (AK) is the integrated representation of the software architecture of a software-intensive system (or a family of systems), the architectural design decisions, and the external context/environment. While much attention has been given to technical architecture, non-technical knowledge remains implicit and is often left to interpersonal, informal communication. The incomplete representation of the needed AK leads to several problems that are generally recognized in any software engineering project, and that become just worse in global software development (GSD): • Lack of first-class representation: Architectural solutions, design decisions and rationale, lack a first class representation in the software architecture. Consequently, the knowledge about the “what and how” of the software architecture is quickly lost. Some architecture design methods stress the importance of documenting architecture design decisions, but experience shows that this documentation often is difficult to interpret and use by individuals not involved in the initial design of the system. • Architectural knowledge is cross-cutting and intertwined: AK addresses technical, business, organizational, and cultural aspects that influence architectural decisions and design solutions. Due to its inter-disciplinary nature, AK is often cross-cutting, affecting multiple components and connectors in a software architecture, and one piece of AK often becomes intimately intertwined with another piece of AK. • High cost of change: A resulting problem is that software architecture, once implemented, is, sometimes prohibitively, expensive to change. Due to the lack of first-class representation and the intertwining of different types of AK, changing or removing existing design decisions is very difficult.
• •
•
•
Design rules, constraints and rationale violated: During the evolution of software systems, designers, and even architects, may easily violate the design rules, constraints and rationale imposed on the architecture during earlier design iterations. Obsolete design decisions not removed: Removing obsolete architecture design decisions from an implemented architecture is typically avoided, or performed only partially, because of the (1) effort required, (2) perceived lack of benefit and (3) concerns about the consequences, due to the lack of knowledge about them. The consequence is a rapid erosion of the software system, resulting in high maintenance cost. Architectural knowledge is dispersed and undocumented: Documented or formalized AK is usually limited to technical architectural solutions. Non-technical knowledge such as business and cultural issues remains tacit and individual know-how of those who participate in the software development. This AK is then lost, and difficult (if not impossible) and very expensive to trace back and reuse in later developments. Documented architectural knowledge neglects interdisciplinary use: AK documentation should convey the overall architecture to persons with different culture, skills and responsibilities in different architectural aspects or subsystems. Persons working at the subsystem level easily lose track of relations between their “part” and the overall architecture. This hampers traceability and may lead to changes that conflict with the general architectural decisions, which instead should orchestrate the differences in the involved parties.
When software engineering projects get global, the problems above are aggravated. Knowledge transfer is a communication process needing strict interaction, and agile information exchange. In local software development it is already difficult to rationalize the type and amount of knowledge we need to exchange. If in addition exchanges occur remotely and via a technological infrastructure, we have to make this knowledge explicit, and we need to identify agile solutions to render this process as dynamic and powerful as posssible. From Tacit Knowledge to Formalized Knowledge In most literature, e.g., [5], knowledge is classified into tacit, documented and formalized knowledge. Tacit knowledge is implicitly known and used by software architects but not made explicit. Documented knowledge about a software architecture can be interpreted and used by humans, whereas formalized knowledge can be created and used by both humans and software systems. Accordingly, the above problems can be broadly categorized into two groups: • The architectural drivers that result in a specific software architecture. These drivers often remain tacit, include a variety of non-technical issues like organizational constraints and policies, and are often not documented at all, or cannot be traced to or from the architecture. In GSD we need notations and methods to turn these types of tacit AK into explicitly documented AK. • The architectural decisions that make up a specific architecture. Based on the architectural drivers, typically software architecture consists of a structured set of design decisions that addresses the requirements put on the system. In GSD we need to capture these design decisions as first-class entities in the documentation, especially the specification of the system. The main focus is the conversion of documented AK into formalized AK. Architectural Grid Components The main questions we have to answer in getting global are: What AK do we need to capture and store? And how do we use the AK stored? We do not have an answer yet, but we advocate the need for the following components: 1. A method to extract the right AK. We need guidelines for eliciting relevant AK from stakeholders, e.g. [6]. These address skills, concerns, context and the anticipated type of use. Tacit knowledge, technical and non-technical, is by definition difficult to elicit: if knowledge remained tacit, quite often people did not even realize that it was actually used for development: guidelines should aid people in
2.
3.
4. 5.
6.
rationalizing the decisions they took, their implicit assumptions and the background (e.g. cultural) they brought in the software engineering process. A language to model AK and its relevant context (incl. stakeholder concerns, business context, organizational and cultural issues). It is important to identify the major contextual aspects that impact the architecture: the explicit integration of technical and non-technical architectural assumptions and decisions enriches documentation, which is the enabling factor to manage evolution. Each visual representation corresponds to a specific view on the AK stored. The amount and kind of AK stored thus determines the views that can be extracted. An extension of the AK modeling language to capture knowledge about the actual/anticipated evolution of the architecture, together with support to guide and reason about reuse and evolution. This includes mechanisms like traceability (from contextual aspects to architectural solutions), variability (relating contextual aspects to possible options), viewpointing (selecting appropriate aspects), and support for architectural cross-cuts (concerns that affect multiple parts of the architecture). The first-class representation of architectural design decisions and their use in the design of the software architecture. The representation facilitates addition, change and removal of design decisions. The use of formalized AK during system evolution and system operation. The former allows for decreased maintenance effort due to the ease of adding, changing and removing design decisions. The latter addresses the area of dynamic software architectures, systems adapting and evolving design artifacts at run-time. Making AK available through an architectural grid. The architectural grid is a global network of organizations and people sharing AK. It represents the infrastructure on which AK is exchanged. AK can be implemented as being made up of an ontology language (the types of architectural elements in the domain of interest, their semantics, inter-relationships and properties) and the architectural ontology (the entities existing in the domain). Existing initiatives in grid computing already exist [3]; an architectural grid would be the heart for GSD as based on shared AK.
Conclusions To use architecture as the central artifact among the stakeholders involved in software engineering, more research and experimentation is required, mainly along two dimensions: modeling of the different types of AK in an integrated interdisciplinary way; and managing AK according to its uses. These dimensions are already important in any large development, and in GSD they play a fundamental role. Architecture is the overall picture that makes explicit technical knowledge about software systems. If it integrates non-technical knowledge too, it carries all information relevant to overcome geographical boundaries and time distance. Also, knowledge transfer and management solutions [2] are needed to make the communication process agile and dynamic. The architectural grid can provide the necessary infrastructure for the sharing and development of integrated AK; it is the enabling factor for distributed development and interactions across closed and open communities that are geographically dispersed.
References 1. Bass, L., Clements, P. and Kazman, R., Software Architecture in Practice, Addison-Wesley, Second Edition, 2003. 2. Dingsøyr, T. and Conradi, R., A Survey of Case Studies of the Use of Knowledge Management in Software Engineering, International Journal of Software Engineering and Knowledge Engineering 12(4), 2002, pp 391414. 3. Grid Initiatives: European Data Grid http://eu-datagrid.org; Globus Alliance http://www.globus.org 4. Lago, P. and van Vliet, H. Observations for the Recovery of a Software Product Family, Third Software Product Line Conference, Springer LNCS, Aug. 2004. 5. Nonaka, I., Takeuchi, H., The Knowledge-Creating Company: How Japanese companies create the dynasties of innovation, Oxford University Press, 1995. 6. Schreiber, G. et al, Knowledge Engineering and Management, the CommonKADS Methodology,
MIT Press, 2000.
