My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox


March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture


July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response ( to the @mreinhold #jigsaw announcement ( 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

Eliminate Architecture

Filed Under Agile, Architecture & Design, Java, OSGi |  

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.


20 Responses to “Eliminate Architecture”

  1. JP Morgenthal on September 8th, 2009 8:28 pm

    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. kirk on September 8th, 2009 8:57 pm

    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. J. B. Rainsberger on September 9th, 2009 2:31 am

    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. Senthil Balakrishnan on September 9th, 2009 3:35 am

    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. whaaaaat? on September 9th, 2009 8:59 am

    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. eelco on September 9th, 2009 10:40 am

    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. Sridharan Srinivasan on September 9th, 2009 12:56 pm

    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. Software Architecture Defined | _mindMeld on September 9th, 2009 4:02 pm

    [...] link: Eliminate Architecture : Software & Technology [...]

  9. Michele Mauro on September 11th, 2009 9:00 am


    The approach you are describing isn’t something very similar to Dependency Injection?

  10. Scott Banwart’s Blog » Blog Archive » Distributed Weekly 14 on September 11th, 2009 1:42 pm

    [...] Eliminate Architecture ** [...]

  11. Agile Architecture Presentation : Software & Technology on September 11th, 2009 6:01 pm

    [...] Eliminate Architecture - Discusses the goal of architecture and how to eliminate the impact and cost of change. [...]

  12. Modularity & Architecture : Software & Technology on September 16th, 2009 4:36 pm

    [...] recently wrote about eliminating architecture, and there were a few comments, especially by folks on JavaLobby, who thought I had my head in the [...]

  13. Agile Architecture, Lean Principles : Software & Technology on September 22nd, 2009 7:45 pm

    [...] me, this captures the essence of eliminating architecture. If we are able to take a seemingly architecturally significant challenge and make it reversible, [...]

  14. The Use/Reuse Paradox : Software & Technology on October 7th, 2009 5:04 pm

    [...] knowledge to make the most informed decision possible. Because of this, we should strive to minimize the architectural significance (impact and cost) of change by making our designs as reversible as possible. Reversibility doesn’t always mean great [...]

  15. 3 Pillars of Architecture : Software & Technology on January 27th, 2010 4:42 pm

    [...] and for architecture to be effective, we must also be able to understand the architecture. In Eliminate Architecture, I cited a definition of architecture that introduces the social dimension. Architects signify the [...]

  16. Thomas J. Clancy on January 29th, 2010 10:30 pm

    Architects ‘design’. They don’t ‘architect.’

  17. Cory Casanave on January 31st, 2010 6:09 pm

    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.

  18. OSGi: Complexity is NOT the Problem : Software & Technology on April 15th, 2010 6:40 pm

    [...] Eliminate Architecture - Discusses the goal of architecture and how to eliminate the impact and cost of change. [...]

  19. Dan on February 24th, 2011 3:03 pm

    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.

  20. louboutin chaussures homme on April 1st, 2014 8:49 pm

    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

Leave a Reply