Sponsored Link •
Bill Venners: You write in Beyond Software Architecture:
The initial version of an architecture can be like a young child: whole and complete, but immature and perhaps a bit unsteady. Over time, and through use and multiple release cycles, the architecture matures and solidifies, as both its users and its creators gain confidence in its capabilities while they understand and manage its limitations. The process is characterized by a commitment to obtaining honest feedback and responding to it by making the changes necessary for success. Of course, an immature architecture can remain immature and/or stagnate altogether without feedback. The biggest determinant is usually the market.
What is the difference between maturity and completeness?
Luke Hohmann: In its first version, an architecture should be like a baby. It is whole and complete. It has ten fingers and ten toes. It has all its systems, but it is immature. You wouldn't expect it to do certain things that you might expect a mature system to do. Of course, the definition of what is complete and incomplete, mature and immature, is subjective. But it is really important to distinguish between incompleteness and immaturity. I see the people make the mistake made all the time of building an incomplete system. It's actually not a mistake that's correlated to a development process, near as I can tell. You can have iterative, agile projects that produce incomplete results, and you can have waterfall or traditional kinds of projects that produce incomplete results.
Bill Venners: Why is it important to aim for completeness?
Luke Hohmann: I'll give you a simple example from a software product standpoint, which is the bulk of my experience. If you were building a reservation system, you might in your initial release have the ability to create a reservation and delete a reservation. That would actually be a complete system, because if you needed to modify a reservation you could delete it and add it again in modified form. By contrast, I've seen people actually create systems in which you could add and modify a reservation, but not delete a reservation.
Bill Venners: And that's not complete, because if it were complete, I could delete. So you're saying that we should shoot for something that's complete, even if not mature.
Luke Hohmann: Right. You always want to shoot for completeness. You want to have a system that's complete, but not necessarily mature. Maturity in this example is that it is obviously easier to use an edit than a delete and add. In one approach, the first sequence of iterative development creates something that's whole and complete, but immature. In the other approach, it creates something that's incomplete,...
Bill Venners: ...but has some aspect of maturity.
Luke Hohmann: Yes. The second approach gives you an idiot savant, and that's what you don't want.
Bill Venners: In the end of the paragraph from your book that I quoted earlier, you wrote about the maturing process that, "The biggest determinant is usually the market." Why is the determinant the market?
Luke Hohmann: The abstract definition of the market would be the users who are actually using the system. Most of my experience is actually building products or consulting for companies who actually build products for sale, as opposed to companies who build IT products for internal use. Concretely, if PeopleSoft were one of my customers, when I say market, I mean PeopleSoft's customers of their ERP system. That's the market that's going to determine whether or not that architecture is going to solidify and grow, or whether it's going to die altogether.
Bill Venners: And you're saying that listening to the feedback from the market of users is what will help the architecture mature.
Luke Hohmann: Yes, but not only that. Two kinds of feedback help systems mature. If you are building an enterprise software product, and you have something that's working or headed in the right direction, the feedback you're going to get from the market is, "This is a good feature. I want you to do more of it. This is a good thing." And if you have something going in the wrong direction, you'll hear about that too. That's one kind of feedback.
The other kind of feedback that you need to get is internal. When a given stakeholder, like technical support, says, "We are consistently having a problem here, and we need you to modify the system this way so we can deal with it," that's typically where you are dealing with all those things architects don't think they need to deal with, but which are vital for success. Upgrades, installs, log files, configuration—the architecture has a huge impact on these things.
You can visualize the features of a product as a tree, where the infrastructure is the roots and the main features are the heavy branches. As you look at what you're putting into the next release, you're actually talking about growing your tree, and in the process you also want to prune the tree. To me, architectures are always organic. Some branches will live and others die. You can prune plants for different shapes, and the market and internal feedback informs your decisions.
Bill Venners: In my experience, I have found that if you give people something, even if only 2% of your users want it, it is hard to take it away, to prune it, because they actually use it for something important to them. How do you prune in practice?
Luke Hohmann: That's typically the role of the product manager. A good product manager will actively manage the feature set. I've played that role, so I've made the decision to remove features. It's not necessarily easy, and you will piss people off. One factor that you have to weigh in your decision making process is just how important is that particular 2% of your market. If it is a non-vocal portion that doesn't account for much revenue, then dropping the feature might be good for you (less code to maintain lowers your costs). If it is 2% of your market, but 16% of your revenue, then you'll need to approach the decision more carefully.
Dropping a feature doesn't have to be complex, and chances are good that you've already done it. It can be as simple as dropping support for an outdated operating system. You're not going to run on NT 3.5.1 right now, so the ripple upgrade effect of Microsoft forcing you to upgrade is in a sense removing a feature. For some customers, who are still running Windows NT 3.5.1, that's a problem. People do prune the product trees. The trouble is they often just don't do it well enough. Bad pruning is one of the great downfalls of many architectures. The vestiges of unruly bush undergrowth bog the architecture down.
Bill Venners: In your book, Beyond Software Architecture, you write: "The books tell us that when the system is completely new and the problem terrain is somewhat unfamiliar, designers should, for example, 'explore alternative architectures to see what works best.' This is sensible advice. It is also virtually useless." Why is it useless advice?
Luke Hohmann: Because, especially for a software product vendor, you're not going to be funded either internally or by a venture capitalist to build four versions of an architecture and then figure out which one works well. That attitude may be appropriate in academic circles, but it has no bearing with any kind of monetary payback value. Having worked at start-ups, I can tell you that you've got to get the product done. You've got to get it out there, because you've got cash left for X number of months, and if you don't get it done you're not going to survive. "Build a few alternatives and pick the best one," is just not how it works.
Bill Venners: A bit later in your book, you write:
Imagine that you are an explorer and you've just crossed a mountain pass and entered a strange new land. You have at your disposal a variety of gear that can help you navigate mountains, valleys, deserts, rain forests, deep lakes, and fast-moving streams. You also have a small, single-person helicopter for reconnaissance. Do you just jump in and start exploring, or do you fire up the helicopter, take a look around, and plot your course? Good explorers fire up the helicopter and plot their course.
I assume the reconnaissance mission contrasts with going on four different adventures and then coming back and saying, "OK, let's go this way."
Luke Hohmann: That would be the right analogy. There's a difference between fully exploring alternatives and taking a scouting trip that's relatively low cost and gives you an overview. On the scouting trip, you check out the domain and the lay of the land. You still could get complete unknowns, and you still may have chosen to go west when you should have gone north. But you're not going to go north and take all that data, then go west and take all that data, then go south and take all that data, and then figure out which one's right.