We Stopped Building Everything: Abstraction Ate Software Architecture
Chapter: How the software architect role changed over time
Grady Booch discusses the idea that the history of software engineering is a story of rising levels of abstraction. Programmers keep pushing work down into tools so they can spend more time on bigger ideas and problems. This concept clicked with me because it describes how I have actually built software. Not a lot of architectural decisions are made from scratch these days. Most of the things engineers used to design by hand have been turned into tools, which makes it easier to work with them and take on even more complex problems. Tools like languages, frameworks, and cloud services have made a lot of things easier. First, I discuss how Booch describes this shift, then I show it in my own work, and finally I connect it to David Garlan's 2000 roadmap for software architecture.
Throughout the video, this shift in architectural decisions is traced by Booch. In the early era of programming, developers focused heavily on algorithms, making them more efficient while using expensive machines to their fullest. In the 80s, object-oriented programming gave developers new ways to organize code, like classes. This made work easier since they no longer had to deal with one long program but could instead treat it as a cluster. Today, as Booch mentioned, a small team of developers can pull in cloud services, hosting, authentication, databases, messaging services, etc., all at once without building any of it. These pieces are sold as services. So the problem switched from how to build to how to piece everything together. As he said, the architect's job has become more economic.
I experienced this kind of change while building a product called Airstitch. We were a tiny team trying to build a useful product as soon as possible. I did not write or design any of the bigger systems like authentication or message queues. Instead, I was weighing one existing tool or service against another and connecting them to fit my needs. I still had to design the entire flow of how each service interacted and how everything worked in the background, away from the eyes of the users. It is safe to say that this kind of switch in architectural planning has saved a lot of time, but it has not made everything child's play. The thinking part of a product still needs to be done carefully.
In "Software Architecture: a Roadmap," David Garlan wrote about where the growing field of software development was heading and about the changing balance between writing software and reusing software developed by other companies. He mentioned that the need to deliver products faster and cheaper has pushed developers to assemble existing systems instead of constructing each one themselves. This has shifted the architectural work towards integration [1]. He was able to see and project all this back in 2000. Looking at the current stage of software development and everything this article pointed towards, we can easily see most people doing these things nowadays.
Another topic Garlan discussed in the article that caught my eye was the concept of "self-monitoring systems" and his insight that it would be an important research direction [1]. This trend feels very realistic and almost in sight now with the growing age of AI tools. AI agents can now monitor production software, catch and fix failures, and create reports based on it. That future is very close. This is the same trend one level up. Maintenance itself becomes a layer the architect configures instead of performs.
Based on what Booch addressed, no single language or framework is the most important trend. Instead, it is the movement towards using all these as layers to solve even more complex problems. As Garlan predicted, we have stopped actively building everything ourselves, but we have not stopped working on architecture and planning. It is the most influential trend because every later trend is another instance of it.
References
[1] D. Garlan, "Software architecture: a roadmap," in Proc. Conf. on The Future of Software Engineering (ICSE '00), Limerick, Ireland, 2000, pp. 91-101, doi: 10.1145/336512.336537.