Thoughts on designing for change
I had a brief conversation with Nick Gall (Twitter: ironick) of Gartner on Twitter regarding designing for change. Back in the early days of SOA, I’m pretty sure that I first heard the phrase, “we need to build things to change” from a Gartner analyst, although I don’t recall which one. Since that time, there’s been a lot of discussion on the subject of designing/building for change, usually tied to a discussion on REST versus WS-*. Yesterday, I stepped back from the debate and thought, “Can we ever design for change, and is that really the right problem?”
As I told Nick, technology and design choices can certain constrain the flexibility that you have. Think about the office building that many of us work in. There was a time when they weren’t big farms of cubicle and they actually had real walls and doors. Did this design work? Yes. Was it flexible enough to meet the needs of an expanding work force? No. I couldn’t easily and quickly create new conference rooms, change the size of spaces, etc. Did it meet all possible changes the company would go through? No. Did the planners ever think that every cubicle would consume the amount of electricity they do today? What about wiring for the Internet? Sometimes those buildings need to be renovated or even bulldozed. The same thing is true on the technology side. We made some design decisions that worked and were flexibility, yet not flexible enough for the change that could not have been easily predicted in most companies, such as the advent of the internet.
Maybe I’m getting wiser as I go through more of these technology changes, but for me, the fundamental problem is not the technology selection. Yes, poor design and technology selection can be limiting, but I think the bigger problem is that we have poor processes for determining what changes are definitely coming, what changes might be coming, and how and when to incorporate those changes into what IT does, despite the available predictions from the various analysts. Instead, we have a reactive, project-driven approach without any sort of portfolio planning and management expertise. To this, I’m reminded of a thought I had while sitting in a Gartner talk on application and project portfolio management a year or two ago. If I’m sitting in a similar session on service portfolio management 5 years from now, we’ve missed the boat and we still don’t get it. Develop a process for change, and it well help you make good, timely design choices. The process for change involves sound portfolio management and rationalization processes.
8 Responses to “Thoughts on designing for change”
Leave a Reply
Todd, if you haven’t seen it, take a look at Stuart Brand’s book “How Buildings Learn: What happens after they’re built”.
It’s a real inspiration to IT architects grappling with building maintainable software.
I’m a believer that applying clean separation of concerns liberally enables different system layers to change at different rates. Brand calls this pace layering.
Agreed, that you can’t anticipate the nature of the changes required to software, but you can anticipate that changes will come and that different layers of your system will need to change at different rates. (e.g. you change your sofa more often than you change your wiring scheme = you change your middleware at a different rate to changes to your business capability)
RW.
@Richard, Great reference to Stuart Brands book. I incorporate some of the thinking on “shearing layers” in my research on “design for change.” For more details on shearing layers (and the architect who created them) see http://en.wikipedia.org/wiki/Shearing_layers .
@Todd, I find it hard to understand how Modular office spaces supports your argument. Modular office design has been a huge success by any measure. NO design will ever be 100% flexible and evolvable (I can show you some of the theoretical work that proves this if you’re interested). That said, designs that provide 80/20 flexibility and extensibility are WAY better than designs that are virtually impossible to change the moment they are deployed.
If you’re looking for the paradigm of the evolvable design and the governance process that guides its evolution, look no further than the Internet itself. Over 30 years old and still rapidly evolving and changing the world. Can’t say that about many 30 year old architectures, eg the IBM mainframe.
None of this is new by the way. One of the papers I always cite as seminal to the concept of “design for change” is David Parnas’ “On the Criteria to Be Used in Decomposing Systems into Modules”.
Way back in 1972, David said: “We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing.” See http://sunnyday.mit.edu/16.355/parnas-criteria.html
I’m just trying to get people to pay more attention to great advice that was given 30+ years ago.
The modular office analogy was meant to illustrate the point that no design will address 100% of future needs. The more important point, and one that we technology professionals seem to repeat over and over again, is that the crux of the issue may not be (and I would argue is not) a technology issue. Can technology impact flexibility, absolutely. But is technology the 80% contributor to improved agility? I don’t think so. I think changes to the process and culture of how IT is leveraged will have far more significance than a technology choice.
I guess we’ll have to agree to disagree Todd. The increased pace and agility of modern economic life primarily due to technologies, especially the computer. You seem to be saying that a business (or culture for that matter) with superb governance but no computers (just manual paper-based record keeping, say circa 1850) could out-compete a similar company with average governance but the latest in computer technology. I don’t believe it.
But don’t get me wrong, a lot of technology is misused and goes to waste. But that doesn’t prove that technology is only 20% of success. I just don’t see enough “low tech” companies or cultures “out performing” high tech ones to accept your point that technology is a minor factor.
In general, the more advanced the technology base, the more successful/productive the business. Not in every case — but on average. And there are Bureau of Economic Statistics studies to prove it.
Todd, I get your point, and Nick your point as well.
Nick I sure do agree with your comment about lessons learned 30 years ago, they still apply today, and being able to identify those separation of concerns and the design boundaries is where architects today should spend their time. Instead it’s usually a barrage of tools and how to hook them together into a functional solution for today…let alone something that will transcend time of execution. This is a product of management teams hunt for short-term fortune and glory, instead of long-term sustainability, and foundations to build success upon.
I did not take Todd’s comments about technology not being the significant contributor to mean that technology does not matter. I took it to mean, technology is the price of admission for corporations to function today, and we have a significant arsenal of tools to create technology based business solutions. However, having the technology is not the major issue we deal with today, it’s how best to use it, and define our business operations within said technology. Both business operations and the technology fabric designed for change.
Best Regards,
Tom
Decision Services and designing for change…
Todd Biske wrote an interesting piece titled Thoughts on designing for change that made me think about one of the real basics of decision management and reminded me of some comments Phil Wainewright made years ago about what happens to……
[…] Biske wrote an interesting piece titled Thoughts on designing for change that made me think about one of the real basics of decision management and reminded me of some […]
[…] Biske wrote an interesting piece titled Thoughts on designing for change that made me think about one of the real basics of decision management and reminded me of some […]