Postmodern Software Architecture

"Postmodern Project Management," an article released in Defense AT&L in May of 2008, makes a convincing argument for why modern project management philosophy fails to help projects reach success [1]. As software architecture is largely a tool to facilitate communication and provide guidance for a project, it is not difficult to see parallels between current and emerging trends in software architecture with the idea of modernism vs. postmodernism project management practices. Tell me if these sentiments don't ring true for the upfront vs. emergent design approaches.
Modernism is indeed an effective approach for a rational, static world where surprises are rare, measurements are precise, humans are tools, and our understanding of the system dynamics is very nearly complete. If the PM's world was linear and predictable, then Modernism would work just fine. But the reality is, reality is messier than that. Things change unexpectedly, surprises surprise us, people are people, and the system dynamics are both unstable and nonlinear. In this sort of environment, Modernism breaks down.
Modernist project management refers to taking a rational, calculated, purely scientific (some might say cold) approach to managing people and projects. By extension, modernist software architecture approaches designing a software system in a similarly rational, calculated, and scientific way. The object of modernist software architecture is to create a process by which great software architecture designs can be consistently and predictably repeated by any team working on any project. The best example of modernist software architecture comes out of the excellent work and research from Software Engineering Institute.



Postmodernist software architecture on the other hand aims to inject some humanity into how we approach the architectural design and ultimately implementation of a software system. In other words, postmodern software architects acknowledge that no matter how much we plan or how good our models are, we can't predict everything as the modernist software architect attempts to do [1].
For us normal folks, [Postmodernism] can be understood as a worldview that is skeptical of Modernism's certainties. Postmodernism doesn't necessarily deny Modern certainties—it just questions, examines, and deconstructs them, investigating the underlying assumptions, particularly when those assumptions are flawed, hidden, ignored, or otherwise not made explicit.
Historically most software architects (and developers in general) tend to approach the design of a complex system in a rational, linear way:  first you gather requirements, then you create a model (which precisely defines the solution), then you verify your model before finally starting implementation. In my experience this approach works extremely well - until things change (and change they always do). Models are imprecise by their very nature and it's easy to forget important details or get details wrong. Changes happen throughout the life of a project – requests from customers, risks becoming problems, even changes you would have never expected.

When changes happen, the modernist approach to software architecture crumbles. All that documentation, all those models, all that analysis – these carefully laid plans become not only useless but also a burden and a resource drain. Over time systems built by relying too heavily on models constructed through a rational process become rigid and the quality decreases. This is not to say that models are bad. When dealing with something as abstract as software architecture models are essential. It's how the models are created and how we use them that make postmodernist software architecture work better.

Change is an opportunity to deliver even more value to customers and users. Postmodernists react with confidence and excitement (and a healthy dose of skepticism as any architect modernist, postmodernist or otherwise should before evaluating trade-offs) where modernists react with pessimism, frustration, and disappointment. But lightweight representations are only part of the story. By recognizing that people are not interchangeable and that all humans are inherently flawed, postmodern architects naturally tend to design systems that are more flexible, testable, and maintainable. By not only allowing change but embracing and encouraging it, architectural drivers can evolve and converge more rapidly, actually shortening the "period of uncertainty."

Faith in the power of individuals and accounting for their humanity is what makes postmodern software architecture so powerful. No amount of up front system analysis will ever change human nature.  And as architects we can never forget this when designing systems.

[1] Maj. Dan Ward, USAF, Maj. Chris Quaid, USAF, and Capt. Gabe Mounce, USAF, "Postmodern Project Management"Defense AT&L: May-June 2008.  [Being a defense journal it's no wonder that I missed it (thanks to the Rogue Project Leader for pointing it out!)]

Comments

  1. Thanks for the post–this seems to be a useful way of characterizing the evolution of software engineering and software architecture.

    Thanks also for your reference to the SEI. Current work in software architecture at the SEI is also moving in the direction of post-modernism. See, for example, our work in ultra-large-scale systems (http://www.sei.cmu.edu/uls) and Agile architecture (http://blog.sei.cmu.edu/post.cfm/developing-an-architecture-focused-measurement-framework-for-managing-technical-debt; http://www.sei.cmu.edu/architecture/research/archpractices/Agile-Architecting.cfm; http://saturnnetwork.wordpress.com/category/from-the-trenches/)

    Regards,
    Bill Pollak

    ReplyDelete
    Replies
    1. Bill, these are some excellent resources, thank you for sharing the links. I have been following Ipek Ozkaya’s, Nanette Brown’s, and Robert Nord’s recent work on Agile and architecture with great interest and I look forward to even more insights from the SEI architectures team!

      Delete

Post a Comment

Popular posts from this blog

Managing Multiple Ruby Versions with uru on Windows

Dealing with Constraints in Software Architecture Design

Architecture Haiku