Rhino Research is a consulting and training company focusing on software architecture. Our primary consultant and instructor is Dr. George Fairbanks, who has a Ph.D. in Software Engineering from Carnegie Mellon University and has been teaching software architecture and object oriented design since 1998.
Articles
Here is a list of articles and other substantial blog posts, generally on software architecture.
Book chapter: Software Architecture & Modeling
Engineers use abstraction and models to solve large and complex problems. However, the use of models does not mean that you must design everything up front or put architects in corner offices. You can separately decide job roles, process, and the engineering artifacts.
Software architecture is about the design of your system and the impact it has on the system’s qualities, things like performance, security, and modifiability. Pinning the definition down further is difficult, but we know that architecture acts as the skeleton of a system, influences system qualities (called quality attributes), and is independent of the system’s functionality.
Sometimes any architecture you choose will work out just fine; other times it is not obvious that a solution is even possible. The harder the problem is, the more you will need to pay attention to your architecture choices.
This chapter discusses three levels of engagement with architecture. In architecture-indifferent design, you pay little attention to the architecture, perhaps using a presumptive architecture, such as a 3-tier system on an IT project. In architecture-centric design, you design the architecture so that it helps the system achieve a desired property. And with architecture hoisting, you build source code that manages a property at runtime.
Book chapter: Risk-Centric Model
As they build successful software, software developers are choosing from alternate designs, discarding those that are doomed to fail, and preferring options with low risk of failure. When the risks are low it is easy to plow ahead without much thought, but, invariably, challenging design problems emerge and developers must grapple with high-risk designs, ones they are not sure will work.
To address failure risks, the earliest software developers invented design techniques that helped them build successful software, such as domain modeling, security analyses, and encapsulation. Today, developers can choose from a huge number of design techniques. From this abundance, a hard question arises: Which design and architecture techniques should developers use?
If there were no deadlines then the answer would be easy: use all the techniques. But that is impractical because a hallmark of engineering is the efficient use of resources, including time. One of the risks developers face is that they waste too much time designing. So a related question arises: How much design and architecture should developers do?
Book chapter: Model Relationships
Over the years, software modelers have developed a useful set of modeling ideas. A clear understanding of these inter-model relationships is important, since you will use them in building models of software architecture. You are most likely using these ideas already: “This diagram is a zoomed-in view of this part of the other diagram,” or “This diagram shows the system from a performance perspective.”
To reinforce that these relationships are more general than software architecture or UML, you will see neither of those here. The chapter uses a running example of a house, with blueprints and other plans, that should be familiar domain to all readers.
This chapter explains these essential modeling relationships with sufficient precision that you should be able to understand and apply them. Increasing the formality will reduce the clarity of presentation for most readers. For example, binding is an easy concept, but to do it right requires that the symbol names are unique, and refinement is even more complex. If you were designing an architecture description language or a CASE tool to draw these models, you would require more precision than is used here.
The Kitchen Drawer Problem
The refactoring of the book reminded me of a problem that I’m sure others have discovered and named, but I’ve called it the Kitchen Drawer Problem. It goes like this. When you have moved to a new house and are putting away your kitchen things, there is invariably one drawer with miscellaneous stuff. Even if you have dozens of drawers, each of which has a coherent grouping of things (like silverware or towels), there’s always that drawer with odd things. As you get more stuff, or drawers, or both, your organization scheme improves so things that were previously in the misc. drawer now have a natural home, but that misc. drawer never goes away (or doesn’t go away for long).
An Architectural Perspective on Software Design
What is architecture design?
For technophiles like me, it was amazing. A friend was playing music at his party via iTunes — nothing unusual there — but he was controlling it from his sofa using his phone. Lots of folks play music at parties from their laptop, but he had an application that showed him the songs in his library and let him queue up songs to play. Since I had a smartphone too, and technical pride was on the line, I decided to find or build a similar application.
On the internet, I found an app for my phone. It was visually attractive and had many features even though it was an early release. However, when I ran it, I found some problems. Initially, I the app would not talk to my media center and it was hard for me to diagnose why. And navigating through the pages of the app was slow — even backing up a page caused a noticeable lag.
After looking at the code, I realized that these problems could be fixed by rewriting the communication library it was using. To solve the problems, the library needed to cache results and report more details about connection errors. In a minor way, the application had an unsuitable architecture.
It is worth relating this story for three reasons. First, it helps to demonstrate the value of an architectural perspective that goes beyond just features. The agile movement has been enormously helpful in that it has cleared out much of the process cruft that I have seen building up in large IT shops. However, some agile advocates recommend a pure focus on functionality and no up-front design at all. I believe that goes too far, and this story shows how a small amount of architectural consideration can be helpful.
Second, it helps to show that architecture is about modeling and abstractions. The essence of a problem can become clearer when using a model that contains only relevant details. In this case, if I didn’t already know it before, a simple model annotated with timing information would convince me that no amount of speedy routines on the client side is going to yield lower latency user interaction until the number and frequency of server requests is reduced.
Third, it helps to reveal that architecture does not come from the problem domain. If we agree that the problem domain here is music, then it is clear that knowing domain facts (e.g., artists produce albums containing songs; playlists are ordered lists of songs) does not lead us to choose a client-server architectural style.
Whitepaper on Software Architecture Education
Many organizations struggle to choose the most appropriate courses to advance their people. They struggle because, while it is relatively easy to describe their desired end state, the path to get to it is unclear.
Software architecture education is particularly tricky. If you take a class on Java or Struts, you do so because you do not yet know that language or framework. But everyone has some ability to design programs already, so it is not clear what benefit will come from a general class on architecture and design. If you are considering an architecture class, you suspect that your team would benefit from software architecture and design education, but are having a hard time putting your finger on exactly what is missing. As a consequence, it’s hard to be sure if any particular course is what the team needs. This whitepaper describes a structured approach to thinking about your architecture and design needs.
What is a Framework?
Software frameworks have changed significantly since they were described by researchers more than a decade ago. They have entered mainstream use in most domains of software development, and their structure and interaction mechanisms have evolved. This paper provides a revised definition of frameworks and surveys commonly used frameworks to extract two categorizations: a categorization of the different kinds of frameworks found in the wild and a summary of common interaction mechanisms employed by frameworks. Four popular frameworks are described in detail to illustrate these findings. The paper also discusses unique framework challenges and avenues for future research on frameworks.
Be Wary of Architecture Documentation Packages
The new boogeyman: the documentation package. This too is a good idea from the SEI that has taken an unfortunate turn. A documentation package is a relatively complete description of an architecture from many standpoints (views). It is described in the book Documenting Software Architectures (disclaimer: I helped out the many authors a bit on one of the chapters for the upcoming 2nd edition, and my advisor is one of the authors). A documentation package is also a very expensive artifact to build. My belief is that a documentation package is something you may choose to build rather than a normal step in building a system, which is a conclusion you might draw from the book. Again the SEI experience with very large systems may be causing the conflation, since if I were building a $1B system then I’d be building a documentation package for its architecture. However, most systems do not (yet) cost $1B, and most teams should not be building a documentation package.
Architecture Hoisting
Following architecture-centric design means that you are using the architecture to ensure a property or to achieve a quality attribute. Code can diverge from the design, often unintentionally, and disrupt your plans. We can use architecture hoisting to ensure that the code has those same properties or qualities as the design.
Architecture hoisting is the direct ownership, management, or guarantee by the architecture of a feature, property, or quality attribute. It lets developers depend on the architecture for the hoisted feature, property, or quality.
Humans as Architecture Analysis Machines
Once you articulate a vision of how software architecture could be done well, which includes the creation of models that enable analysis, the next question is, “What analyses can I do?” At this point we can either go down the path of somewhat obscure academic efforts such as rate monotonic analysis or queuing theory and pretend that they are appropriate for mainstream use. Alternately, we could admit that there really aren’t many architecture analyses yet. Let me suggest a third path.
Human brains are remarkable at processing information, but quite dependent on the form of that information. Imagine trying to navigate from NY to LA if you were given an alphabetical listing of the street segments in the country. This would thwart a human but impede a computer only slightly. That’s because people have lots of visual processing capabilities that we use to find a route on a map. Maps are drawn to work with those capabilities, for example by drawing major roads thicker than minor roads.
Design Fragments
Frameworks are a valuable way to share designs and implementations on a large scale. Client programmers, however, have difficulty using frameworks. They find it difficult to understand non-local client-framework interactions, design solutions when they do not own the architectural skeleton, gain confidence that they have engaged with the framework correctly, represent their successful engagement with the framework in a way that can be shared with others, ensure their design intent is expressed in their source code, and connect with external files.
A design fragment is a specification of how a client program can use framework resources to accomplish a goal. From the framework, it identifies the minimal set of classes, interfaces, and methods that should be employed. For the client program, it specifies the client-framework interactions that must be implemented. The structure of the client program is specified as roles, where the roles can be filled by an actual client s classes, fields, and methods. A design fragment exists separately from client programs, and can be bound to the client program via annotations in their source code. These annotations express design intent; specifically, that it is the intention of the client programs to interact with the framework as specified by the design fragment.
Software Architecture at a Large Financial Firm
System builders have historically used informal software architecture models to understand options, make choices, and communicate with others. Research into software architecture over the past fifteen years has indicated that more precise architecture models may be beneficial. At a large financial firm, we applied precise software architecture techniques on four software projects and this experience has revealed a number of practical issues. We made the following observations across the projects:
- Architecture models can be used to bridge gaps between business requirements and technology
- A small collection of techniques and a detail knob are practical and useful in a variety of projects
- Architecture modeling techniques amplify the skills of the architects
- A model of domain concepts and relationships is helpful when building architecture models
- It is difficult to know when to stop adding detail to your architecture model
We believe that these observations motivate future research and can help practitioners make software architecture more effective in practice.
Software Architecture Education
A large financial company, struggling with legacy systems that did not interoperate, performed a pilot project to teach software architecture to an enthusiastic application development team. Experienced mentors, including the author, worked with the application team for seven months who completed their engineering goal successfully. However, the mentors were unsuccessful in their attempt to train any of the six members of application team to create architecture models on their own, though they were able to create them collaboratively with the mentors. This surprising result is due to the application team’s strong preference for concrete artifacts over abstract ones. Even more surprising, an application developer from a different project, ‘Developer X’, read the architecture modeling documentation on an internal website and, without mentoring, created good architecture models within a few days. In light of this failure to teach software architecture, two short-term strategies are suggested for the use of software architecture in companies and long-term strategies are discussed.