Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Eliminate Architecture

09.09.2009
| 10093 views |
  • submit to reddit

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.

From http://techdistrict.kirkk.com/

Published at DZone with permission of its author, Kirk Knoernschild.

Comments

aaaaa aaaaaaaa replied on Wed, 2009/09/09 - 3:10am

Very interesting. In a 100% flexible system is very easy to make any changes, but very difficult to find the point of change due to the high complexity. So we should eliminate architecture, but not too much.

Pieter van der Meer replied on Wed, 2009/09/09 - 4:34am

I do agree to the point made in the article but with some remarks. The architecture (or design) stuff performed at the beginning is required see Fowler statement. But then you start talking about flexibility.
the problem in every application is the flexibility all the business wants is flexibel applications that can be change quickly. But when you ask about the flexibility required no answer pops to mind ;-).
In the designs I always start with no flexibility at all. (and yes by applying various patterns it is extensible). because of the extensibility of the architecture all required flexibility can be build later on. if time comes the new functionality is incorporated in the architecture.
With this you have a win win situation. The upfront design is simple and basic, it clearly defines the interfaces between the components/modules. Cause of the extensibility of the various modules we prepared for all flexibility without adding it to the design.

Alessandro Santini replied on Wed, 2009/09/09 - 12:40pm

Kirk,

I am not fully sure I have understood your point here.

First of all, I humbly disagree with the sentence "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." - this is, from my point of view, a very theoretical take at software development as it happens in the real world. 

The cost of a change in a software system is, as to my experience, given by the gap between the new requirement and the system as-it-is-now. The gap analysis will then tell you how many points of the system are affected and how complex/expensive (if feasible) changes would be.

Here, the software architecture enters into play. Each piece of design is a piece of architecture because you do not really know beforehand how radical the changes will be. And changes, even radical ones, do happen because of communication errors, mistaken assumptions and many other factors that characterise software development projects. I might also add that the cost of a modification to a system is function of time as well because, as project progresses, the cost of a change will become increasingly expensive.

What you are suggesting here is to eliminate (a far more suitable but less catchy verb would be to reduce) architecture by means of SOLID principles, modularization and joints. The foremost and perhaps most stupid question that comes on top of my head is "are we really reducing architecture here?" - and the most immediate answer is "no".

No,  because - again in my humble opinion - you are not getting rid of the architecture; you are instead making assumptions based upon an existing infrastructure, therefore based upon an existing architecture.

I do agree that OSGi and friends may yield a lot of benefits from this perspective, but I do not think that will be the silver bullet and I more importantly believe this will not prevent the over-engineering phenomena that we all witnessed in the JEE world from happening again.

Ciao,

Alessandro

Ronald Miura replied on Wed, 2009/09/09 - 2:32pm

"Modularity combined with design patterns and SOLID principles, represent our best hope to minimize the impact and cost of change, thereby eliminating architecture."

Isn't "modularity combined with design patterns and SOLID principles" architecture?

And architecture is not about cost of change only.

Twitter's and Google's architectures are the way they are because they have a requirement of enormous scalability. Many (mostly non-funcional) requirements must be considered by the architecture.

Performance, scalability, security, safety, flexibility, maintainability. Whenever you think about how these issues are handled across your application, or across a set of applications, you are thinking architecture, writing it down in a document or not.

The moment you chose a programming language, you defined one architectural aspect of your application.

"Architecture is about the important stuff. Whatever that is."

Mladen Girazovski replied on Thu, 2009/09/10 - 6:36am

Nice Article (as usual), i can agree with it.

The "Big Design Upfront" leads to an overengineered architecture, which makes the project inflexible and increases the effort to change and thus the cost of change.

Things always change, so, if we assume as little as possible about the future of a project, we end up with as little architecture as nessecary, therefore being as flexible as possible.

 Architecture is the summ of all important decision,architecture offers options , but at the same time it limits them.

Alessandro Santini replied on Thu, 2009/09/10 - 7:43am in response to: Mladen Girazovski

Things always change, so, if we assume as little as possible about the future of a project, we end up with as little architecture as nessecary, therefore being as flexible as possible.

I honestly fail to understand, beyond words, where is the break-even point between flexibility and assumptions.

As I have already said, regardless we make assumptions or not, we do not know how things will change and there is simply no way to protect design decisions from being challenged over time. As such, I still believe that any design decision taken during the development of a software system is an architectural point and that you end up having a full-blown architecture in place.

I also fail to understand how modularization will solve the problem of over-architecturing: we will then have the problem of over-modularization.

Bruno Vernay replied on Thu, 2009/09/10 - 8:25am

You are playing with the definition of Architecture and give it a catchy title. Funny, but doesn't help.

Bruno

 

Mladen Girazovski replied on Thu, 2009/09/10 - 8:41am

I think K.I.S.S. would be  another way to explain that, any Design/Architecture that is sufficient to fullfil the current requirements (and only them) is the way to go for maximum flexibility.

I have worked in a couple of JEE Projects (EJB 2.1  ), where the architecture was set mostly from the JEE Patterns catalog, none of those projects was ever run in a cluster, but the limitations imposed by the architecture of such a system were slowing down our development, the chance to use the options that such an architecture offered and, thus the benefits did never  come into play.

I agree that this isn't just a J(2)EE issue, the same happenend in my last SpringDM/OSGi Project,  in the end it could have been implmented as a standard Java WebApp, without a lots of hassles.

I think the problem of overengineering is completely ingorant to the technology used, it depends on the ratio of Requirements and the Architecture to fullfill them.

Of course i doubt that the statement "eleminate architecture" was meant as "eliminate all architecture", my guess is that it's about "eliminate big design upfront".

As for Design vs. Architecture, Design is Architecture on a lower level, i can have Design that does not represent Architecture as Design can be hidden in Details that do not show up in public interfaces.

Alessandro Santini replied on Thu, 2009/09/10 - 9:03am in response to: Mladen Girazovski

"I think K.I.S.S. would be  another way to explain that, any Design/Architecture that is sufficient to fullfil the current requirements (and only them) is the way to go for maximum flexibility."

Do not get me wrong - nothing personal here but I still do not agree with this statement. The KISS principle is in my opinion the way to maximum productivity, not flexibility; I also acknowledge that the KISS principle may work in a substantial number of small-medium sized projects, but I would stand very clear from defining it an universal principle.

I have seen too many times designs that were absolutely fit for the prototyping phase or for the initial use cases. Uses cases have then evolved or new ones have emerged - eqiplogue was that many times the initial, KISS-compliant design simply did not cater for the new requirements and a substantial, expensive rework was instead needed.

Erin Garlock replied on Thu, 2009/09/10 - 10:47am

It's been touched on by others here, but flexibility for change is not always a requirement and in cases is something to be avoided.  it has to be asked, "Are we going to ever change this, and if so what is the current cost versus the future cost?"

I can make something infinitely flexible and it will take an infinite amount of time to create.  There is always a tradeoff.  Many of these trade offs are discussed in the perspective of project management and fiscal management.  Theory is nice, but spending dollars to earn dimes is usually poor business.

Mladen Girazovski replied on Fri, 2009/09/11 - 3:08am in response to: Alessandro Santini

replying to wrong person, please ingore

Mladen Girazovski replied on Fri, 2009/09/11 - 3:09am in response to: Alessandro Santini

Well, i used K.I.S.S. as a another way to describe the opposite of "Big Design Upfront", but it still has to be S.O.L.I.D.

A "prototype" that does not comply to S.O.L.I.D. is just Quick & Dirty, that is not what i meant, and is something to be avoided.

 If you stick to SOLID and have enough tests, you can virtually refactor anything, and you can tell how long it will take. This is very different from the Q&D K.I.S.S. that you mentioned.

As a matter of fact, whenever Systems where build to be flexible, they ended up very complex, and in the end they were only flexible for changes that were foreseen, not the unexpected ones. In the latter case the complex systems where very inflexible after all...

Tim Boudreau replied on Sun, 2009/09/13 - 1:48pm

Interesting thought, but logical fallacy.  You can posit that architecture is correlated with inflexibility;  that does not mean that there is a cause and effect relationship - either architecture causing inflexibility, or inflexibility causing architecture :-)  It is entirely possible to have more- and less-flexible architectures for a given problem set;  and also very easy to create something with little discernable architecture which is also highly inflexible.

Architecture is a matter of interpretation.  If you give me a hunk of (perhaps obfuscated) source code with no documentation, and I analyze and come to understand it, my interpretation of what are the components of its architecture, and the roles of those components, may be completely different than the original author's understanding of them.  Yet if my understanding allows me to use the system effectively, it is equally valid.  The "architecture" only exists insamuch as it is a tool for communicating an understanding of the system, and a mental toolkit for conceiving the system.

I agree about modularity being important - I've been giving talks on the importance of modular *architecture* for years :-)  The fact is, the more modular the software, the greater the requirement for stable contracts - ahem, architecture - to enable the software to function, to allow components to be updated compatibly, etc.

-Tim

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.