Hans van Vliet

Building up and reasoning about architectural knowledge

Architectural knowledge consists of architecture design as well as the design decisions, assumptions, context, and other factors that together determine why a particular solution is the way it is. Except for the architecture design part, most of the architectural knowledge usually remains hidden, tacit in the heads of the architects. We conjecture that an explicit representation of architectural knowledge is helpful for building and evolving quality systems. If we had a repository of architectural knowledge for a system, what would it ideally contain, how would we build it, and exploit it in practice? In this paper we describe a use-case model for an architectural knowledge base, together with its underlying ontology. We present a small case study in which we model available architectural knowledge in a commercial tool, the Aduna Cluster Map Viewer, which is aimed at ontology-based visualization. Putting together ontologies, use cases and tool support, we are able to reason about which types of architecting tasks can be supported, and how this can be done.

Business Modelling Is Not Process Modelling

Innovative e-business projects start with a design of the e-business model.We often encounter the view, in research as well as industry practice, that an e-business model is similar to a business process model, and so can be specified using UML activity diagrams or Petri nets. In this paper, we explain why this is a misunderstanding. The root cause is that a business model is not about process but about value exchanged between actors. Failure to make this separation of concerns leads to poor business decision-making and inadequate business requirements.

Architecture-level modifiability analysis (ALMA)

Several studies have shown that 50-70% of the total lifecycle cost for a software system is spent on evolving the system. Organizations aim to reduce the cost of these adaptations, by addressing modifiability during the systems development. The software architecture plays an important role in achieving this, but few methods for architecture-level modifiability analysis exist. Independently, the authors have been working on scenario-based software architecture analysis methods that focus exclusively on modifiability. Combining these methods led to architecture-level modifiability analysis (ALMA), a unified architecture-level analysis method that focuses on modifiability, distinguishes multiple analysis goals, has explicit assumptions and provides repeatable techniques for performing the steps. ALMA consists of five main steps, i.e. goal selection, software architecture description, change scenario elicitation, change scenario evaluation and interpretation. The method has been validated through its application in several cases, including software architectures at Ericsson Software Technology, DFDS Fraktarna, Althin Medical, the Dutch Department of Defense and the Dutch Tax and Customs Administration.

The relation between EA effectiveness and stakeholder satisfaction

Enterprise Architecture (EA) is increasingly being used by large organizations to get a grip on the complexity of their business processes, information systems and technical infrastructure. Although seen as an important instrument to help solve major organizational problems, effectively applying EA seems no easy task. Active participation of EA stakeholders is one of the main critical success factors for EA. This participation depends on the degree in which EA helps stakeholders achieve their individual goals. A highly related topic is effectiveness of EA, the degree in which EA helps to achieve the collective goals of the organization. In this article we present our work regarding EA stakeholder satisfaction and EA effectiveness, and compare these two topics. We found that, regarding EA, the individual goals of stakeholders map quite well onto the collective goals of the organization. In a case study we conducted, we found that the organization is primarily concerned with the final results of EA, while individual stakeholders also worry about the way the architects operate.

What's in an Electronic Business Model?

An electronic business model is an important baseline for the development of e-commerce system applications. Essentially, it provides the design rationale for e-commerce systems from the business point of view. However, how an e-business model must be defined and specified is a largely open issue. Business decision makers tend to use the notion in a highly informal way, and usually there is a big gap between the business view and that of IT developers. Nevertheless, we show that conceptual modelling techniques from IT provide very useful tools for precisely pinning down what e-business models actually are, as well as for their structured specification. We therefore present a (lightweight) ontology of what should be in an e-business model. The key idea we propose and develop is that an e-business model ontology centers around the core concept of value, and expresses how value is created, interpreted and exchanged within a multi-party stakeholder network. Our e-business model ontology is part of a wider methodology for e-business modelling, called e3 -value, that is currently under development. It is based on a variety of industrial applications we are involved in, and it is illustrated by discussing a free Internet access service as an example.

Stakeholder Perception of Enterprise Architecture

Enterprise Architecture (EA) is increasingly being used by large organizations to get a grip on the complexity and inflexibility of their business processes, information systems and technical infrastructure. Although seen as an important instrument to help solve major organizational problems, effectively applying EA seems no easy task. Efficient collaboration between architects and EA stakeholders is one of the main critical success factors for EA. The basis for efficient collaboration between architects and EA stakeholders is mutual understanding. In EA research, there has been much focus on the role of the architect; there is little research on the EA stakeholder. In this article we present the cognitive structure of four EA stakeholder groups, revealing how they expect the EA function to help them achieve their goals. With this we gain understanding of the EA stakeholder and provide the basis for better collaboration between architects and EA stakeholders.

Software maintenance from a service perspective

SUMMARY In this paper we investigate the differences between software maintenance and software development from a service point of view, and the consequences thereof for the maturity of software maintenance organizations. We argue that software maintenance can be seen as providing a service, whereas software development is concerned with the development of products. Differences between products and services affect the way in which customers assess their respective quality. Consequently, customers will judge the quality of software maintenance differently from that of software development. This in turn implies a need for different processes than those used by the average software development organization. We discuss two overall approaches to achieve a high-quality IT service organization which include these service-specific processes: ITIL and the IT Service Capability Maturity Model. ITIL is a set of best practices widely used within the IT service industry. The IT Service CMM is a maturity growth model akin to the Software CMM.

Explicit assumptions enrich architectural models

Design for change is a well-known adagium in software engineering. We separate concerns, employ well-designed interfaces, and the like to ease evolution of the systems we build. We model and build in changeability through parameterization and variability points (as in product lines). These all concern places where we explicitly consider variability in our systems. We conjecture that it is helpful to also think of and explicitly model invariability, things in our systems and their environment that we assume will not change. We give examples from the literature and our own experience to illustrate how evolution can be seriously hampered because of tacit assumptions made. In particular, we show how we can explicitly model assumptions in an existing product family. From this, we derive a metamodel to document assumptions. Finally, we show how this type of modeling adds to our understanding of the architecture and the decisions that led to it.

Experiences with ALMA: architecture-level modifiability analysis

Modifiability is an important quality for software systems, because a large part of the costs associated with these systems is spent on modifications. The effort, and therefore cost, that is required for these modifications is largely determined by a systems software architecture. Analysis of software architectures is therefore an important technique to achieve modifiability and reduce maintenance costs. However, few techniques for software architecture analysis currently exist. Based on our experiences with software architecture analysis of modifiability, we have developed ALMA, an architecture-level modifiability analysis method consisting of five steps. In this paper we report on our experiences with ALMA. We illustrate our experiences with examples from two case studies of software architecture analysis of modifiability. These case studies concern a system for mobile positioning at Ericsson Software Technology AB and a system for freight handling at DFDS Fraktarna. Our experiences are related to each step of the analysis process. In addition, we made some observations on software architecture analysis of modifiability in general.

The many faces of architectural descriptions

In recent years architecture has acquired recognition as playing a pivotal role in change processes. Despite this recognition, describing architecture has proven to be difficult. Architecture frameworks have been defined to address this problem. However, there are many of them, and together they leave us with seemingly contradicting terminology. What are the underlying forces that caused people to create so many different frameworks? What do these frameworks teach us about the essence of architecting? Where do I start to select or create a framework for my current project? With these questions in mind we set out to perform a comparison of existing architecture frameworks. We ended up with a deeper understanding of the function of a framework, and “discovered” nine fundamental dimensions that seem to underlie architectural thinking. These “base dimensions” can be used to clarify the meaning of individual architecture documents independent of the framework they originate from, and they can be helpful in defining new architecture frameworks or situational architecture descriptions. In this paper we also relate our findings to IEEE 1471, which is another important generalisation of existing frameworks.