The executives and sales reps faced an unpleasant task with regard to their flagship product: explaining to their installed customers that they would need to replace their workstations with more powerful ones just in order to install the forthcoming upgrade to the software. The cost of installing the new version of the product endangered the company's very existence. That the company, Mentor Graphics, survived the damage is a story unto itself [5], but it is not the story of this article.
This article is about strategies for evolving software architectures in tandem with business revenue. I will discuss the tensions between simplistic, simple, and complicated designs for the architecture1 and how those tensions are influenced by the architect's professional ambitions....architectures do affect the business bottom line, and it does matter how they are implemented.
Text Here are three case histories to get us started:
(Unhappy) Case 1 (above): The architects chose to replace the product infrastructure with object-oriented C++ code within a single version change. That move nearly broke the company. The architects in Case 1 nearly bankrupted their company with their architectural decision.
(Unhappy) Case 2: The architects promised their executives that their radically new architecture would allow direct translation from use cases to running Java code, making the product incredibly nimble with respect to changing needs. Rather than use the lower-risk strategy of getting a simple architecture to work first and then incrementally rearchitecting it (the general recommendation of this article), the project manager chose to hang all hopes on the new architecture. That turned out to be too hard to implement in practice, and no product was shipped at all.
If the architects in Case 2 had pulled off their dream architecture, their company would have been in a great business position. Instead, the company ended up with no product to sell.
(Happy) Case 3: The architects created and delivered their first running system after three months, using a fairly simple design. They followed that by delivering a new version every three months, modifying the underlying architecture to follow the business's changing technological preferences and vendor affiliations. Over a three-year period, their product moved from being a splinter activity to being a strategic product. The architects in Case 3 delivered a saleable product with a simple architecture and then updated it fast enough to follow the business needs each quarter.
I'M BEGINNING TO SEE A PATTERN ...
These cases reveal a noteworthy success strategy (aka design pattern) that I periodically encounter in my project debriefings: Incrementally Rearchitect from a Simple Initial Architecture. This design pattern/strategy, based on the more general Incremental Rearchitecture pattern [2], recommends that you start with a simple initial architecture that delivers a usable product, then incrementally modify the architecture to extend its capabilities as the limitations become evident and as the business situation changes.
We'll look at the pros and cons of the Incremental Rearchitecture strategy in a moment, but first we need to note that like any useful strategy, it admits of overzealous misapplication, as in the next case history.
(Not Fully Happy) Case 4: Using Extreme Programming (XP), the contractors told the architects at the client company that they didn't want to hear about all the interfaces that had to be put into the new system. "You aren't gonna need it" (YAGNI) is the rallying cry that drives simple design in XP. The client architects watched in frustration as the contractors created one overly simplistic design after another, slowly picking up the requirements that were known well in advance and changing the architecture to fit each one.
The project cost extra money and caused frustration because the designers did not pay attention to known "No, I am gonna need it!" (NIAGNI) requirements.
'TIS A GIFT TO BE SIMPLE (BUT THERE'S NO GLORY IN IT)
The cases above illustrate the theme: architectures do affect the business bottom line, and it does matter how they are implemented.
Simple, implementable architectures earn business value early and usually can be restructured over time using normal business value principles. Overly simplistic architectures can cost the business extra money; overly complicated ones can sink products and even companies [4]. In other words, simple, rearchitectable architectures generally are a better business proposition than their complicated, forward-looking counterparts.
I have been using some loaded terms so far; namely, simplistic, simple, and complicated.
Saying that an architecture is simplistic implies that not only is it simple but also that it won't really work in the target setting. Such architectures are usually the result of people not understanding the problem at hand or not having adequate facility with the technology in use. In other words, calling an architecture simplistic implies that it is inadequate.
Saying that an architecture is simple implies both that it is easy to implement and understand and that it works for the assignment at hand. Generally speaking, "simple" tends to carry with it some worry about the future scalability of the design.
Saying that an architecture is complicated implies that it is more complex than really necessary; it has an "accidental" rather than an essential complexity. This type of architecture is both harder to implement and harder to understand, and thus it is more costly -- and possibly risky -- to the business than it should be. Arguments rage over whether any given architecture is simplistic, simple, or complicated, and I won't attempt to deal with those arguments here. What I wish to highlight is that architects use very different lines of thinking in pursuing these very different strategies.
Architects creating a complicated architecture do so with a deliberate strategy in mind: to understand future needs in such a way that incorporating unanticipated changes turns out to be natural and inexpensive. As one noted architect boasted (paraphrased here, since I can't find the original quote), "I haven't been there for over a year, and they have been able to incorporate changes to the system that none of us foresaw a year ago, without changing the architecture." The epitome of this architectural approach is getting it "right," which means not needing modification over a long period of time.Architects creating a complicated architecture do so with a deliberate strategy in mind: to understand future needs in such a way that incorporating unanticipated changes turns out to be natural and inexpensive.
Text A good, complicated architecture is immensely hard to come up with. Achieving one gives the architect tremendous bragging rights, along with peer admiration and professional promotions. Creating a simple design, on the other hand, offers no bragging rights -- after all, if the solution is simple, the problem can't have been very difficult, can it? And creating a simplistic (inadequate) design is seen as a sign of incompetence. As a result, there is strong social pressure to create complicated architectures and very few pressures to create a merely "adequate" simple design.
This results in a fundamental tension:
Business motivations favor simple designs that earn back their development costs early and can evolve over time. Social pressures encourage subtle, complicated designs that are stable over time. You will not be surprised to hear that the social pressures usually outweigh the business motivations.
A COOL MINIMALISM: YAGNI XP has managed to introduce a countering social pressure. The YAGNI rallying cry permits a different boast: "My design is simpler than your design, and it still works!" That the YAGNI cry has shown itself to be effective highlights once again the power of social peer pressures.
However, architects and managers both find YAGNI threatening for the following reasons:
The badge of the superior architect is invalidated. How is a smart, ambitious architect supposed to demonstrate his or her ability while attending to YAGNI? Deliberately ignoring known, forthcoming requirements threatens to result in a simplistic final design. Experienced architects and product managers raise the countercry, "No! I am gonna need it!" It is difficult for the manager to tell the difference between simple and simplistic designs and therefore is difficult to arbitrate in any meaningful way. Business managers find themselves caught between these strong social pressures. How are they to tell whether the architecture is proceeding on the YAGNI or the NIAGNI side of the line?
Enter business value. In the last decade, developers have shown that tidy, simple architectures are reasonably straightforward to upgrade to their next stage of complexity and performance. The business consequence of this is that, very often, a company can create an early version using a simple architecture to demonstrate function and possibly even generate revenue. It then can use an incremental rearchitecture strategy to revamp the infrastructure under the running system.
This approach can't always be done -- and I'll discuss that in a moment -- but it can be done more often than people expect. The advantages of this approach are:
The architecture is easier to modify when modifications are needed. The function and infrastructure teams get to work in parallel, hastening the moment at which usable function becomes available, or at least visible. The end users can view the system's proposed functionality early and judge (and improve) its fundamental fitness for business use.
The running system might reveal shortcomings in the architecture that the architects' early thought experiments didn't catch. The system can sometimes be deployed to a limited market, in which case the business will start earning revenue to help pay for ongoing development.
IT'S NOT FOR EVERY PROJECT
There are two particular circumstances in which the strategy might not be suitable:
1. Multiple deployments are not possible.
2. The project uses a large, geographically dispersed team.
Mobile phones and enterprise resource planning (ERP) systems are examples of the first situation. Mobile phones go from the manufacturer to the user to the garbage dump. It would be considered a major catastrophe if a cell phone manufacturer had to ask people to bring their phones back in for a software-architecture update. While ERP and other enterprise-wide systems are not quite so immutable, they are nonetheless deployed at most once annually. Whatever system goes out has to last until the following year.
The basic strategy, Incrementally Rearchitect from a Simple Initial Architecture, can still be employed when multiple deployments are not possible, with one particular difference: all of the tests of the final architecture, such as load tests, have to be performed within the primary development cycle. It may still be possible to show the system to friendly users or give it to alpha customers in order to find architectural errors early, but these activities have to be treated as part of the single-deployment model, as opposed to an income-generating multiple-deployment model.
If the live load is predicted to be enormous, the system might first be delivered to a miniature market for its maiden voyage. That delivery gives the team a chance to discover the real bottlenecks in the system design and to revise the architecture based on real information before deploying it to the main market.
The economic damage in the second case -- that of a large, geographically dispersed team -- comes from the cost of communicating each new architecture to all of the people in all of the locations well enough that they can make their local design decisions in accordance with the changed architecture. That cost, usually badly underestimated by project leaders, is why NIAGNI can be more appropriate. The next case history, which comes from Motorola [1, 3], illustrates this point.
WHY FEIGN IGNORANCE?
(Happy) Case 5: The project was to design a new mobile phone architecture involving transmission towers, handsets, and PCs. The bad news was that the project team consisted of a few hundred developers in six countries on three continents. Two pieces of good news offset this. The first was that the technical leads were familiar with the technical domain they were working in, so there was less risk of unknown requirements popping up than there might be on other projects. The second was that the resulting system was to be put through field trials, as opposed to being deployed to the marketplace, so any architectural mistakes would be merely expensive, not catastrophic.
Ron Crocker, the lead architect, reviewed with me their use of NIAGNI on one core architectural decision; namely, the decision to design the mobile phones to handle both circuit-switching and packet-switching traffic right from the start. The YAGNI approach would have called for them to design just for circuit switching and to add the capability for packet switching only when that became strictly necessary.
I asked Ron to estimate the cost of communicating the new redesign under the simplest circumstances -- say, for example, the project consisted only of 30 people, all located in the same building on the same floor. After a pause, he estimated that they might have been able to get all the developers up to speed on the new architecture in "merely" a few weeks.
"But why would I want to do that?" he asked. That is, why would they want to cost the entire team two weeks of time when the requirement was known from the beginning? Besides, he noted, they didn't have 30 people in one building -- they had 250 people in six countries. The cost of communicating the revised architecture would have been enormous, and the requirements were known from the start!
Rather than incur the cost of communicating a new global architecture in the middle of the project, Ron and his architecture team created a simple architecture that handled all the known "big rocks" (requirements particularly hard to incorporate late in the project) and let the local teams handle incorporation of the "small rocks" as they appeared throughout the project.
Ron's situation illustrates that even a recommended general strategy, such as Incrementally Rearchitect from a Simple Initial Architecture, is not universally applicable and can even backfire on occasion.
In deciding when to apply the strategy, ask the following questions:
Can the system, in fact, be developed in two streams, with the infrastructure or architecture evolving in parallel with the system functionality? (The answer is usually "yes.") Might the business catch an unpredicted architectural mistake by first creating a fallback simple architecture and testing the system in live use? (The answer is often "yes.") Can the business earn early revenue by deploying a version with limited functionality to a limited market? (The answer is surprisingly often "yes.") Are the gains achieved by these three means greater than the cost of communicating architectural redesigns to relevant members of the team? The answer to the fourth question is an easy "yes" when colocated teams are building new systems whose requirements are likely to change. The answer is a less obvious "yes" as the requirements become more stable.
The unexpected twist in the story is that although the cost of communicating redesigns to a geographically distributed team drives the answer to "no," the importance of having a simple architecture grows.
SIMPLE ARCHITECTURES AND AGILITY
The strategy of growing from a simple architecture clearly is centered in the agile development camp. This raises the following questions: Does the agile approach scale to larger projects and systems? And how does the issue of architecture change along the way?
The answer is that agile approaches do scale (because they are a mindset, as opposed to a specific set of rules) and that the simplicity of the architecture becomes more important as the project or system grows in size.
Ron led his far-flung architecture team for two Motorola field trial projects [1, 3]. In addition to the standard agile practices of incremental development, frequent personal communication, early integration, and high levels of testing, Ron made it one of his primary jobs to keep the overall system architecture from becoming complicated.
The architecture was based around subsystems matching the locations of the different teams, with minimal communication paths between those systems so as to minimize the need for communication across those teams. The primary architectural diagram was a simple four-quadrant sketch showing that every subsystem communicated only with other subsystems in the same quadrant or a directly adjacent quadrant (never having to cross diagonally).
Ron's first task was to ensure that every team member understood and could draw this diagram. His ongoing task was to help resolve design issues so that this elementary architectural principle didn't need to be violated and to see that the developers in the different sites didn't violate the principle by accident.
Recognizing the enormous costs of working with such a large, distributed team, Ron attended to NIAGNI for the "big rocks" he knew about in advance and put fanatical energy into keeping the architecture both simple and adequate to handle the known big issues. Once the simple and partitioned architecture was in place, he could let the individual teams deal with their local issues as they saw fit.
In interviews I am currently conducting, I am finding more architects who affirm the idea that simplicity in the architecture must be emphasized more as the team size increases.
SUMMARY
There are two competing approaches to developing architecture in the face of business changes:
1. Spend extra time to get the architecture "right" the first time so it won't need to change as the business changes.
2. Make a simple version to begin with and accept the business cost of updating it when its shortcomings become evident.
The first strategy is attractive to many ambitious designers, because it presents a more "interesting" challenge and improves their social and professional status. It is, however, rather like swinging for a home run, with the concomitant risk of striking out (which in business terms means that the system simply never gets delivered).
These days, more architects are adopting the second, base-hit strategy: create a simple initial architecture and incrementally rearchitect it using the information -- and possible the revenue -- that comes from using the early version.
From a business perspective, the second strategy offers lower risk and greater revenue. The safety zone around a simple design is much bigger, and the risked damage much smaller, than that around a complicated design. Further, the importance of having a truly simple architecture grows as the team size and the cost of communication grow.
What if there are "big rocks" to deal with and the team is committed to the YAGNI strategy? Move the big rocks to the front of the requirements queue so the architects have to face them early.