API Versioning in the Enterprise – Minimising the impact of change

There are a number of versioning approaches that we regularly come across in the the IT world including:

  • Semver (http://semver.org)
    • is based on using the versioning information in a build to inform the consumer of the nature of the changes
  • Calver (http://calver.org)
    • calver is based on informing more about release schedules and supportability
  • And even sentimentalver (http://sentimentalversioning.org)
    • probably the default position of many developers but again is based on using versioning to indicate something about what the new version is compared to the previous ones

These strategies have been borne out of software development projects where we control every aspect of the development. They have been extended to work within eco-systems such as node.js to support automated build and dependency management and have worked with some success. In-fact version control based on source code changes has many advantages and should be actively encouraged as:

  • It can be used by automated scripts to attempt to ensure compatibility of software when releasing software,
  • It helps in support when you need to know when a bug was reported and what code was actually live at the time
  • It can help you with bug fix releases
  • You can create version dependency matrices showing what versions of the software are currently deployed and how they relate to each other.

There are often attempts to utilise these strategies for internal services (e.g. SOAP services) and also external API’s. How ever none of the ‘BIG’ api publishers use any of these versioning strategies and even software runtimes such as Java and .NET actually offer you a completely different strategy. Why do we still use these strategies in our enterprise and is there an alternative? Continue reading API Versioning in the Enterprise – Minimising the impact of change

On Current, Transitional and Target Architectures

Having worked through a number of large scale IT projects, migrations and transformations, I thought it prudent to share some thoughts around these three, commonly used yet commonly misunderstood, Architectural States: ‘Current’, ‘Transitional’ and ‘Target’.

All architectural strategies must consider at least two of these, the Current and Target states and some, well any which are not pure big bang releases, will include one or more transitional architectures.

What are these states for and what do they mean? Continue reading On Current, Transitional and Target Architectures

Enterprise Architecture Types


A lot has been written about the role of enterprise architecture in an organization, what the benefits are, what is the best framework to use, and how this fits with the role of solution architects. However one thing that has become clear to me over the years of working in this space is the lack of understanding of exactly what the common enterprise architectures are and how enterprise architectures change over the life of an organization. This can lead to misunderstandings about what possible end state architectures there are, what they can do for an organization and what drawbacks they bring. It is clear without this knowledge it is usually impossible to make and communicate which architectural state and organization is best suited for and why.

Continue reading Enterprise Architecture Types