At my company we have found a nice way to get future-oriented discussions going. We have a workshop format for discussing current strategy and trends in order to define the most important capabilities for the future. These workshops have really been a good way to make people think about things that will be important in a more long-term perspective. One of those things that have been discussed in these workshops is speed and flexibility and the ability to experiment with ideas. Dave Gray has interesting views about experimenting in the book The Connected Company. (There can also be leadership difficulties with experimenting, some of which is mentioned here: http://thebuildnetwork.com/innovation/pricing-experiments/)

I think that one of the most critical aspects to consider for your architecture is the speed of change that is needed for your organization. An experimenting capability is probably one of the business needs that put most demand on speed. And you will need to consider that different parts don’t need the same speed of change. And there might even be parts that would be hurt if designed mainly for speed. In his blog post Unbreaking, Tom Graves hit on something that made me “connect some dots”. The part I’m referring to is what he calls the tactic of backbone and edge. (Tom has written about this in older blog posts as well so please take a look at his pointers.)

Tom talks about spectrum of stability and spectrum of governance, and this is important. When the speed of change differs much within your enterprise you will most likely need different types of governance. This might seem obvious, but how do you actually create an organization that can handle this? I think that this is especially important when it comes to IT development. At my organization we have a history of building much of our own software, and finding the right type of organization and governance will be important for us when increasing our experimenting capability.

For the IT part of this equation I have been spending a little bit of time on thinking on the concept of software product lines (see SEI Software Product Lines). Here we have the concepts of “core assets” and “variations” that I think might fit well with an overall enterprise architecture based on backbone and edge. Software product lines has its focus on solving common problems for organizations that sell software products, but in the concept I see things that might give one more dimension for organizations with a large portfolio of IT solutions. The basic idea I have is to define core assets within the backbone and allowing variations of the same software in the edges, and thus allowing more experiments outside the backbone. It might also be easier to have a distributed development organization working on different variations. Successful experiments can then be defined to either be included into the core assets or be run as a valid variation for one part of the enterprise. It would be really interesting to see if other organizations have tried something like this 🙂

One aspect of this approach that I have been thinking about as well is how I can visualize it. I would like to have it in some sort of core diagram as seen in Enterprise Architecture as Strategy. It would require some nice way to illustrate the different speed of changes. I haven’t seen a really good way to do that yet, but if you know of any good examples, please share 🙂

On the topic of speed, I feel forced to also share this song: Speed Metal – by Mustasch