<<I had a brief conversation with Nick Gall <http://ironick.typepad.com>
(Twitter: ironick <http://twitter.com/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.>>
You can read Todd's blog at: http://www.biske.com/blog/?p=632
Gervas
