Just Enough Software Architecture book, by author George Fairbanks, focuses on a risk-driven approach to software architecture development.
George explains the Architecture Modeling process from different perspectives such as Engineering Use Models, Conceptual Model, Domain Model, Design Model and the Code Model. He also discusses the various architecture styles including Big ball of mud, Pipe-and-filter, Batch-sequential, Map-Reduce and talks about the distinction between architectural patterns and architectural styles. The discussion also includes topics like evolutionary design, architecture refactoring and how to analyze, test and validate the architecture models.
George has been teaching software architecture and object-oriented design for over a decade for companies including Kinetium, Valtech, and Platinum Technology. In the Spring of 2008 he was the co-instructor for the graduate software architecture course at Carnegie Mellon University. George has been a program committee member for the Working International Conference on Software Architecture (WICSA), the International Conference on Software Maintenance (ICSM), and the European Conference on Software Architecture (ECSA). He has been a referee for IEEE Transactions on Software Engineering (TSE) and IEEE Software.
InfoQ spoke with George about the book, the main motivation for writing it, his thesis project on design fragments in the software framework domain, and other topics. We are also making an excerpt (Chapters 1 - Introduction, 3 - Risk-Driven Model and 7 - Conceptual Model of Software Architecture; 1,382 KB PDF) from the book available for our readers.
InfoQ: What was the main motivation behind writing the new book?
George Fairbanks: There are two things. The first is to overturn the idea that architecture means shelfware documents. Both object-oriented design and software architecture are ways of solving software design problems - they are engineering skills that developers can learn to become more effective. Software architecture is more about how you think about design problems and solve them rather than the documents you write.
The second is to overturn the misperception that agile and architecture are incompatible. Like many other developers with a history in telecom, I learned that when you build a telephone switch, regulations say it must provide dial tone in 40ms, a difficult requirement to achieve. Later, I worked in finance and you don't build a system for a bank that lacks security. It doesn't matter what other features you have if you provide dial tone in 50ms or let bad guys steal money.
Not every project has failure risks like that, things that keep you awake at night with worry. But when you do have those worries - Will my website scale to 100M hits? Is my voting system secure? - you want engineering techniques that help you solve the problem. The misperception is that this should take months when you can often do the needed architecture design in hours or days.
InfoQ: You worked on a thesis project called design fragments in the software framework domain. Can you discuss more about that project and how it influenced the book writing?
George: There's a strong argument to be made that frameworks have been our best answer to the software crisis. People used to complain that software was hardly getting better while hardware was racing ahead, but now they complain about how much software is included with their operating system. Using a framework, you can often solve a complex problem with just a dozen lines of code. The problem, as we've all experienced, is finding out *which* 12 lines of code to write. That can take all day.
Design fragments are patterns that express how client code plugs into frameworks. I built a tool that lets you browse a catalog of patterns, bind them to your code, and statically check your use of the pattern. This was thesis research done at Carnegie Mellon University, advised by David Garlan and Bill Scherlis, with Jonathan Aldrich and Ralph Johnson on the committee.
This year at the OOPSLA/SPLASH conference, I met up with Ralph and was reminded of advice he gave me at the time. Recalling his experience trying to popularize refactoring and the refactoring browser (Bill Opdyke's thesis, and others), he told me that the problem isn't other people taking my ideas, it's them ignoring those ideas! It took about a decade for refactoring to become commonplace in IDEs. I hope that if people like you keep asking about design fragments, perhaps that good idea won't sink into the swamp.
InfoQ: You talk about applying the risk-driven model to an agile process in the book. What are the real-world practical tips on incorporating architecture related tasks and efforts into an agile software development process?
George: The risk-driven model described in the book is simple. You prioritize your risks (things that you worry might cause your project to fail, like not handling 1M users or integration problems), choose and apply architecture techniques that mitigate that risk, then decide if the risks are handled. That often takes just a few hours or a few days and is easy to fit into a 2-week iteration alongside feature delivery.
But to embrace that idea means throwing away some other ideas. The first is that architecture means designing everything in advance. Instead, you only investigate and design the riskiest parts. Sometimes you will need to dig deep into those to allay your concerns, other times not.
The second idea to discard is the idea of complete architecture descriptions. It's true that sometimes you need a complete blueprint. Usually that is because you are on a huge project and you need to communicate a design to other federated teams. Those of you in this situation already know it because your biggest challenge is organizational (how to get 1000 developers pointed in the same direction) instead of technical. For other projects, it is better to create partial models, for example just a throughput model for the server because that's what you are most worried might fail.
By rejecting Big Design Up Front and binders full of documentation, it's easy to add architecture to the agile ideas that are working for you, things like iterative development, test suites that enable refactoring, pair programming, etc.
InfoQ: Agile software development frameworks have built-in risk management in terms of daily iteration reviews, risk backlogs etc. How does that approach compare with risk-driven model you discuss in the book to manage software architecture?
George: At first glance, the book's advice on risk seems to be different than agile's advice, but they are talking about two different categories of risks. Agile is great at reducing project management risks, like the risk that you build the wrong thing or deliver late, but for engineering risks it mostly expects developers to bring their own skills to the party. So if you need your project to successfully handle UI, database, or architecture risks, your developers must have those skills. Extreme Programming has no advice about whether you should use a peer-to-peer architecture or a 3-tier one. What it does is sweep away a lot of management risk so that you can use your mad engineering skills without distraction.
The book describes a bunch of architecture techniques to make you a better developer. But if you tried to apply them all then you'd be back to Big Design Up Front, a bad idea. So it suggests the risk-driven model to help you apply the most valuable ones, then get back to delivering your system.
Agile, and specifically short iterations, help you discover problems early. Your customer will tell you sooner that your UI is unusable or (indirectly) that your database is slow. That benefit applies to your architecture too - you'll find out sooner that EJB or Hadoop is or is not working out.
InfoQ: You discuss various architecture styles in Chapter 14 (Architectural Styles) of the book. What are the styles and patterns that are more relevant in the architectural transformation happening in the new Cloud Computing era where applications (code and data) are hosted on an external system?
George: The most important thing to remember about architectural styles is that each of them is a ready-to-wear corset that helps your system achieve certain quality attributes. For example, pipe-and-filter networks enable re-configuration, peer-to-peer systems keep working when nodes appear and disappear, and map-reduce enables the parallelization of computation across commodity hardware.
There is a catalog of architectural styles (i.e., patterns) in the book and all of them apply to hosted computing environments like cloud computing. Renting rather than owning the hardware will likely change some of your design decisions, but it's too soon to report on that yet.
InfoQ: What do you think about the role that Domain Specific Languages (DSLs) can play in modeling and executing the software architectures?
George: Academics have been working with custom architecture languages for maybe 15 years. These languages, like ACME, C2, AADL, and SysML, allow you to express architectural concepts like components, connectors, and styles - things you cannot express directly in Java. These languages have mostly been used for modeling, though I know some people working on code generation from SysML.
However, most of us have already used a DSL for execution, like you suggest, though we probably never thought of it that way. When you write the config file for Struts or EJB, you are describing the topology of your system. That config file is actually a DSL designed by the framework author and developers use it to configure a running system. There are lots of systems that follow this pattern, where you write some modules / components in source code then describe how they are connected using an external config file.
InfoQ: How can the model you describe in the book be used to manage a Security Architecture program in an organization?
George: I'm not going to try to answer that one directly - you are the expert on security architectures, Srini! Instead, let me emphasize one of the messages from the book: Your model must be tailored to the problem. If you built a model to schedule a network of trains, could you re-use that model to calculate the depreciation of those trains? Probably not, and the same thing happens with software. If you build a model of your system that is useful for predicting latency of user requests, it probably won't help you discover security holes.
Engineers have been building models for a long time. Models by definition do not include all details. So, to avoid wasting time modeling, decide in advance what questions you want the model to answer, then you can build a model that helps you answer the question.
Software developers are, on the whole, pretty bright folks. But we are asked to work on problems that are much too big to fit into any developer's brain. The example of security is a good one: I don't think any developer can look at 10M lines of code and find all the security problems. But a model of that system can help. For example, a runtime view of the system makes it easy to see which services are accessible from outside a firewall, or you might create a custom view that shows request pathways so that you can search for ones that do not sanitize inputs. Models work by omitting details, making the problem small enough to fit into your head and reason about.
InfoQ: Any other thoughts or comments about the book and the current state of Software Architecture?
George: I miss the 1990's, not because the music was better, but because of the excitement about software design. Conferences were filled with developers learning about objects, design patterns, and design techniques. Bookstores (remember them?) were filled with books on the latest ideas about software design. But these advances were hamstrung by bureaucratic corporate software development processes. Enter the agile movement!
Today, the excitement is about agile development. Developers are focused on eliminating inefficiencies in their software process. They have moved to short iterations, regression test suites, and pair programming. Thank goodness! They seem to have studied the software design lessons from the last decade, though, sadly, I do run into a fair number of people who don't know their design patterns.
Roughly speaking, software gets about 10x bigger each decade. So while our attention has been focused on fixing process problems, our software got an order of magnitude bigger. The documentation for .Net is, no joke, bigger than the Encyclopedia Britannica. The pain caused by poor design is magnified by scale, so a poorly designed 10MLOC system is more than 10x harder to handle than a 1MLOC system. And guess what - software will be bigger again next year!
In my opinion, it's time to turn our attention back to design. Software frameworks dominate the land like giant predators and developers struggle to stay alive. Internet scale systems with their challenging engineering, once the curiosity of a few Bay Area companies, are commonplace. I'm looking forward to reading all those new design books.
InfoQ: Thank you for your time with this Q&A interview. Final question, what are your favorite technical and non-technical books?
George: Rather than running down the classics that everyone knows about, let me suggest two books that have had a big impact on me but are not widely read anymore. The first is Smalltalk Best Practice Patterns by Kent Beck. He sat down and reflected on how he wrote classes, methods, and variables. He describes it to us as a set of patterns that describe his thinking process, so in a way you get to be inside Kent's head while he's programming. A friend of mine joked that the name Smalltalk was keeping this book down, and he was going to rewrite it as Java Best Practice Patterns because the concepts apply just fine.
The second is the Catalysis book by Desmond D'Souza and Alan Wills. The sheer size and depth of this book is daunting, and its use of careful specifications scares off many readers. I don't currently write the kind of pre and post-conditions described in the book, but I find that *thinking* about those contracts makes me write better code. The book has helpful advice on software design issues ranging in scope from methods, to frameworks, to components.