Following the previous post on the importance of flexibility in any strategic architecture, one has to plan for how this flexibility will be provided and managed.
Flexibility implies a "flexibility point", a point or interface at which the consumer of some functionality and provider of the functionality meet. This point enables the provider to make changes, and it enables the consumer to accommodate those changes in a controlled manner.
But how does one represent change?
There are multiple methods used in the industry today to represent change in provider functionality
- Version number: Here the change is represented through the use of some notation, like major.minor.maintenance, where each of these components represent the type of change being introduced. This notation may be extended in some cases to further indicate the level of maturity like alpha, beta, release candidate, etc. Well known examples include Google AdWords 12.
- Date: Here the change is represented through the use of the date and time when the change was introduced. Well known examples include Microsoft Visio 2007, or the XML schema namespace which is http://www.w3.org/2001/XMLSchema.
The benefits of using a version number is that it enables the change to happen at any point, but requires a discipline of managing this versioning mechanism. The benefits of using a date is that it enables automation in that human intervention for deciding a version number is not needed, but this automation can lead to anomalies like the date indicated by the change is not really when the change was introduced.
Many well known flexibility points don't have a built in method for indicating change. For e.g. the URI which is a standard method for identifying a resource has no notion of versioning. So, change management to resources are managed in different ways by different providers.
Because of the importance of flexibility, as indicated in the previous post, it is important to think about how change will be introduced from the start. Introducing this at a later stage will likely lead to very expensive impact to the consumer of functionality.