Todd Biske: Outside the Box

An expression that you may have heard bantered about in SOA discussions is “design for change.” A recent exchange on a Yahoo group made me decide that I really don’t like it.

If you think about it, how can you possibly design for a change, unless you know what that change is going to be? In that case, you’re not really supporting change, you’re supporting a known quantity. The only example that I can come up with that actually makes sense is systems that deal with regulatory enforcement. For example, Intuit knows that the Tax Code changes every year. If they had some web services associated with this in their TurboTax products, it is possibly that the interfaces of these could be designed to support change. The reason they’re able to do this is because they have a good idea on how things change. They may not know what aspect of the tax code will change, however, so there’s still plenty of work to be done.

What we really should be espousing is a three-pronged approach. First, architect for change. Okay, some of you are immediately going to cry foul and say, “What’s the difference?” To me, architecture is about establishing boundaries. It is the process of splitting a problem up into independently maintainable components. To architect for change, you don’t need to know what changes will occur, you need to know where the changes may occur. If I haven’t broken out my tax calculation service from the user facing system that requires it, adding new tax laws into the product is going to be more costly because I did not establish appropriate boundaries. SOA is about architecting for change, not designing for change.

Second, design to the best of your current knowledge. In other words, don’t try to predict the future. Design is about what goes within those boundaries, but certainly does involve the boundary itself (i.e. the interface). If you try to come up with an interface that supports all currently known needs as well as trying to predict the future, you can run into all sorts of problems ranging from analysis paralysis to an interface that works for all but is equally hated by all. One point of note on this. Designing to the best of your current knowledge doesn’t mean you only accept input from service consumers currently under developed. If you know that another system is going to use your service in the future, then you should incorporate their needs into your design. If you hope that another system is going to use your service, now you’re starting to walk on thin ice.

Third, and most importantly, plan for change. It has been said that the only constant is change. Your systems, your services, your business- all of them will change. What gets us into trouble is not the fact that things have changed, it’s that it is a mad scramble when things do. Schedules have to be synchronized, resources assigned, etc. Think about how you deal with your vendors. Which would you rather deal with? A vendor that releases a version every 6 months, on schedule, without fail, or a vendor that sometimes releases versions within a month of each other, but sometimes as long as 18 months? As a consumer of that vendor, how can you possibly hope to plan your upgrades? To become a service provider, you must figure out how to effectively manage change. A standard release schedule for every service would be a great start. For an enterprise, those changes may not occur as frequently as needed for a commercial product. Perhaps there are standard dates that must be used.

The problem is not a technical one. This isn’t a debate over SOAP/WS-* versus REST. If the underlying XML message changes, the consumer and provider need to be modified, presuming the change isn’t backward compatible with the existing schema. If the organization has to scramble every time this situation occurs, that causes problems.

One Response to “Design for Change?”