- 3.1. Defining Architecture
- 3.2. A Software Architecture Story
- 3.3. The Goal of Architecture
- 3.4. Modularity: The Missing Ingredient
- 3.5. Answering Our Questions
- 3.6. Conclusion
- 3.7. References
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.2. A Software Architecture Story
The story of software architecture reminds me of the following story (Hawking 1998):
- A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever,” said the old lady. “But it’s turtles all the way down!”
- —A Brief History of Time by Stephen Hawking
Software architecture is “turtles all the way down.” How? This section discusses these ideas.
3.2.1. The Ivory Tower
Many of us can relate to the ivory tower. In dysfunctional organizations, architects and developers fail to communicate effectively. The result is a lack of transparency and a lack of understanding by both sides. As shown in Figure 3.1, architects bestow their wisdom upon developers who are unable to translate high-level concepts into concrete implementations. The failure often occurs (although I recognize there are other causes) because architecture is about breadth and development is about depth. Each group has disparate views of software architecture, and although both are warranted, there’s a gap between these views. The architect might focus on applications and services, while the developer focuses on the code. Sadly, there is a lot in between that no one focuses on. This gap between breadth and depth contributes to ivory tower architecture.
)
Adapted from http://www.rendell.org/jam/upload/2009/1/tower-12054835.jpg
Figure 3.1. The ivory tower (the Open Group)
3.2.2. Turtles and the Tower
Without question, the ivory tower is dysfunctional, and systems lacking architectural integrity are a symptom of ivory tower architecture. So, assuming good intent on the part of the architect and the developer, how can we bridge the gap between breadth and depth? How can we more effectively communicate? How do we increase understanding and transparency?
Let’s revisit the definition of software architecture by exploring another definition. My favorite definition of software architecture was offered by Ralph Johnson in an article by Martin Fowler (2003). He states:
- In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called “architecture.” This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers . . . Architecture is about the important stuff. Whatever that is.
The key aspect of this definition that differentiates it from the earlier definitions in this chapter is that of “shared understanding,” which implies that there is a social aspect to software architecture. We must have a shared understanding of how the system is divided into components and how they interact. Architecture isn’t just some technical concept; it’s also a social construct. Through this social aspect of architecture, we can break down the divide between architects and developers.
To ensure shared understanding, we have to architect “all the way down.” Architects cannot worry only about services, and developers cannot worry only about code. Each group must also focus on a huge middle ground, as illustrated in Figure 3.2.
)
Figure 3.2. Architecture all the way down
Focusing exclusively on top-level abstractions is not enough. Emphasizing only code quality is not enough either. We must bridge the gap through other means, including module and package design. Often, when I speak at various conferences, I ask the audience to raise their hands if they devote effort to service design. Many hands raise. I also ask them to raise their hand if they spend time on class design and code quality. Again, many hands go up. But when I ask if they also devote effort to package and module design, only a small percentage leave their hands raised.
This is unfortunate, because module and package design are equally as important as service and class design. But somewhere along the way, with our emphasis on services and code quality, we’ve lost sight of what lies in between. Within each application or service awaits a rotting design, and atop even the most flexible code sits a suite of applications or services riddled with duplication and lack of understanding. A resilient package structure and corresponding software modules help bridge the divide between services and code. Modularity is an important intermediate technology that helps us architect all the way down and is the conduit that fills the gap between breadth and depth.
We need to focus on modularity to ensure a consistent architecture story is told. It is the glue that binds. It’s the piece that helps bridge low-level class design with higher-level service design. It’s the piece that helps bring down the ivory tower, enhance communication, increase transparency, ensure understanding, and verify consistency at multiple levels. It is the piece that allows us to “architect all the way down” and allows us to realize the goal of architecture.