Matthias Naab

Static evaluation of software architectures

The software architecture is one of the most crucial artifacts within the lifecycle of a software system. Decisions made at the architectural level directly enable, facilitate, hamper, or interfere with the achievement of business goals, functional and quality requirements. Architecture evaluations play an important role in the development and evolution of software systems since they determine how adequate the architecture is for its intended usage. This paper summarizes our practical experience with using architecture evaluations and gives an overview on when and how static architecture evaluations contribute to architecture development. We identify ten distinct purposes and needs for static architecture evaluations and illustrate them using a set of industrial and academic case studies. In particular, we show how subsequent steps in architecture development are influenced by the results from architecture evaluations

Architectural flexibility in a software-system's life-cycle: systematic construction and exploitation of flexibility

Software evolution is omnipresent and only with adequate flexibility it can be mastered in time and budget. Flexibility is supported by many architectural mechanisms, but more methodological support for a life-cycle-phases bridging approach of flexibility is still desirable. Therefore, in this paper we contribute a life-cycle-phases bridging approach for flexibility. Our approach supports architects during system design to achieve flexibility and during system evolution to exploit flexibility. We build on existing flexibility analysis techniques and extend them to give architects specific guidance and tool-support. For architecture design, we introduce an automated flexibility analysis with real-time feedback in architecture tools. For software evolution we provide a flexibility exploitation analysis which builds up on the results of the design time analysis and enables effective utilization of provided flexibility by deriving flexibility-aware work-plans. We demonstrate our approach by applying it to a checkin system, report first validation results from an empirical study and propose further validation activities.

Mobility in the virtual office: a document-centric workflow approach

In todays global business, office workers conducting their business have a high demand for mobility. Nevertheless, the software support for workflows and the induced collaboration with other office workers is weak in mobile situations, for instance, while people are traveling. In some situations, no access to centrally provided services is possible; in other situations, this access is difficult to achieve due to security reasons and other technical constraints. Thus, the existing workflow management systems are mostly inappropriate to support mobile office workers and their specific needs. In this paper, we present a document-centric solution to tackle the existing deficiencies in the support of mobile workflow processing. These deficiencies are made explicit in six typical scenarios from the domain of office environments. The core of the solution is a reference architecture dominated by the peer-to-peer style. Hence, the overall office environment is fully decentralized into computational nodes. The documents processed by office workers are packaged together with workflow information in so-called VOF documents and transmitted among the nodes of respective users to execute the overall workflow. In a prototypical implementation, we showed that the concepts introduced are applicable.

A Proactive Support for Conceptual Interoperability Analysis in Software Systems

Successfully integrating a software system with an existing other software system requires, beyond technical mismatches, identifying and resolving conceptual mismatches that might result in worthless integration and costly rework. Often, not all relevant architectural information about the system to integrate with is publicly available, as it is hidden in internal architectural documents and not exposed in the public API documentation. Thus, we propose a framework of conceptual interoperability information and a formalization of it. Based on this framework, a systems architect can semi-automatically extract interoperability-relevant parts from his architecture and lower-level design documentation and publish it in a standardized and formalized way. The goal is to keep the additional effort for providing the interoperability-relevant information as low as possible and to encourage architects to provide it proactively. Thus, we extract from UML diagrams and textual documentation information that is relevant for conceptual interoperability. Companies that aim at interoperation of their systems with others, e.g. Companies initiating an ecosystem, should be highly motivated to provide such interoperability information in order to grow their business impact by more successful interoperations. In a more advanced level, also the architect, who is integrating his system with a provided one, could extract interoperability-related information about his existing system and we envision to automatically match the pieces of both sides and identify conceptual mismatches.

Why Data Needs more Attention in Architecture Design - Experiences from Prototyping a Large-Scale Mobile App Ecosystem

Data is of great importance in computer science and in particular in information systems and how data is treated has major impact on a systems quality attributes. Nevertheless, software architecture research, literature, and practice often neglect data and focus instead on other architectural topics like components and connectors or the management of architecture decisions in general. This paper contributes experiences from the prototyping of a large-scale mobile app ecosystem for the agricultural domain. Architectural drivers like multi-tenancy, different technical platforms and offline capability led to deep reasoning about data. In this paper, we describe the architectural decisions made around data in the app ecosystem and we present our lessons learned on technical aspects regarding data, but also on data modeling and general methodical aspects how to treat data in architecting. We want to share these experiences with the research community to stimulate more research on data in software architecture and we want to give practitioners usable hints for their daily work around data in constructing large information systems and ecosystems.

A Method for Collaborative Development of Systems of Systems in the Office Domain

Seamless interoperability across system boundaries and optimally tailored solutions for customers are dominating concerns in the vision of future office infrastructures. This means to change the way how office systems are developed from todaypsilas ad-hoc integration of independent systems towards a collaborative approach for adequate systems of systems. In this paper, we propose a development method based on product line engineering to support the efficient production of customized solutions. The interoperability issues are tackled by a collaboration model separating solution providers and suppliers and by a reference architecture defining clear specifications of the components to be integrated. Together with our production method, interoperability in complex systems of systems is supported by construction.

Mitigating the Risk of software change in practice: Retrospective on more than 50 architecture evaluations in industry (Keynote paper)

Architecture evaluation has become a mature instrument to mitigate the risk of software change. It enables decision-making about software systems being changed or being prepared for change. While scientific literature on architecture evaluation approaches is available, publications on practical experiences are rather limited. In this paper, we share our experiences - after having performed more than 50 architecture evaluations for industrial customers in the last decade. We compiled facts and consolidate our findings about the risk of software change and architecture evaluations as a means to mitigate change. We highlight the role of reverse engineering in these projects. In addition, we share our lessons learned and provide data on common beliefs and provide examples for frequently observed misconceptions on the power of reverse engineering. This industrial and practical perspective allows practitioners to benefit from our experience in their daily architecture work and the scientific community to focus their research work on the generalizability of our findings.

A Service-Oriented View on Business Processes and Supporting Applications

Even if SOA has received much attention, there is still no common definition of what a SOA is or what a SOA should provide for business. In this paper, we have therefore introduced a conceptual model on service orientation that explains the impact of service orientation on business processes and supporting applications. We consider this consolidation as an essential step for establishing methods for a better business IT alignment as well as more systematic and integrated business and software engineering in the context of service-oriented enterprises.

Task-Specific Architecture Documentation for Developers

It is widely agreed that architecture documentation, independent of its form, is necessary to prescribe architectural concepts for development and to conserve architectural information over time. However, very often architecture documentation is perceived as inadequate, too long, too abstract, too detailed, or simply outdated. While developers have tasks to develop certain features or parts of a system, they are confronted with architecture documents that globally describe the architecture and use concepts like separation of concerns. Then, the developers have the hard task to find all information of the separated concerns and to synthesize the excerpt relevant for their concrete task. Ideally, they would get an architecture document, which is exactly tailored to their need of architectural information for their task at hand. Such documentation can however not be created by architects in reasonable time. In this paper, we propose an approach of modeling architecture and automatically synthesizing a tailored architecture documentation for each developer and each development task. Therefore architectural concepts are selected from the model based on the task and an interleaving of concepts is done. This makes for example all interfaces explicit, which a component has to implement in order to comply with security, availability, etc. concepts. The required modeling and automation is realized in the tool Enterprise Architect. We got already very positive feedback for this idea from practitioners and expect a significant improvement of implementation quality and architecture compliance.

How to Perform the Documentation Quality Check (DQC)

he main goal of the Documentation Quality Check (DQC) is to check how adequate the architecture documentation is for its audience and purposes. The evaluation checks both the content and the representation of the architecture documentation. Thinking from the perspective of the audience and considering the purposes of the documentation helps to rate the adequacy of the documentation. In addition, principles of good documentation, such as structure, uniformity, or traceability, can be checked. These principles are determined by the mental capabilities of the readers and can be used across domains and system types.