Good Architecture == Bad Architecture
Today, I spent some time questioning what makes companies decide to migrate to new architectures. The conclusion that I came to was based upon the "architectural change is a tax to pay/avoid" mantra that I think Business has. Basically, change is often only approved where necessary or with zero cost/risk; if the current architecture is seen as failing now, can be shown to fail in the near future, or change has no real cost/risk associated with it then there is a good reason to change or little reason to avoid change. If the risk of staying on the current architecture vs. migrating can't be shown to be a really clear call, then change is less likely to be approved. This is where I've found a problem to exist:
If your current architecture is well designed, you may not be able to justify moving off it.
Obviously, in companies where a more equal technology-business partnership exists, this isn't as much of a problem. For others it can be; in the long term, a migration might prove really valuable - a change to SOA may help you become more agile by being able to switch partners more readily. But if that's not a current requirement, how do you justify change now if, say, you've got quite a robust component oriented DNA architecture?
Hence a relatively good architecture is sometimes actually a bad architecture.
I'll qualify that a bit; it's only actually bad in terms of migration. But surely a good architecture is one that supports change at low cost, not just one that's technically impeccable? If you bear the need for future change in mind whilst developing on an existing system, this can then be supported much easier than through retrofits, as is always the case.
How migration support is built into a system has to be approached on a case-by-case basis. Several standard approaches exist, though, such as using data/transport formats that are common to both the old and new platform at certain shearing points. But these are really just the same techniques as used for supporting internal change.
If you think about what's just been written, there are two things to note:
- It's actually shifting the cost of transformation - rather than incurring it at the migration point from Generation.N to Generation.N+1 architecture, it's spreading it across the development of Generation.N as well.
- It's altering the types of migration that are available. With common data/transport formats, encapsulated logic, etc. you can implement a piece-meal migration, rather than a big-bang approach necessary with systems that consist of, for instance, one giant object model.
So, the title of this entry is possibly a bit misleading. There's an important principle, though: systems as a whole are iterative, and creating an internally perfect Generation.X of a system won't necessarily help, and can hinder the creation of Generation.X+1 - if a system is architected to be good for the current situation, that may well be all it's good for. In the worst case, if a large part of the Generation.X+1 budget is spent on migration issues, your architecture could degenerate over time rather than improve. Personally, I think this is part of the reason that the "shiny new architecture" that's promised always appears a little tarnished by the time it's introduced. I'll look at the other reasons for that in another entry...