Service Design - Design Challenges

Its not just about technology

Organisations sometimes place an overemphasis on technology. Instead it's better to focus on how to get the business and IT thinking together. By separating away from the technology focus, it prevents the business from focusing too closely on a particular web application or database. We can then concentrate at the high level instead using the top down approach.

Business getting drawn in to development

In some instances the business unit gets involved in actually developing the solution and handing it to the IT unit. That's not too bad if the IT unit have a service oriented architecture that supports plugging in apps and components with minimal impact. But these days, if the IT unit lets the business unit determine solutions then they'll end up with diversity from so many different types of tools and languages. These things all start to drive up IT costs and resources. Instead of letting the business unit run freely, we need to help the business unit understand early on, using Service Design. Outlining particular things that make sense if the business unit wants to work with the solution.

Endless scoping

The longer it takes to design something, the more chance we have for requirements to change. So we really need to get a handle on getting requirements and dealing with changes in requirements. The business needs to understand the impact of letting requirements float. Certainly some requirements can float downstream, e.g. the final design of a web app. However other types of things need to be controlled.

Compliance and risk

Governance, risk and compliance are certainly a challenge and usually something that's left out towards the end. A few policies accounted for here and there in design is not enough. Thankfully, there's some great guidance in v3 in terms of governance, accountability and decisions to help you remember and account for those particular items.

I wish we had done..

As we progress down into operations, we see issues with the delivered designs, and we always want to look back and say I wish we'd spent more time on a better design. The upfront architecture at the design phase is pivotal to operations. We need to put the appropriate focus and amount of attention on architecture type activities. Not just drawing diagrams, but building data fields and data constructs.

Service Warranty

These days there's a fundamental inability to predict service warranty. Instead organisations look to design for 'reasonable' levels of availability. Then afterwards, they'll implement processes, train people and put in tools that will give them that level of warranty they need. Its almost like a build it first, adapt it later approach.

Skipping processes

As we progress through the service lifecycle, processes are left out because of either a lack of enthusiasm or limited resources. If we under focus on one task and put more focus on another, you know that will cause problems down stream when we get into testing. For example, if we're short on capacity and we didn't think about the business demand. Or we didn't really estimate the risk for doubling our storage growth over the next year, we didn't budget that in. Like the waterfall effect, a small unaccounted item can snowball into a bigger problem as we process through the phases.