Enabling connector experimentation
This weekend there was some great chat in the PP Admin WhatsApp group that I’m part of. It’s a pretty new group and a few dedicated channels have sprung up to share our collective knowledge on subjects like Administration, Licensing etc. In there anyone can ask any question and a bundle of people will then share their views, ideas, and links. It’s a great group and resource.
One of the questions asked this weekend was how we deal with requests to experiment with connectors and do we just open a DLP policy up for open experimentation. There were a few different perspectives shared but the theme was that opening up all connectors was as bad as crossing the streams in Ghostbusters, or similar to ‘driving a car with just your knees - you can do it but it’s not a good idea’, or ‘like wedging all the doors and windows of your house open before going to bed - you can do it but it’s not a good idea’ 😁
I thought this was a good topic for a blog post so as well as sharing my thoughts in that group I started to distill my ideas into a picture to share here too! This is that picture!
Process flow showing how connector experiment requests may progress and be managed
Inputs
One set of inputs is obviously those of the requester. They have an idea. They want to do a ‘thing’…. But is it just inquisitiveness to explore? Or do they want to do a Proof of Concept (PoC)? Or have they already done that at they now want to scale it and do a Proof of Value (PoV) experiment? What connectors do they want to experiment, combined with what? Using what data? Why? And how long is the experiment likely to last? Days? Weeks? Months? Years? All these answers help us understand the level of risk we’re dealing with.
We may also have some inputs to the experiment too. Perhaps we want them to test some stuff we’d be interested in finding out about that connector and how it might be used in the real world? We’d certainly be interested in the T-Shirt Size aligned to our Scalable Governance (read more on the scalable governance model here) so we can understand the risk of it and what the governance needs might be, and who we might need to consult, before enabling the experiment. Of course we’ll also need to understand what licenses are needed too.
Experiment
Assuming we’re all clear what our experiment is, what success would look like, how we need to manage the experiment, and are happy to progress, then we start! Hoorah!
To do this we need to create an environment (see my post on Environments to learn more) for the experiment to take place in, only grant access and permissions to those who we’ve agreed can experiment. By creating it as a Sandbox environment we can reset it with ease and, if needed, promote it to a Production environment at a later date.
Assuming this is an experiment on a premium connector or the organisation already has some Premium licenses I’d recommend setting them up as managed environments and controlling the sharing to whatever level has been agreed… Just to make sure there’s no temptation for the experiment to grow arms and legs and grow uncontrollably… it can happen when things go well 😁
We also need a DLP policy (read more on DLP Policy here) to enable the experiment. Rather than allowing the crazy scientists to be unleashed and people experimenting with anything and everything and creating all sorts of dangerous experiments we’ll provide the connectors that are needed for the experiment… no more, no less 😁
Then off our scientists go to experiment with us there to help and solve problems, and to keep an eye on what’s going on, of course. This is a partnership to achieve all of our experiment outcomes!
Experiment Outcome
At some point we’ll reach the end of the experiment - Hopefully we’ve learned what we set out to achieve, within the duration (or an extended duration) that we planned. We might have had to evolve our approach or solve challenges along the way. Our experiment will have either been a success or a ‘failure’ against our original goal…. But we can consider both results a success in the sense that we’ve learned something new and how the connector(s) can / can’t be applied.
Next Steps
So what do we do next? One option may be to do nothing… We learned. We decided that we can’t do it that way, or we don’t want to at this point in time… so we delete the environment and DLP policy and move on to our next piece of work or experiment…
But if we achieved an outcome that showed that it worked in the way we hoped then we may want to do more…. We may want to expand it out in demonstrating how it can work as part of a more complete process or at a greater scale and do a Proof of Concept (PoC) to… well… prove the concept! We need to take it through our governance processes to ensure our stakeholders and sponsors are onboard, and that we’re doing it in a compliant way.
Once developed we may want to show some of our users who are involved with that process and get them to test it to give us feedback and evolve it some more. We could continue to develop in our sandbox environment, but perhaps we want to create a Test environment so we can provide a bit more control.
We may have already proven the concept and we now want to do a Proof of Value (PoV) by getting some of those people to actually use the solution in their real role, perhaps in parallel to the official way of doing the task, to compare how much quicker, higher quality, lower waste, or better experience it is. It may make sense to do this in a Production environment to ensure we have sufficient resources and performance available to us to operate at a larger scale with a bigger audience.
Hopefully this gives an idea of how you can partner with your developers to unlock experimentation whilst ensuring we’re working within our governance to not introduce unplanned risk.
How do YOU enable experimentation?
If you find this post or any other of my posts useful please subscribe below to make sure you don’t miss out on future posts when they’re published! :)
