Operations Development
The Setup
Imagine this scenario:
You are a person with a job. Your job involves doing technical things on complex IT systems. Part of your work involves using other complex IT systems (e.g. email, job ticketers, wikis, etc.).
Now imagine this:
The complex IT systems you have to use to do your job have the odd bug, or require the occasional enhancement.
I know, it's a radical hypothetical, but it could happen.
And to complete the scenario:
There are teams of people in your organisation with jobs that involve doing technical things on the complex IT systems you have to use to do your job.
Terminology
Because I can tell this is going to get really wordy if I keep going like this, here are some fictional names which bear no resemblance to any real people or systems:
- "WARMTH" – a complex IT system you have to use to do your job
- "the WARMTH team" – the team of people with jobs that involve doing technical things on WARMTH
Endarkenment
In an unenlightened corporate environment the WARMTH system would be entirely configured, developed, and managed by the WARMTH team. The WARMTH code, maybe even documentation, would be restricted so that only members of the WARMTH team could access (let alone modify) it. Any bug or enhancement you identify would have to be assigned to the WARMTH team, then the WARMTH team would have to:
- gather requirements / identify the actual issue
- evaluate / approve / prioritise it (or reject it as not in line with the future vision for the service underpinned by the WARMTH system)
- identify and develop a fix/implementation
- QA the fix/implementation (code review, integration testing, etc.)
- deploy the fix/implementation
- confirm that it's resolved (including checking that you're satisfied)
That's a lot for the WARMTH team to do.
Enlightenment
Enlightenment comes when you realise that – while the WARMTH team members are all "people with jobs that involve doing technical things on complex IT systems" – you, too, are "a person with a job that involves doing technical things on complex IT systems."
Your particular and specific expertise may not be in dealing with the complexities and idiosyncrasies of WARMTH, but as an end user you should have a good idea of how it works (and share the future vision for the service it underpins, but that's another story), and as a technical person you should have a certain generalised ability to identify and resolve simple technical issues (particularly issues of content and configuration, if not code).
Models
In the technical industry we have a pretty well-developed model:
- work is done in an isolated "development" space;
- candidate changes are reviewed, then merged into a clean "working" space; then
- the set of merged changes undergoes final QA, before being released into the "production" space.
In unenlightened corporate environments all three phases are handled within the team. However in open source communities the first phase can be handled by anyone (team members, invested stakeholders, or random altruists) – reducing some of the development burden on the team.
An enlightened corporate environment would borrow from the open source community: accept that all of its technical employees, across the entire organisation, are worthy and capable – and open up the first phase of the model to all of them.
The Payoff
Now, imagine this scenario:
You are at work. You identify an issue with WARMTH. You log in to an isolated DEV-WARMTH environment and makes some tweaks to the configuration that you think resolve your issue. Then, you submit your changeset to the WARMTH team along with a description of the issue it resolves.
At this point the WARMTH team would:
- evaluate / approve the issue (or reject it as not in line with the future vision for the service underpinned by the WARMTH system)
- QA the submitted changeset (check whether it resolves the issue, introduces regressions, meets coding standards, etc.)
- deploy the changeset
That's a lot less for the WARMTH team to do.
Of course, it won't always work. Sometimes an issue is too deeply entrenched, and requires to much specific knowledge of WARMTH and its complexities and idiosyncracies to be resolved. Sometimes the enhancement you propose doesn't mesh well with someone's vision of how WARMTH should work. Sometimes you just don't have the time or inclination to fix something for some other team.
And other times it might be difficult. Perhaps the change you make can't be communicated easily (the config isn't in version control, or isn't in a format that can be easily diff'ed, etc.). Perhaps your change doesn't resolve the issue or introduces regressions, so the WARMTH team still has to do all the identification/development work. Perhaps a swarm of bees rushes out of the air conditioning and engulfs you every time you log in to DEV-WARMTH (obviously the WARMTH team are specially trained to deal with this).
However the improvements to the service (some bugs are fixed in esse before they're even identified by the WARMTH team), workload (less pressure on the WARMTH team), buy-in (you feel like you have some input into WARMTH, and so become a little more invested), and knowledge sharing (something something silos) are self-evidently worth it.
Update [2017-06-22]:
I know the bees are a well-documented known risk, but not everything is like that. Here is another potential pothole on the path to paradise, to ponder, and possibly preempt:
Isolation isn't easy
- Some systems don't lend themselves to having multiple development spaces (because they're a pain to set up, or they're prohibitively large, or there are licensing issues, etc.)
- If there's a single DEV-WARMTH environment, your fiddling can interfere with other people's. (Including the WARMTH team's, which is arguably a higher priority than yours.)
In theory a good DevOps / automated deployment strategy can get around most of these issues (not licensing, alas), but an unenlightened corporate environment is not likely to have implemented a good DevOps / automated deployment strategy.
Perhaps that is the first step to enlightenment.