Eliminate Architecture

I believe:

The best way to deal with architecture is to eliminate it.

Architecture’s Goal

Let’s start at the beginning. First, by defining architecture. Second, by understanding the goal of architecture. I’ll offer two perspectives, one from Fowler and the other from Booch. First, the Fowler statement.

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.

Now Booch says:

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

Examining these two statements is very revealing. Fowler makes it’s apparent that architecture is about the important stuff, while Booch is clear that something is architecturally significant if it’s difficult to change. Therefore, I’ll conclude that the goal of software architecture must be to eliminate the impact and cost of change, thereby eliminating architectural significance. And if we can do that, we have eliminated the architecture.

Eliminating Architecture

The Paradox

The idea behind eliminating architecture isn’t new. In fact, Fowler mentions “getting rid of software architecture” in the article linked to above. And the way to eliminate architecture by minimizing the impact of cost and change is through flexibility. The more flexible the system, the more likely that the system can adapt and evolve as necessary. But herein lies the paradox, and I’ll use a statement by Ralph Johnson to present and support the idea.

making everything easy to change makes the entire system very complex

So as flexibility increases, so too does the complexity. And complexity is the beast we are trying to tame because complex things are more difficult to deal with than simple things. It’s a battle for which there is no clear path to victory, for sure. But what if we were able to tame complexity while increasing flexibility? Is it even possible? In other words, how do we eliminate architecture?

Maximize Flexibility, Manage Complexity

Eliminating Architecture

As the Johnson quote clearly points out, it’s not feasible to design (or should I say architect?) an infinitely flexible system. Therefore, it’s imperative that we recognize where flexibility is necessary to reduce the impact and cost of change. The challenge is that we don’t always know early in the project what might eventually change, so it’s impossible to create a flexible solution to something we can’t know about. This is the problem with Big Architecture Up Front (BAUF), and it’s why we must make architectural decisions temporally. It’s also why we must take great care in insulating and isolating decisions we’re unsure of, and ensuring that these initial decisions are easy to change as answers to the unknown emerge. For this, modularity is a  missing component that helps minimize the impact and cost of change, and it’s why agile architecture requires modularity.

In the UML User Guide (P. 163), Booch talks about “modeling the seams in a system.” He states:

Identifying the seams in a system involves identifying clear lines of demarcation in your architecture. On either side of those lines, you’ll find components that may change independently, without affecting the components on the other side, as long as the components on both sides conform to the contract specified by that interface.

Where Booch talks about components, today we talk about modules. Where Booch talks about seams, I talk about joints. Modularity combined with design patterns and SOLID principles, represent our best hope to minimize the impact and cost of change, thereby eliminating architecture.

21 thoughts on “Eliminate Architecture

  1. The very distinction that one is drawing lines of demarcation that will become boundaries around components is architecture. It requires and architect to decipher where those boundaries should be and what they should be for maximum applicability of the source toward future domain problems that are not known at the time of development. What’s missing from your definitions of architecture is that the architect provides a vision for how all the pieces will fit together. This is a very developer-centric view of architecture, which ultimately, will drive an endless cycle of development without vision.

  2. Hey JP,

    Keep in mind my intent is to define the goal of architecture and to explore how to realize that goal through flexibility while managing complexity. I don’t consider the role of the architect part of this definition, and I want to be careful in using words such as “vision” because it suggests “up front”. I recognize the importance of establishing some direction early, while acknowledging that we must be willing to accommodate the inevitable shifts that will come our way. That is the goal of architecture – to minimize the impact and cost of change. IMHO, that is the role of the architect.

  3. In the presence of high modularity, architecture simply becomes design-in-the-large. I use the four elements of simple design to guide my code to high modularity, by decreasing coupling and increasing cohesion.

  4. In my view, As an architect we do make choices based on the business goals and challenges, that doesn’t mean it is rigid it’s always bound to change. The core of were the solution is heading towards will be lost if we eliminate architecture effort.

  5. Like Limp Bizkit puts it: “You can’t take the edge off the knife”.

    Every system has an architecture – documented or not. Therefore you can’t eliminate it without eliminating the whole system.

    Architecture is defined by design decisions that are difficult to change. It is driven by functional and non-functional requirements, constraints and the overall product vision. It’s all about tradeoffs and balancing competing stakeholder wishes.

    When building any moderately complex system you need to consider architectural issues. Great architects are masters of organizing development so that as many people as possible can positively contribute (if needed). Usually this means at least modularity, well-thought interfaces, low coupling, agile documentation, visualization, efficient communication and leadership & management skills.

    Personally I absolutely do NOT believe in chaotic “design by committee” type solutions where there is no clear design lead or any focus on architectural planning and design. I do not believe in do-it-alone “ivory tower” architects either but there has to be someone who is the technical lead. Just like there is someone responsible for the product vision and priorization (the Product Owner).

    It’s funny that the word “upfront” is nowadays a dirty word. As if you weren’t allowed to think anything up front. “Just sketch 5 mins on a napkin and start coding.”. That’s just damn stupid and expensive.

    It’s not a choice between everything or nothing up front. It’s about doing _enough_ upfront design and planning and revising things along the way. Extremes are generally harmful.

  6. Nice post. #subscribe.

    In a way, as an architect i try to create ‘containers’ for which i should not really care anymore how good or how bad the solution will be. Just tell the team: do what you like, but these are the boundaries. (Of course that does not always work that way – once the big picture is clear, the details become interesting).

  7. Nice Post which exactly mirrors my current experimental/research work.

    It is already well known that Low Coupling (Zero Coupling?) leads to flexible system. It is also well known that High Coupling leads to Complex and Unmanageable system.

    If we can separate coupling as Meta Data (your concept of Joints) from components/modules and have a Assembler framework which combines the Coupling Metadata and the Components/modules to realize a system, maybe we can increase the flexibility of the system, but at a reduced complexity.

    The interesting thing I found was that having a simple 4 step Language of Assembly (Joints Meta Data) namely, 1) Specify a Context, 2) Specify Context Components 3) Configure Context Components and 4) Link Context Components lead me to in theory to assemble any application from discrete components.

    I started working on such a system in my free time, to find out whether separating Assembly from coding will lead to reduced overall complexity or not.

    Still experimenting, my first experiments were on a proof of concept to build a website which just validates my Language of Assembly.

    Currently working on using the Assembly Framework (Experimentally/Personally only) on a large Enterprise Application in my Job to find whether it really reduces overall complexity or increases complexity.

    Will Assembly Oriented Software Development give the benefit of Flexibility at reduced complexity similar to Car Manufacturing?

  8. It seems to me you are missing the point of architecture – which is to achieve something. I would add to J.P.’s initial statement and say that “the architect provides a vision for how all the pieces will fit together to form a system that fulfills some purpose”. What architects architect are systems –organizing complexity for a purpose.
    By definition a system is an organization of parts and their relationships that act as a whole. The purpose of architecture is then to create these systems such that they fulfill some purpose. This notion of systems and parts is modular (the parts), so modularization is an essential component of architecture – so yes, the “joints” are critical. Cost, flexibility and effectiveness of the system are design goals that any architect must balance but not the reasons for architecture.
    Whenever we are creating any kind of system – from a program algorithm to an enterprise SOA to a building we are architecting. It is the essential human act of creating, rather than just responding to, our environment.
    So perhaps it is better to look at all phases of architecture: in I.T. systems this includes the developer, the systems architect and the business architect. Our goals should be to better join the various architectural disciplines to they work together more effectively in creating our world.

  9. Simplistically, the results of architecture are “ilities” (ideas about behavior of a “system” — broadly speaking). Design employs a variety of potentially functionally equivalent methods and inventions to purposefully assemble resources to implement these behavioral ideas. To that extent design is a focus on architecture; it is not the same as architecture. Unless…there are no expected behaviors. If the designer disavows any particular set of behaviors, the designer can then say the design has no purposeful architecture beyond what emerges from the will of the designer. If there are no overarching behavioral expectations for the “system,” the designer will exercise no creativity in avoiding unintended behavioral results. Designers who try to eliminate (behavior oriented) architecture create “accretion architectures.” The world is full of examples: strip malls come to mind. IT has its strip malls: stovepipes.

  10. hey there and thank you for your info – I’ve definitely picked up something new from right
    here. I did however expertise several technical points using this web site, as I experienced to reload the
    site a lot of times previous to I could get it to load properly.
    I had been wondering if your web hosting is OK? Not that I am
    complaining, but slow loading instances times will often affect your
    placement in google and can damage your high-quality score if ads and marketing with Adwords.
    Well I am adding this RSS to my email and could look out for much more
    of your respective intriguing content. Make sure you
    update this again very soon.

    louboutin chaussures homme

  11. In recent years, the most active in the field of consumer electronics, one of the most talked about product categories comes as cell phones, mobile phones and mobile phone related accessories protective shell areas are also of concern, although they do not have phones ‘out of place

Leave a Reply

Your email address will not be published.