Frank Buschmann

Patterns, frameworks, and middleware: their synergistic relationships

The knowledge required to develop complex software has historically existed in programming folklore, the heads of experienced developers, or buried deep in the code. These locations are not ideal since the effort required to capture and evolve this knowledge is expensive, time-consuming, and error-prone. Many popular software modeling methods and tools address certain aspects of these problems by documenting how a system is designed However they only support limited portions of software development and do not articulate why a system is designed in a particular way, which complicates subsequent software reuse and evolution. Patterns, frameworks, and middleware are increasingly popular techniques for addressing key aspects of the challenges outlined above. Patterns codify reusable design expertise that provides time-proven solutions to commonly occurring software problems that arise in particular contexts and domains. Frameworks provide both a reusable product-line architecture [1] - guided by patterns - for a family of related applications and an integrated set of collaborating components that implement concrete realizations of the architecture. Middleware is reusable software that leverages patterns and frameworks to bridge the gap between the functional requirements of applications and the underlying operating systems, network protocol stacks, and databases. This paper presents an overview of patterns, frameworks, and middleware, describes how these technologies complement each other to enhance reuse and productivity, and then illustrates how they have been applied successfully in practice to improve the reusability and quality of complex software systems.

To Pay or Not to Pay Technical Debt

Ward Cunningham coined the term technical debt as a metaphor for the trade-off between writing clean code at higher cost and delayed de livery, and writing messy code cheap and fast at the cost of higher maintenance efforts once its shipped. Joshua Kerievsky extended the metaphor to architecture and design. Technical debt is similar to financial debt: it supports quick development at the cost of compound interest to be paid later. The longer we wait to garden our design and code, the larger the amount of interest. Discussions of the metaphor have distinguished different types of technical debt and how and when to best pay them off. Most agree that, sooner or later, technical debt will come due. But is this assumption universally true? If its better to pay interest, what factors influence the decision to service the debt? And if we decide to retire it, what approach should we take?

Learning from Failure, Part 2: Featuritis, Performitis, and Other Diseases

In the first part of this article, the author analyzed some common software architecture mistakes. In this article, the author discussed and explored the three mistakes that most architects know all too well. The author and his architect colleague Klaus Marquardt named these mistakes as if they were diseases: featuritis, flexibilitis, and performitis.

Framework-Based Software Architectures for Process Automation Systems

Abstract This paper describes how framework technology helps building flexible software architectures for Process Automation Systems. First we discuss constraints and conditions within industry under which such systems are to be built. Then we introduce the framework concept as one approach to master the challenges of todays busines situation: what are frameworks, what are their underlying software concepts, how are they built, and what benefits do they provide—all illustrated with help of a real-world example, a framework for hot rolling mills. The paper concludes with lessons learned from building frameworks in process automation and outlines future directions in using them.

A Week in the Life of an Architect

Leadership is the key for architects to balance all their activities and duties with the interests of different stakeholders without losing control of the architecture under development. They must have a clear vision and strict focus on key aspects of success. All their activities should be goal-driven and in direct cooperation and interaction with the relevant stakeholder groups.

Value-Focused System Quality

To assure the expected operational and developmental system quality is actually delivered, a test-driven approach to architecture elaboration is a powerful tool. Evaluations, simulations, and running code provide direct feedback as to whether a systems architecture and implementation support its quality requirements. Test-driven design is also a fantastic vehicle to check if the specified qualities are sufficient for providing the expected value. Unless you physically experience the system, all its requirements, especially quality aspects, are just assumptions. Thus, you might need to adjust the assumed quality requirements when you see the system in action. The quality/ value feedback loop closes.

Five Considerations for Software Architecture, Part 1

Many software architectures suffer from unnecessary, accidental complexity: arbitrary flexibility for its own sake, unnecessary features, design choices whose complexity is out of proportion for the problems and requirements at hand, or a focus on reusability rather than usability.The XDD family of approaches- in particular, test-driven, responsibility driven, and domain-driven design and development set the architects focus on what to design, identifying usable architecture concepts more naturally.

Architecture Quality Revisited

There is a common belief in the software community that nonfunctional quality is fundamentally important for architecture sustainability and project success. A recent study, however, suggests that nonfunctional quality is of little relevance for users and customers, but instead mainly a concern for architects. Nontechnical constraints, such as licenses and technology providers, appear to be driving design as prominently as quality requirements. Quality requirements, such as performance, are mainly defined by architects on the basis of their experiences, and are often poorly documented and validated. This column explores whether the software community actually overestimates the relevance of nonfunctional qualities or whether the studys observations indicate a valid position on nonfunctional quality for certain types of application domains, development approaches, and organizational setups.

Architecture and Agility: Married, Divorced, or Just Good Friends?

Does agile development need architecture? Does architecture need agile development? These two questions are debated time and again, frequently with great passion but quite often more polarized than open minded. In this edition of the column, the authors try to offer a more evenhanded perspective on this debate. Instead of posing and discussing culturally biased assumptions, they consider a more open and neutral question: what is the relationship between architecture and process?

Evaluation Model for Assessment of Cyber-Physical Production Systems

Cyber-physical production systems based on technologies such as machine to machine communication, the Internet of Things and other cutting edge technologies are going to advance manufacturing automation and industrial production. Information technology seems once again to be the driving force for change in manufacturing automation. But what are the characteristics of such systems in comparison to the existing approaches? In this article we recommend an evaluation model for cyber-physical production systems is proposed based on a set of system characteristics, which defines specific abilities and performance indicators. Furthermore, an analysis and verification of that model is presented sketching the typical pattern and impact of cyber-physical production systems. As a result a refined evaluation model is available, suitable for the characterization of cyber-physical technologies and thereby enabling a technological assessment.