Why Worry About Architecture

One of the arguments against lightweight processes is that they will evolve "bad" architectures.

In the architect space of a solution there will be a continuum of architectures from poor to adequate to excellent. How do you tell where your system lies on that continuum?

Is it better to just get on with it and let the architecture evolve or to specify the architecture first?

Bear in mind that this decision might be forced by other considerations. For example, choosing an application server for one particular feature will often force your hand in implementing other features.

How good the design is doesn't matter near as much as whether the design is getting better or worse. If it is getting better, day by day, I can live with it forever. If it is getting worse, I will die. --KentBeck (from XpMailingListQuotes)

What I am getting at is that in my business area, for example, there are a number of different approaches. Monolith on the mainframe, two-tier, three-tier, multi-tier, message based, RPC based (haven't seen an EJB one yet, I expect there is one though). All of them run and make money for the business. Some are a dog to manage, most look great from the outside and cruddy from the inside.

If I were building a new one should I spend a long time deciding which architecture to go for or should I just do what I know 'cos there is no real way to tell if I made a bad architectural choice. Even if the project fails it will probably be because of other reasons (probably the development process getting out of control).

Is Architecture as important to project success as people and process? --TomAyerst

Example: Emacs contains a very important architectural decision: the decision to write most of it in its own Elisp. It is unclear how such a major architectural decision could have followed from an evolutionary process.

But it did! Emacs began life as some simple macros in the Teco editor (which itself had grown by accretion until it was Turing Equivalent), which refreshed the screen after each change rather than waiting for an explicit refresh command. It grew in complexity in an evolutionary way starting from there.
Eventually Stallman rewrote it from scratch, and chose Lisp as the extension language rather than the previous (horrendous) Teco. Given Stallman's environment at MIT, Lisp was the inevitable choice. However, since it had always had an extension language, and had always been implemented primarily in the extension language, changing extension languages was also evolutionary, albeit a sharp change that left us all with tons of non-working macros (like my Teco macro that animated an ASCII stick-man juggling three balls :-) -- DougMerritt
P.S. This touches on something else: it's been observed that both Stallman and BillJoy had major impacts by massively improving or even rewriting existing software systems, but neither of them ever successfully started a software project absolutely from scratch (consider e.g. TheHurd?). I believe in architecture, but it's undeniable that some of the most successful ones were evolved architectures.

It depends what the requirement was? Was it 'I want a highly configurable text editor'? I can certainly imagine an editor starting with a fairly simple config file that then evolved into a sophisticated configuration language (probably not elisp though).

Would choosing a different language been a different architecture?

That's an interesting example, because in some sense it did follow from an evolutionary process. The original Emacs was a set of TECO macros, and only after exhausting the possibilities of that approach was the decision made to rewrite it based on lisp. See for example http://www.base.com/gordoni/web/tcl-rms.html

The conclusion might be that if you have unlimited time, architectural decisions don't matter because you can always revisit them later. I'm not sure whether there are any useful lessons here for projects with limited time. Find an architect who's done it already? --DanBarlow

Is Architecture as important to project success as people and process? --TomAyerst

What a great question! Here's another one I like: "Are architecture and process as important to project success as people?"

Architecture and process in a vacuum are nothing. A perfect architecture that no one understands is worthless, as is a perfect process no one can follow. The BigBallOfMud "architecture" is common enough to demonstrate that adequately functional systems can exits and be very unattractive to maintain. Similar argument applies to chaotic processes. I believe the main thrust behind architecture and process improvements are motivated by the desire to do better with the nonfunctional requirements of systems. Good architectures and good processes have to be designed to take care of those who build and maintain the systems, and that clearly subordinates them to the people on the project.

--WaldenMathews

Even GradyBooch himself admits "one of the dirty little secrets of software engineering: People are more important that any process." I am in emphatic agreement. But he goes on to say (and I would also tend to agree) that "Good people with a good process will outperform good people with no process every time." ObjectSolutions, p.188. --RandyStafford

Good architectures and good processes have to be designed to take care of those who build and maintain the systems, and that clearly subordinates them to the people on the project.

Then again, the architecture defines the programming skills needed for a project. You can then select the people who have the needed skills. You may need COBOL skills for the mainframe part, Oracle skills for the database part, etc. That clearly subordinates the people to the architecture.

Also, a good architecture can make a team of programmers better than the sum of individual members. We use a 3-tier architecture and have been able to move functionality between the VB front end, C++ middle tier, and Oracle stored procedure back end. Clearly this architecture has given us solutions that individual programmers could not.

Likewise, a poor architecture can sink even the best programmers.

-- WayneMack

For example we have a 3 tier architecture where bottlenecks move from tier to tier. functionality has been developed on the wrong tier several times because of time constraints. We cannot move the developers because they don't understand the technology of the other tiers.

I' m not certain if the above comment is agreement or disagreement. Yes, in a three tier architecture, you can pay a performance penalty for bad choices in functional allocation. You will also make bad choices for a variety of reasons: schedule, available manpower, ease of update, lack of knowledge, developer ego (I can do that by myself), etc. The point is you can make some of these trade-offs up front and can repair some of the affects later.

The key point is communication. No, you often can't move the developers to a new tier, but you can move the knowledge. What you can take advantage of is flexibility, you can trade-off a less than optimal solution based on available resources, and you have more approaches to fix poor decisions. To be able to use this flexibility, you must have good communications and a team approach across tiers.

-- WayneMack

Wayne, I see your point above, in which you buy architectural freedom through the selection of different people. I never got to do that, so I can't really comment on it, but I have a deep intuition that anytime you really subordinate people to architecture (or process), you have created a problem. Your second paragraph is more like what I was getting at, but you've taken it even farther, which I like. I was saying "build the organization around the people" -- you're saying "choose synergizing architectures (and processes, by extension)", which is even better.

--WaldenMathews

Hoo, boy! I certainly worry about architecture, since I have seen some very cool-looking projects die a horrid death for lack thereof. I have also been able to take some dogs and create a new architecture for them that brought them out of the doghouse. Architecture is more than just a buzzword; it is a unified approach to solving a system requirement that integrates the thinking about a problem. This Wiki is full of people who are JustaProgrammer and don't think about overall solutions. When one is charged with finding "the solution" one is required to think in these terms. The ability to share that vision is a primary separator between mediocre architects and superlative ones.

So you are saying that correcting the architecture after the initial development is a good way to improve the software ("[bring] them out of the doghouse") and that if the architecture going in exhibits problems, then it needs to be corrected during the development effort to succeed (to avoid "[dying] a horrid death"). This seems in agreement with the approach of addressing architecture problems as they arise, i.e., evolving architecture.

No. That is not what I said and not what I implied. The bow-wows I was referring to had to be recoded from scratchola because the code simply didn't fit into any architecture, and certainly not the one I came up with after analysis. New architecture does not necesitate new code, but that is the most likely outcome.

Take a look at WhatIsArchitectureAnyway for a clean definition of architecture so that we can sing from the same hymnal.

Contributors: TomAyerst, WaldenMathews, WayneMack, MartySchrader, DanBarlow, RandyStafford

CategoryArchitecture