The colour palette analogy of OSS

Let’s say you act for a service provider and the diagram below represents the number of variations you could offer to customers – the number that are technically supported by your solution.
13,824,000 Colours
That’s 13,824,000 colours.

By comparison, the following diagram contains just 20 colours:
20 Colours

If I asked you what colours are in the upper diagram, would you say red, orange, yellow, green, blue, etc? Is it roughly the same response as to the lower diagram?

If you’re the customer, and know you want an “orange*” product, will you be able to easily identify between the many thousands of different orange hues available in the upper diagram? Would you be disenfranchised if you were only offered the two orange hues in the lower diagram instead of thousands? Or might you even be relieved to have a much easier decision to make?

The analogy here to OSS is that just because our solutions can support millions of variants, doesn’t mean we should. If our OSS try to offer millions of variants, it means we have to design, then build, then test, then post-sale support millions of variants.

However, in reality, we can’t provide 100% coverage across so many variants – we aren’t able to sufficiently design, then build, then test, then post-sale support every one of the millions of variants. We end up overlooking some or accept risk on some or estimate a test spread that bypasses others. We’ve effectively opened the door to fall-outs.

And it’s fall-outs that tend to create larger customer dissatisfaction metrics than limited colour palettes.

Just curious – if you’ve delivered OSS into large service providers, have you ever seen evidence of palette analysis (ie variant reduction analysis) across domains (ie products, marketing, networks, digital, IT, field-work, etc)?

Alternatively, have you ever pushed back on decisions made upstream to say you’ll only support a smaller sub-set of options? This doesn’t seem to happen very often.

* When I’m talking about colours, I’m using the term figuratively, not necessarily the hues on a particular handset being sold through a service provider.

The PAOSS Call for Innovation has been released

I’ve been promising to release an OSS Call for Innovation, a manifesto of what OSS can become – a manifesto that also describes areas where exponential improvements are just waiting to happen .

It can be found here:
http://passionateaboutoss.com/oss-call-for-innovation/
And you’ll also notice that it’s a new top-level menu item here on PAOSS.

Each time I’ve released one of these vision-statement style reports in the past, I’ve been pleasantly surprised to find that some of the visions are already being worked on by someone in the industry.

Are there any visions that I’ve overlooked? I’d love to see your comments on the page and spread the word on all the amazing innovations that you’re working on and/or dreaming about.

Who can make your OSS dance?

OSS tend to be powerful software suites that can do millions of things. Experts at the vendors / integrators know how to pull the puppet’s strings and make it dance. As a reader of PAOSS, chances are that you are one of those experts. I’ve sat through countless vendor demonstrations, but I’m sure you’ll still be able to wow me with a demo of what your OSS can do.

Unfortunately, most OSS users don’t have that level of expertise, nor experiences or training, to pull all of your OSS‘s strings. Most only use the tiniest sub-set of functionality.

If we look at the millions of features of your OSS in a decision tree format, how easy will it be for the regular user to find a single leaf on your million-leaf tree? To increase complexity further, OSS workflows actually require the user group to hop from one leaf, to another, to another. Perhaps it’s not even as conceptually simple as a tree structure, but a complex inter-meshing of leaves. That’s a lot of puppet-strings to know and control.

A question for you – You can make your OSS dance, but can your customers / users?

What can you do to assist users to navigate the decision tree? A few thoughts below:

  1. Prune the decision tree – chances are that many of the branches of your OSS are never / rarely used, so why are they there?
  2. Natural language search – a UI that allows users to just ask questions. The tool interprets those questions and navigates the tree by itself (ie it abstracts the decision tree from the user, so they never need to learn how to navigate it)
  3. Use decision support – machine assistance to guide users in navigating efficiently through the decision tree
  4. Restrict access to essential branches – design the GUI to ensure a given persona can only see the clusters of options they will use (eg via the use of role-based functionality filtering)

I’d love to hear your additional thoughts how to make it easier for users to make your  (their) OSS dance.

Do we actually need less intellectual giants?

Have you ever noticed that almost every person who works in OSS is extremely clever?
No?

They may not know the stuff that you know or even talk in the same terminologies that you and your peers use, but chances are they also know lots of stuff that you don’t.

OSS sets a very high bar. I’ve been lucky enough to cross into many different industries as a consultant. I’d have to say that there are more geniuses per capita in OSS than in any other industry / sector I’ve worked in.

So why then are so many of our OSS a shambles?

Is it groupthink? Do we need more diversity of thinking? Do we actually need less intellectual giants to create pragmatic, mere-mortal solutions?

Our current approach appears to be flawed. Perhaps Project Platypus gives us on alternate framework?

Actually, I don’t think we need less intellectual giants. But I do think we need our intellectual giants to have a greater diversity of experiences.

Getting past the first layer on the OSS onion

When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can often times arrive at some very elegant and simple solutions.”
Steve Jobs
.

The quote above pretty well describes my experience with OSS. The first solutions we come up with for a given problem are generally very complex…. and that’s where we stop because there are so many other problems to move on to next.

Does that reflect your experiences too?

Do we ever get the chance to take a deep breath because we have all our roadmap items completed, and then therefore have time to peel more layers off old problems?

In my experience this just doesn’t happen. So that just leaves us with solutions that are complex… to the detriment of OSS as a whole.

So the question for you today is how to give the time and space to be able to peel more layers off our OSS onions?

My initial thought is that we should stop adding so many things into the roadmap – to take the 80/20 approach into our roadmap prioritisation – leaving more time to refine the really important stuff. I’d love to hear your thoughts though.

One of the biggest insights we had…

One of the biggest insights we had was that we decided not to try to manage your music library on the iPod, but to manage it in iTunes. Other companies tried to do everything on the device itself and made it so complicated that it was useless.”
Steve Jobs
.

How does this insight apply to OSS? Can this “off device” perspective help us in designing better OSS?

Let’s face it – many OSS are bordering on useless due to the complexity that’s build in to the user experience. So what complexity can we take off the “device?” Let’s start by saying “the device” is the UI of our OSS (although noting the off-device perspective could be viewed much more broadly than that).

What are the complexities that we face when using an OSS;

  • The process of order entry / service design / service parameters / provisioning can be time consuming and prone to errors,
  • Searching / choosing / tracing resources, particularly on large networks, can result in very slow response times,
  • Navigating through multiple layers of inventory in CLI or tabular forms can be challenging,
  • Dealing with fixed processes that don’t accommodate the many weird and wonderful variants that we encounter
  • Dealing with workflows that cross multiple integration boundaries and slip through the cracks,
  • Analysing data that is flawed generally produces flawed results
  • Identifying the proverbial needle in the haystack when something goes wrong
  • And many, many more

How can we take some of those complexities “off-device”

  • Abstracting order and provisioning complexity through the use of catalogs and auto-populating as many values as possible,
  • Using augmented decision support to assist operators through complex processes, choosing from layers of resources, finding root-causes to problems, etc,
  • Using event-based processes that traverse process states rather than fixed processes, particularly where omni-channel interactions are available to customers
  • Using inventory discovery (and automated build-up / tear-down in virtualised networks) and decision support to present simpler navigations and views of resources
  • Off-device data grooming / curation to make data analysis more intuitive on-device
  • etc

In effect, we’re describing the tasks of an “on-device” persona (typically day-to-day OSS operators that need greater efficiency) and “off-device” persona/s (these are typically OSS admins, configuration experts, integrators, data scientists, UI/UX experts, automation developers, etc who tune the OSS).

The augmented analytics journey

Smart Data Discovery goes beyond data monitoring to help business users discover subtle and important factors and identify issues and patterns within the data so the organization can identify challenges and capitalize on opportunities. These tools allow business users to leverage sophisticated analytical techniques without the assistance of technical professionals or analysts. Users can perform advanced analytics in an easy-to-use, drag and drop interface without knowledge of statistical analysis or algorithms. Smart Data Discovery tools should enable gathering, preparation, integration and analysis of data and allow users to share findings and apply strategic, operational and tactical activities and will suggest relationships, identifies patterns, suggests visualization techniques and formats, highlights trends and patterns and helps to forecast and predict results for planning activities.

Augmented Data Preparation empowers business users with access to meaningful data to test theories and hypotheses without the assistance of data scientists or IT staff. It allows users access to crucial data and Information and allows them to connect to various data sources (personal, external, cloud, and IT provisioned). Users can mash-up and integrate data in a single, uniform, interactive view and leverage auto-suggested relationships, JOINs, type casts, hierarchies and clean, reduce and clarify data so that it is easier to use and interpret, using integrated statistical algorithms like binning, clustering and regression for noise reduction and identification of trends and patterns. The ideal solution should balance agility with data governance to provide data quality and clear watermarks to identify the source of data.

Augmented Analytics automates data insight by utilizing machine learning and natural language to automate data preparation and enable data sharing. This advanced use, manipulation and presentation of data simplifies data to present clear results and provides access to sophisticated tools so business users can make day-to-day decisions with confidence. Users can go beyond opinion and bias to get real insight and act on data quickly and accurately.”
The definitions above come from a post by Kartik Patel entitled, “What is Augmented Analytics and Why Does it Matter?.”

Over the years I’ve loved playing with data and learnt so much from it – about networks, about services, about opportunities, about failures, about gaps, etc. However, modern statistical analysis techniques fall into one of the categories described in “You have to love being incompetent“, where I’m yet to develop the skills to a comfortable level. Revisiting my fifth year uni mathematics content is more nightmare than dream, so if augmented analytics tools can bypass the stats, I can’t wait to try them out.

The concepts described by Kartik above would take those data learning opportunities out of the data science labs and into the hands of the masses. Having worked with data science labs in the past, the value of the information has been mixed, all dependent upon which data scientist I dealt with. Some were great and had their fingers on the pulse of what data could resolve the questions asked. Others, not so much.

I’m excited about augmented analytics, but I’m even more excited about the layer that sits on top of it – the layer that manages, shares and socialises the aggregation of questions (and their answers). Data in itself doesn’t provide any great insight. It only responds when clever questions are asked of it.

OSS data has an immeasurable number of profound insights just waiting to be unlocked, so I can’t wait to see where this relatively nascent field of augmented analytics takes us.

Warring tribes and the five paper ball technique

The following extract from Ken Segall’s book, “Insanely Simple,” provides a great story on persuasion:
At one agency meeting with Steve Jobs, we were reviewing the content of a proposed iMac commercial when a debate arose about how much we should say in the commercial. The creative team was arguing that it would work best if the entire spot was devoted to describing the one key feature of this particular iMac. Steve, however, had it in his head that there were four or five really important things to say. It seemed to him that all of those copy points would fit comfortably in a thirty-second spot.
After debating the issue for a few minutes, it didn’t look like Steve was going to budge. That’s when a little voice started to make itself heard inside the head of Lee Clow, leader of the Chiat team. He decided this would be a good time to give Steve a live demonstration.
Lee tore five sheets of paper off of his notepad (yes, notepad—Lee was laptop-resistant at the time) and crumpled them into five balls. Once the crumpling was complete, he started his performance.
“Here, Steve, catch,” said Lee, as he tossed a single ball of paper across the table. Steve caught it, no problem, and tossed it back.
“That’s a good ad,” said Lee.
“Now catch this,” he said, as he threw all five paper balls in Steve’s direction. Steve didn’t catch a single one, and they bounced onto the table and floor.
“That’s a bad ad,” said Lee.
I hadn’t seen that one before, so I rather enjoyed it. And it was pretty convincing proof: The more things you ask people to focus on, the fewer they’ll remember. Lee’s argument was that if we want to give people a good reason to check out an iMac, we should pick the most compelling feature and present it in the most compelling way
.”

For most people in our industry, initiating OSS change is all about designing a technical solution that can fulfill a list of requirements. This may be effective in some situations, but in large carrier environments the bigger challenge is almost always in getting the many stakeholders contributing towards a common goal. If the project is big enough, multiple different business units will be involved and/or impacted. Each will tend to have their own objectives / metrics – and they’re often metrics that are misaligned or even in conflict – what common goal?

In the all-too-common “warring tribe” situation, persuasion techniques become essential. A great place to start is by creating an inspiring vision, much like John F Kennedy established when in 1961, he exhorted America to put a man on the moon before the decade was out.

There are many persuasion techniques, but I put them into two categories:

  • What you’re going to add
  • What you’re going to take away

I’m sure you want to go deeper, so Kellerman and Cole’s 64 Compliance-gaining Strategies give some great persuasive food for thought. Different strategies will work better/worse with different stakeholders of course, .

But to loop back to Ken Segall again, if you’re responsible for a significant change that crosses multiple domains and multiple stakeholders / influencers, you may choose to start with a vision based around the “most compelling feature and present it in the most compelling way.”

How many of you are wondering whether you could use the five paper ball technique to persuade in your next OSS stakeholder group when complexity is running rampant?

This is the best OSS book I’ve ever read

This post is about the most inspiring OSS book I’ve ever read, and yet it doesn’t contain a single word that is directly about OSS (so clearly I’m not spruiking my own OSS-centric book here 😉 ).
It’s a book that outlines the resolutions to so many of the challenges being faced by traditional communications service providers (CSPs) as well as the challenges faced by their OSS.

It resonates strongly with me because it reflects so many of my beliefs, but articulates them brilliantly through experiences from some of the most iconic organisations of our times – through their successes and failures.

And the title?

Insanely Simple: The Obsession That Drives Apple’s Success.
Book by Ken Segall.
Insanely Simple

OSS is downstream of so many Complexity choices that this book needs to be read far beyond the boundaries of OSS. Having said that, we’re incredibly good at adding so many of our own layers of complexity.

Upcoming blogs here on PAOSS will surely share some of its words of wisdom.

One unasked last question for OSS business cases

OSS business case evaluators routinely ask many questions that relate to key metrics like return on investment, capital to be outlaid, expected returns, return on investment, and more of the same circular financial questions. 🙂

They do also ask a few technical questions to decide risk – of doing the project or not doing the project. Timeframes and resources come into play, but again tend to land back on the same financial metric(s). Occasionally they’ll ask how the project will impact the precious NPS (Net Promoter Score), which we all know is a simple estimate to calculate (ie pluck out of thin air).

As you can tell, I’m being a little tongue-in-cheek here so far.

One incredibly important question that I’ve never heard asked, but is usually relatively easy to determine is, “Will this change make future upgrades harder?

The answer to this question will determine whether the project will have a snowballing effect on the TCO (total cost of ownership – yes, another financial metric that actually isn’t ROI) of the OSS. Any customisation to off-the-shelf tools will invariably add to the complexity of performing future upgrades. If customisations feed data to additional customisations, then there is a layer multiple to add to the snowball effect.

Throw in enough multi-layered (meshed?) customisations and otherwise routine upgrades start to become massive undertakings. If upgrades are taking months of planning, then your OSS clearly no longer facilitates the level of flexibility that is essential for modern service providers.

The burden of tech-debt insidiously finds its way into OSS stacks, so when evaluating change, don’t forget that one additional question, “Will this change make future upgrades harder?

OSS brand building with the simple stick

Today’s consumers want to get the best prices, but offering your brand at a discount can undermine profits and threaten viability. Smart brands utilize strategies to create and sustain a meaningful difference that helps consumers justify spending more.”
Nigel Hollis
, in his PoV on branding.

I once read a statistic that at one point Apple owned 6.5% of the total handset market, but accounted for 75% of the entire industry’s operating profit. Now that’s a premium brand!

Whilst some in the OSS industry may claim their brand is the strongest, none come close to having the fanatic customer base that Apple has built. This makes me ponder what it would take to create a truly premium OSS brand.

People buy a premium brand for the enjoyment it brings them, either in the experience, the status, the prestige, the satisfaction of having a need met efficiently and probably many other variants on these reasons.

Three questions for you:

  1. For how many customers is the OSS buying experience an enjoyable one?
  2. For how many customers is the implementation / integration experience an enjoyable one?
  3. For how many customers is the user experience an enjoyable one?

Actual customer experiences in relation to the questions above might be 1) Confusing, 2) Arduous and 3) Unintuitive.

I’m going to take a completely contrarian view because the status quo clearly isn’t working. This contrarian view focuses squarely on simplicity. It seems that our developers are always building new functionality. However, most of the OSS functionality that users will ever need has already been around for decades. Rather than new functionality, how about a focus on making old functionality vastly more simple?

Rather than with Engineers, how about beating OSS with the simple stick by engaging marketers, designers, artists, stylists – the creatives – to improve the three experiences above?

The mafia… Pressure? What pressure?

OSS delivery teams can be quite tense environments to work within can’t they? Deadlines, urgency, being in the customer’s line of sight and did I mention deadlines? [As an aside, I’m not sure which type of deadline is more stressful, the ongoing drain of fortnightly releases under Agile, or the chaos of a big-bang release that is preceded by lengthier periods of relative calm.]

When it comes to dealing with stress, I see two ends of a continuum:

  • The teflon end – get it off me, get it off me – the people who, when under stress, push stress onto everyone else and make the whole team more stressed
  • The sponge end – the people who are able to absorb the pressure around them and exude a calm that reduces stress contagion

I can completely understand those who fall at the teflon end, but I can’t admire them or aspire to work with them. I’m sure most would feel the same way. They let urgency overwhelm logic.

This reminds me of a project where the mafia were tightly entwined into a customer’s project team and they were constantly wrangling scope, approvals and payments to ensure “the organisation” profited. They were particularly “active” around delivery time.

A biggest of big-bang deliveries required me to stand in front of a large customer contingent for three days straight to demonstrate functionality and get grilled about processes, tools and data sets. At the end of the third day, we’d scheduled the demonstration of some brand new functionality.

It was a module that had been sold to the customer before even being conceptually architected let alone built. [You know the story – every requirement on an RFP must be responded to with a “Complies” even if it doesn’t]. My client (the vendor) was almost ready to back away from this many-million dollar contract due to the complexity and time estimated to build the entirely new module from scratch. I stepped in and proposed a solution that stitched together four existing tools, some glue and only a few weeks of effort… but we’d never even had it working in the lab before entering into the demo.

At first pass, the demo failed. Being at the end of the three-day demo (and the hectic weeks leading up to it), my brain was fried. The customer agreed to take a short break while we investigated what went wrong. We were struggling to find a resolution, so I was proposing to delay demonstration of the new tool until the following day.

Luckily for me, the most junior member of our team sat in the background plugging away, trialling different fixes. He tapped me on the shoulder and told me that he thought he’d resolved the problem.

We regathered the customer’s team and presented the new module. We waited for the customer’s lead to push an unknown configuration into the network and waited for him to check whether our new tool had responded correctly. It did and the customer was ecstatic.

We’d been saved by a very clever young man with an ability to absorb pressure like a sponge. I couldn’t thank him enough.

If you can’t repeat it, you can’t improve it

The cloud model (ie hosted by a trusted partner) becomes attractive from the perspective of repeatability, from the efficiency of doing the same thing repeatedly at scale.”
From, “I want a business outcome, not a deployment challenge.”

OSS struggles when it comes to repeatability. Often within an organisation, but almost always when comparing between organisations. That’s why there’s so much fragmentation, which in turn is holding the industry back because there is so much duplicated effort and brain-power spread across all the multitude of vendors in the market.

I’ve worked on many OSS projects, but none have even closely resembled each other, even back in the days when I regularly helped the same vendors deliver to different clients. That works well for my desire to have constant mental stimulation, but doesn’t build a very efficient business model for the industry.

Closed loop architectures are the way of the future for OSS, but only if we can make our solutions repeatable, measurable / comparable and hence, refinable (ie improvable). If we can’t then we may as well forget about AI. After all, AI requires lots of comparable data.

I’ve worked with service providers that have prided themselves on building bespoke solutions for every customer. I’m all for making every customer feel unique and having their exact needs met, but this can still be accommodated through repeatable building blocks with custom tweaks around the edges. Then there are the providers that have so many variants that you might as well be designing / building / testing an OSS for completely bespoke solutions.

You could even look at it this way – If you can’t implement a repeatable process / solution, then measure it, then compare it and then refine it, then you can’t create a customer offering that is improving.

In desperate search of OSS flow

Flow, also known as the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does, and a resulting loss in one’s sense of space and time.”
Wikipedia.

It’s almost definitely no coincidence that a majority of the achievements I’m most proud of within the context of OSS have been originated outside business hours. I strongly believe it all comes down to flow. In a day that is punctuated by meeting after meeting, there is no flow, no ability to get into deep focus. In the world of transaction-based doing, there is rarely the opportunity to generate flow.

Every OSS project I’ve worked on has been in desperate need of innovation. That’s not a criticism, but a statement of the whole industry having so many areas in which improvement is possible. But on your current and/or past projects, how many have fostered an environment where deep focus was possible for you or your colleagues? Where have your greatest achievements been spawned from?

Jason Fried of Basecamp and 37signals fame is an advocate of building an environment where flow can happen and starts with manager and meeting minimisation. The best managers I’ve worked with have been great at facilitating flow for their teams and buffered them from the M&M noise.

How can we all build an OSS environment where the thinkers get more time to think… about improving every facet of ideating, creating, building and implementing?

Use cases for architectural smoke-tests

I often leverage use-case design and touch-point mapping through the stack to ensure that all of the use-cases can be turned into user-journeys, process journeys and data journeys. This process can pick up the high-level flows, but more importantly, the high-level gaps in your theoretical stack.”

Yesterday’s blog discussed the use of use cases to test a new OSS architecture. TM Forum’s eTOM is the go-to model for process mapping for OSS / BSS. Their process maps define multi-level standards (in terms of granularity of process mapping) to promote a level of process repeatability across the industry. Their clickable model allows you to drill down through the layers of interest to you (note that this is available for members only though).

In terms of quick smoke-testing an OSS stack though, I tend to use a simpler list of use cases for an 80/20 coverage:

  • Service qualification (SQ)
  • Adding new customers
  • New customer orders (order handling)
  • Changes to orders (adds / moves / changes / deletes / suspends / resumes)
  • Logging an incident
  • Running a report
  • Creating a new product (for sale to customers)
  • Tracking network health (which may include tracking of faults, performance, traffic engineering, QoS analysis, etc)
  • Performing network intelligence (viewing inventory, capacity, tracing paths, sites, etc)
  • Performing service intelligence (viewing service health, utilised resources, SLA threshold analysis, etc)
  • Extracting configurations (eg network, device, product, customer or service configs)
  • Tracking customer interactions (and all internal / external events that may impact customer experience such as site visits, bills, etc)
  • Running reports (of all sorts)
  • Data imports
  • Data exports
  • Performing an enquiry (by a customer, for the purpose of sales, service health, parameters, etc)
  • Bill creation

There are many more that may be required depending on what your OSS stack needs to deliver, but hopefully this is a starting point to help your own smoke tests.

Use-case driven OSS architecture

When it comes to designing a multi-vendor (sometimes also referred to as best-of-breed) OSS architecture stack, there is never a truer saying than, “the devil is in the detail.”

Oftentimes, it’s just not feasible to design every interface / integration / data-flow traversing a theoretical OSS stack (eg pre-contract award, whilst building a business case, etc). That level of detail is developed during detailed design or perhaps tech-spikes in the Agile world.

In this interim state, I often leverage use-case design and touch-point mapping through the stack to ensure that all of the use-cases can be turned into user-journeys, process journeys and data journeys. This process can pick up the high-level flows, but more importantly, the high-level gaps in your theoretical stack.

A new, more sophisticated closed-loop OSS model

Back in early 2014, PAOSS posted an article about the importance of closed loop designs in OSS, which included the picture below:

OSS / DSS feedback loop

It generated quite a bit of discussion at the time and led me to being introduced to two companies that were separately doing some interesting aspects of this theoretical closed loop system. [Interestingly, whilst being global companies, they both had strong roots tying back to my home town of Melbourne, Australia.]

More recently, Brian Levy of TM Forum has published a more sophisticated closed-loop system, in the form of a Knowledge Defined Network (KDN), as seen in the diagram below:
Brian Levy Closed Loop OSS
I like that this control-loop utilises relatively nascent technologies like intent networking and the constantly improving machine-learning capabilities (as well as analytics for delta detection) to form a future OSS / KDN model.

The one thing I’d add is the concept of inputs (in the form of use cases such as service orders or new product types) as well as outputs / outcomes such as service activations for customers and not just the steady-state operations of a self-regulating network. Brian Levy’s loop is arguably more dependent on the availability and accuracy of data, so it needs to be initially seeded with inputs (and processing of workflows).

Current-day OSS are too complex and variable (ie un-repeatable), so perhaps this represents an architectural path towards a simpler future OSS – in terms of human interaction at least – although the technology required to underpin it will be very sophisticated. The sophistication will be palatable if we can deliver the all-important repeatability described in, “I want a business outcome, not a deployment challenge.” BTW. This refers to repeatability / reusability across organisations, not just being able to repeatedly run workflows within organisations.

I want a business outcome, not a deployment challenge

We can look and take lessons on how services evolved in the cloud space. Our customers have expressed how they want to take these services and want a business outcome, not a deployment challenge.”
Shawn Hakl
.

Make no mistake, cloud OSS is still a deployment challenge (at this nascent stage at least), but in the context of OSS, Shawn Hakl’s quote asks the question, “who carries the burden of that deployment challenge?”

The big service providers have traditionally opted to take on the deployment challenge, almost wearing it as a badge of honour. I get it, because if done well, OSS can be a competitive differentiator.

The cloud model (ie hosted by a trusted partner) becomes attractive from the perspective of repeatability, from the efficiency of doing the same thing repeatedly at scale. Unfortunately this breaks down in a couple of ways for OSS (currently at least).

Firstly, the term “trusted partner” is a rare commodity between OSS providers and consumers for many different reasons (including trust from a security perspective, which is the most common pushback against using hosted OSS). Secondly, we haven’t unlocked the repeatability problem. Every organisation has different networks, different services, different processes, even different business models.

Cloud-hosted OSS represents a big opportunity into the future if we first focus on identification of the base ingredients of repeatability amongst all the disparity. Catalogs (eg service catalogs, product catalogs, virtual network device catalogs) are the closest we have so far. Intent abstraction models follow this theme too, as does platform-thinking / APIs. Where else?

Be afraid, be very afraid

Just because you’re afraid of doing something doesn’t give you a permission slip to not do it.”
Debbie Millman
.

There’s a lot of fear in OSS. So many things can go wrong (the OctopOSS theory), so much incompetence is created, so many nearly insurmountable integration challenges await and their complexity means that there is no perfect plan going into a project.

They do require a leap of faith, a confidence in your team to work your way through all the challenges and a commitment from senior stakeholders to help drive change through (with compassion for those whose working life is about to be impacted of course). They also need an eye for simplification, like the Mechanical Turk model.

Oh, and I’d like you to have a think about how the momentum spiral or corkscrew model might help you to get from afraid to delivered.

How would Einstein or Darwin manage an OSS?

Here are a few questions I reflect on:
– Am I excited to be doing what I’m doing or am I in aimless motion?
– Are the trade-offs between work and my relationships well-balanced?
– How can I speed up the process from where I am to where I want to go?
– What big opportunities am I not pursuing that I potentially could?
– What’s a small thing that will produce a disproportionate impact?
– What could probably go wrong in the next 6 months of my life?

Zat Rana
on here on Business Insider.

The link above provides some insights into the way some of the world’s greatest innovators have tackled the challenges that lay before them. It espouses the benefits of Reflective Thinking versus the current mindset of Doing Thinking, as discussed here earlier.

If you were to follow Zat Rana’s suggestion of allocating two hours a week to reflective thinking, what are the seed questions you could ask? Would the list above work as a starting point? Perhaps something more specific to your situation?

Here are a few other possibilities:

  • Do I know what (my) OSS will look like in 5 years
  • Am I satisfied that (my) OSS is actually helping outside operations
  • What tangents could (my) OSS take to improve the world
  • Where does complexity stem from that impacts (my) OSS
  • Which areas can I pare back with negligible impact
  • What is the OSS moonshot that changes the landscape forever
  • What is my lead domino(es) (ie What’s a small thing that will produce a disproportionate impact?)
  • Have I thought about what might impact business continuity
  • How can I impact the bigger bodies (eg CSPs, vendors, standards bodies) around me