In my last blog we looked at the first area we need to cover in a strategy, in this post we will look into some of the other areas we need to cover.
The next part of the strategy is the process part, what processes do we need as an organisation to make good use of the technology?
I’m pretty sure everyone here has at some point in their life deployed some fantastic bit of kit that ended up only being used for 10% (or not at all) because it was:
- not implemented correctly due to lack of knowledge.
- it was over specified with way more features than needed which now sit idle all day.
- the process in use where never adapted and the old process “works fine” .
- nobody actually knew it was deployed and the guy that did has long since left.
- it turned out to be way more complex than the vendor let on.
Hello complexity and technical debt!
Going round the various teams and asking them about their processes can sound laborious but will greatly help in understanding how a company operates, uncover which parts are not captured in process and possibly identify opportunities for enhancing efficiency (typically marketed as “time to market”).
If we introduce new technology we need to make sure the appropriate service-portfolios are updated, new process are developed to actually use the product (as intended).
Special attention should be placed on inter-team process as often badly aligned process or overly complex (bureaucratic) processes can negatively impact productivity, efficiency and speed of delivery. In the Netherlands we actually have a term for unnecessary bureaucratic processes “de paarse krokodil” (“the purple crocodile”) and I’m sure most countries will have their own version (leave a comment with your version I’d love to hear them).
So now that we have an overview of technology and processes we need to look at the final part of the puzzle, the people involved.
Change of technology means change of skill sets and so we need to map out which skills are readily available, which are sparse, which might disappear and which are new.
Now writing down what changes people should “undergo” is easy but actually motivating people to change is hard and as pointed out in a recent blog post by Denise Donoheu this is really something you should spend time on getting support from both management and the teams.
So making a clear overview of skills (possibly augmented with available training courses and certifications) can help in attract new people to the team and help current team members in deciding which skills they need (and want) to learn.
At this point I’d like to reiterate the importance of people in the whole process because without the people your vision is dead in the water, so getting support throughout all layers of the organisation is paramount.
Each change we want (or even need) to make within the strategy will require resources in terms of money (cost of equipment, training, process changes) time and people. And while giving an exact number will be hard, a good indication should be included (here the architect can rely on the engineers and operations teams to get rough cost estimates).
Part of cost is savings so if you are sure certain savings can be made (by process improvements or replacing two bits of technology by one) include those. Potential savings should also be mentioned, for instance if we spend a bit more time automating we might reduce operational spend.
All costs should be broken down in recurring costs (licenses, support etc.) and one off (initial purchase). There are some great posts on Packetpushers about the cost of hardware and why nobody (should) pay list-prices.
So far we have mainly been gathering information, talking to people (people we know from when we were working on our vision, right?), and we now have a bloc note full of technology, processes, skills and costs.
The final part is putting it all together and figuring out which technology dependencies exist, maybe I need X to be deployed before K or have optimized some process or automated task Z. So we map out the technologies and dependencies in the right order making sure to include time for skills to develop (make sure to validate this with the teams). Also make sure to include key points where new skills should be available within the organisation (see processes).
Do remember though this is still a high-level roadmap so don’t try to plan it down to the minute (that’s why we have project managers) just provide a reasonable timeline so management can see how long the process will take, have a rough indication of money spent (and when) and the various teams can anticipate the workload.
Breaking down the ivory tower.
As you might have guessed working on a vision and strategy takes some time, so why not help your architect out and see if you can do a similar exercise for your area of expertise and share this with them.
Are you a network admin, what would your vision be, and what would your strategy be to achieve this? Are you a systems admin, what is your vision and how would you go about achieving it?
Companies that adhere to a “architecture-driven” or “architecture-led” model will often use this strategy to start planning projects and programs to execute and start moving towards the vision.
If however your company does not follow this model then it is time for the architect to put on some comfortable shoes and start going round the company trying to convince everyone their plan is the one to follow.
Feel free to drop your thoughts in the comments.