I gave a presentation at the recent British Computer Society (BCS) Enterprise Architecture Conference and this post is an outline of my talk. Over the last few years I have worked with many architects and quite a few are unhappy. Executives might appreciate the efforts that go into models and designs but things move on so quickly that, often, the architect’s work does not keep pace with events or arrives too late to be useful. The architect might sadly slope away, loaded down with copies of densely packed designs which are now only good for the recycling bin, or they might become angry at being ignored. Either way, it is not a pleasant situation. I shared with the conference some ideas about why this is happening and offered some suggestions of how to respond.
I recently read a really nice post by Drew Firment (thanks go to Chis Swan for sharing it). Drew’s article reminded me of some patterns I have seen in big transformations - most recently in my digital transformation work but also in the earlier rounds of change we called internet- or electronic-business transformation. This post is a first attempt at making these patterns explicit, initially so I can use them in my own work. It would be great to get your feedback if you think they will help you too. Lots of other people have already been trying to make sense of this area through frameworks, maturity models, life-cycles and other models. I have started to collect a list of some of these at the end of this post and they are worth reviewing as well.
I recently noticed that I have been using @CIOPortfolio for 5 years now and that got me thinking about what has changed for CIOs over that time. Although digital technology is renowned for its frenetic pace of innovation (here we go again!) you could argue that not much has changed. Surprisingly, that is a terrifically useful insight for CIOs.
This is quite a long post so here is the 30-second version: organising services around calendars and clocks is generally a bad idea it is much better to organise around outcomes and risks this is now a practical option because of new technology CIOs can take the lead and help the whole enterprise. Sarah Wilkinson, CTO for the UK Home Office, recently wrote a post about breaking away from some long held traditions in IT. The article includes some great advice but I think we need to go further.
The signs are not good. A recent CIO Survey so this is all a bit worrying. Can we save architecture? Should we try?
I managed to get along to the Cloud World Forum in London this week. It was a busy, fast and noisy event (sometimes very noisy) which provided a way to sample a lot of views in a short space of time. The fundamentals of cloud computing are well established so there were no paradigm shaking revelations (and this wasn’t the kind of premier global event where such things might get announced anyway). I did pick up some subtle signals which might be of interest to organisations wanting to move to the cloud, suppliers competing for cloud business and engineers working with cloud technologies. This first post focuses on the customer perspective.
Despite what you might have heard, managing finances for IT is really very simple. Forget the nonsense you may read about “value centres” and “capex vs opex”. Instead, here is a simple story which will illustrate all you need to know.
Recently I have been enjoying the “Pheonix ProjectThis is one of those novels of IT and, like a good Disney movie, you know it is just a story but it engages on many levels and includes strong messages. In the Pheonix Project the authors make much of the parallels between traditional manufacturing and IT operations. I am a big fan of this idea and something very similar is at the heart of the next chapter in our story about a service oriented operating model for IT.
In this latest post on a service-oriented operating model for IT I will cover mapping out the IT value chain. There are quite a few steps which lead up to this point so start here if you want a reminder and don’t forget these warnings. So let’s get started with: what are IT value chains all about, why you need to take the time to map them and how do you use them.
I have been writing a series of posts about implementing an operating model for IT which is based upon services. If you followed the last post you will have already started to engage your key stakeholders and they will already be thinking about their IT needs and their role in making the IT ecosystem work. Now you will be looking for advice on how to map out the value chains for the new IT model. The next post will go into more detail on how to use value chains and provide some examples but first I thought I should share a few warnings. We are about to enter what is probably the most dangerous part of the journey where unwary CIOs could be lured off course and face disaster. Take a look and let me know what you think.
This post is one of a series about developing a service-oriented operating model for IT. Previous posts have covered: the concept of a service-oriented operating model for IT designing the right organisation structure. This post is about the first step in the IT transformation process - engaging with the rest of the organisation. This means IT leadership engaging with other leaders across the enterprise and not just the rest of the IT department. Whether or not your vision is to move to a service-oriented operating model this is the first step in the process.
This is first of a series of follow ups to my blog post about a service-oriented operating model for IT. These posts are based upon some of my insights and experience of putting this model into practice and I hope they will either help you develop your own thinking or provoke you to share your own ideas. In these follow up posts I am going to cover: engaging the rest of the organisation mapping out the IT value chain developing the IT bill of materials designing the IT organisation structure aligning funding and resources implementing the change. Most of the comments and reactions to the original blog post concern organisation so I am going to start there although, logically, it is the fourth step.
There is quite a lot written about IT consolidation and centralisation. Best practice in business operations includes concepts such as having a “single source of the truth” to help understand and serve customers or make key business decisions. These sorts of concepts imply some centrally managed shared IT. Enterprise architects strive to understand, model and design business structures and supporting IT spanning whole enterprises. IT concepts and technologies such as Service Oriented Architecture and Cloud Computing are justified on the principles of maximising scale and re-use. Procurement specialists seek to rationalise suppliers and consolidate purchases for all categories of spend including IT products and services. Suppliers offer price and other inducements for sole supplier status. For a long time ERP suppliers have promoted their ability to provide a single, integrated solution to the needs of large businesses. For relatively small organisations a single, enterprise-wide perspective on IT is quite realistic. For large organisations, particularly those which operate on a truly global scale, the reality is a lot more complex.
Recently I read an article on the on-line version of Forbes by Mark Settle. Mark was proposing an IT operating model which he calls “Broker/Integrate/Orchestrate” as a replacement for a more traditional approach he refers to as “Plan/Build/Run”. The article is well written but I think Mark creates an artificial gulf between these two ways of looking at IT and neglects another useful alternative: an operating model based upon a portfolio of services.