Home ›

Book chapter: Introduction to Software Architecture

Decade after decade, software systems have seen orders-of-magnitude increases in their size and complexity. This is remarkable — and more than a little scary for those of us who build software. In contrast, imagine how hard basketball would be if it scaled up the same way, with 5 people on the floor one decade, then 50, then 500. Because of this growth, today’s software systems are arguably the largest and most complex things ever built.

Software developers are always battling the ever-stronger foes of complexity and scale, but even though their opponent grows in strength, developers have staved off defeat and even reveled in victory. How have they done this?

One answer is that the increases in software size and complexity have been matched by advances in software engineering. Assembly language programming gave way to higher-level languages and structured programming. Procedures have, in many domains, given way to objects. And software reuse, which used to mean just subroutines, is now also done with extensive libraries and frameworks.

Download full article

Book chapter: The Risk-Driven Model of Software Architecture

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?

Download full article

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.

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.

Book chapter: A Conceptual Model of Software Architecture

When a coach and a rookie watch the same game, they both see the same things happening on the field, but despite the rookie’s eyes being younger and sharper, the coach is better at understanding and evaluating the action. As a software developer, you would like to understand and evaluate software as effectively as the coach understands the game. This chapter will help you build up a mental representation of how software architecture works so that when you see software you will understand it better and will design it better.

If you want to become as effective as a coach, you could simply work on software and wait until you are old. Eventually, all software developers learn something about architecture even if they sneak up on it indirectly. It just takes practice, practice, practice at building systems. Consider another path, one where you see farther by standing on the shoulders of others. Perhaps we are still waiting for the Isaac Newton of software engineering, but there is plenty to learn from those who have built software before us. Not only have they given us tangible things like compilers and databases, they have given us a set of abstractions for thinking about programs. Some of these abstractions have been built into our programming languages — functions, classes, modules, etc. Others likely will be, such as components, ports, and connectors.

Download full article

The Kitchen Drawer Problem

I’ve just had a rather enjoyable “refactoring session” with my book. At first, I had some good content sections lumped together into a catchall chapter — Working with Models. But, as the book fills out, it becomes easier to see where those sections should fit, so I was able to refactor the outline to introduce a new chapter on Encapsulation and Partitioning that will hold several of those sections.