A response to Alex Hawkers blog & the challenge to define Flexible Service Delivery.
To my mind, the answer is sort of in the question. Bearing in mind the critics of the term FSD mentioned by Alex – and yes there have been some, and we could have spent the next ten years debating terminology – I think a useful way of looking at it is to see the three key words as defining the what, how and why of the programme.
Flexible is the what. As Alex says, what we’re trying to do is get institutions into the position where they can ‘exploit new and improved business models for the delivery of their IT services’ – which sounds like flexibility to me. To not necessarily be tied to big suppliers; to not necessarily have to run/own everything in house; to be open to new approaches to sharing, both internally and externally. I think it’s also useful to consider what ‘flexible’ isn’t: it isn’t necessarily shared services, software as a service, the Cloud, SOA, outsourcing etc – but it is having a flexible and adaptable approach that makes these genuinely and easily adoptable options. This approach is also required from suppliers – better and genuine adherence to standards, disaggregation of software suites, new models for delivery.
Service is the how. I think it’s critical to emphasise exactly how powerful the shift from thinking about systems to thinking about services can be – and I don’t mean this in the more technical SOA sense, but in the sense of thinking ‘my institution needs an enrolment service’ and not ‘my institution needs an enrolment system’. Thinking in the latter (old?) way tends to lead again in the direction of proliferating systems and associated integrations and complexity; thinking in the former (new?) way leads to more fundamental considerations about how the service might be delivered and where it might sit. Defining the service layer that sits above and is supported by the systems is an essential step towards flexibility – if you don’t have a clear picture of what services your systems are supporting, you can hardly make rational decisions about which to share/outsource/discontinue. And this – of course – is where Enterprise Architecture comes in, as an essential approach for understanding how your systems, processes and people fit together, all based around a service definition.
Delivery is the why. In the current financial climate, we still need to deliver quality services to increasingly demanding customers – and the scale of cuts already being faced means that we can’t simply do this by shaving a bit off the edges and doing everything that little bit less well. It will be mandatory to take a fundamental look at the what, how and why of all services (it should have been anyway!) – & we’ll undoubtedly end up with some new ones, some redesigned ones, some that are delivered in new and innovative ways, and some that are surplus to affordable requirements. As I’ve said, ‘flexible’ doesn’t necessarily mean shared services etc – it would hardly be flexible if it did – but financial constraints and customer expectations may well mean exactly that, and engagement with alternative methods of delivery may well not be optional.