Summary: As part of my work in the field of the Digital Workplace I get asked one question a lot (even though I am not really a technology expert): “It’s 2016. Can’t we just buy this as a box somewhere?”. My answer to that is always: “Depending on how flexible you are as an organisation and what you mean by ‘box’.” So, this article is my personal(!) angle on the three main options to deliver modern digital services (probably as blurry as communication & collaboration in its scope). Personal angle, because I am not an analyst and because I don’t have the ambition to come across as one. My point of view is primarily driven by my experience in projects when I represent the business side of things.
I sincerely believe that we are moving out of the age of proprietary and specification driven development. Two factors seem to influence this with tremendous momentum:
- The substantial change of quality SaaS (that’s what we used to call the cloud in the old days) provides on almost all levels: scope, easy-of-use, governance, performance, availability, evolution/roadmap, mobility etc.
- The lack of effectiveness in allocating OPEX and CAPEX to infrastructure and systems that aren’t remotely core to the source of business
A third seems to emerge as well: compliance. In various projects (and it feels like a trend already) business owners have made sure that data touched by the project is business critical but not regulated! This means that there is very little legal leverage to argue “cloud security” by principle. For non-regulated content it’s almost a guarantee that cloud vendors have a better angle on data security than the heavy metal t-shirted guys in your basement.
The most significant change in this new playground: requirements engineering.
To play with boxes or modular systems requires new rules. The best way to determine, if you play by these new rules, is to never need a specification. In the new world, requirements and processes have to adapt to the capabilities of the target infrastructure and solutions (or the combination of modules/solutions therein). There simply isn’t the option to ask for the button on the upper right instead of a text link on the lower left anymore. The designers of the box want it up there, and if you don’t like it: get another box!
Organisations have to even learn a different way of determining requirements. They have to leave wiggle room to ready-to-use services in order to address the requirements properly. That requires intellectual flexibility on all sides: business stakeholders as well as (internal) solution experts. Therefore new methods of requirements engineering and documentation are needed.
Let’s talk about the scenarios
The following part of this article will only refer to three scenarios but not solutions or platforms that might fall into those. Primarily because I don’t want this article to be perceived as “analyst material” but more importantly because the “modular” scenario can be built from more than one solution/platform/service.
In order to provide the core content of this article in a somehow re-usable format I will use a structure: my take on each option divided by
- non-DWP analogy
- key questions in the business context
Firstly this structure will help to align my point of view with yours, the reader (most likely not always 100% matching). Secondly I want to provide inspiration for readers that are confronted with the decision between the scenarios and seek for additional input for the decision process.
You buy a space ship in a toy store. It’s called “space ship” and it comes in one piece – as a space ship.
You know what you get. You know what to expect and so does everyone who’s going to play with you. If your play requires space travel, interstellar transport and artificial gravity, you’re all set.
The play is limited to the context in which a space ship makes sense. To play “summer camp 2014” will require a lot of creativity in
- framing (change management)
- execution (user experience & add value)
- adaption (requirements re-engineering)
Questions in a business context
- Are your business requirements clear enough so that you can determine a (reasonable) match with a technology? Do you need a space ship?
- Can everyone use the new box? (e.g.: do you infinite bandwidth everywhere?)
- Have you made sure that “out of the box” doesn’t mean “out of the boxISH” in the vendor’s sale pitch? In German you say “Auslegungssache” ;o)
- Do you know all the other boxes in your company? Do you know the boxes that will be brought in in the near future? Do you understand how things will play together or create redundancy?
- Are your functional requirements flexible enough so that they can adapt to how things are done within the new box?
- Is your organisational willing to change the current standards (processes, ways of working, guidelines etc.) so that YOU will be compliant with the new box (not the other way around)?
Option 2: Modular
You buy a construction set to build a space ship. The set it build from some common standards and some space ship specific pieces. *
You are way more flexible in your play. You can adapt the space ship depending on space ship play relevant factors. You don’t even have to use all pieces and still build a space ship. Some standards in the set will help you to address needs that aren’t specific to space ship plays.
If you don’t follow the exact (child proof) plan on how to build the space ship you need the experience (not just the vision) on how to build a space ship. Not everything you can build from a space ship construction set will be a space ship, which might be confusing to others.
You need a solid understanding for the priorities in your space ship play, so that you can cater to them. If you leave pieces out you need a reason-why. If you leave out all the space ship specific pieces, there was no need to buy the set in the first place.
Questions in business context
- Do you have a plan? (literally)
- Do you have internal competence to work with and maintain construction sets? It is a different ball game compared to standard solution operations…
- Have you matched your plan to the construction set?
- If you leaves pieces out, do you have a reason-why for the ones that “always wanted something like that”?
- If you start small, do you have a roadmap for adding the other pieces?
- Does your construction set play well with other sets and boxes in your organisation? Does it have to?
Option 3: Custom
The following statements will make you feel that I am not necessarily a “custom” fan anymore. However, there can be good reasons to go fully customised. It’s all a matter of requirements engineering and cost/benefit analysis.
You get some raw material and you build a space ship.
It’s the space ship that fits a specification, which was built on known requirements. It’s yours. You are in charge, if you don’t sell and lease it back…
- Your requirements have to be spot on (correct and complete)
- Your specification has to be spot on (correct and complete…and ideally tested)
- Prioritised requirements automatically lead to a roadmap and release management. It’s good to have the future 1.5 releases in mind to avoid “cul-de-sacs”.
- You better test your space ship before you fly off because it’s a brand new space ship
(Pragmatic) questions in business context
- There is really no box out there that would fit your requirements? Really, really?
- Is “custom” connected to the people in charge? (that’s always how we’ve done it)
- Could you adjust your requirements to fit a box or a construction set?
- Could you change (like in: processes, ways of working, etc.) to become more box or construction set compatible?
- Could you win your CFO over to your team by creating a business case that sets out
- benefits of generally changing “ways of working” (aka organisational evolution)
- freed up CAPEX and OPEX for more core business focussed actions
* “Modular” can stand for “built from multiple specialised/best of breed solutions” as well. The available eco system of services simply becomes the construction set.