Automation has become a big buzz-word in OSS architecture. It’s all about the automation. At face value that’s great, it’s triggering an implication of bringing tangible business value to our OSS…. Except sometimes it’s not.
Our industry consists of so many incredibly clever engineers who love solving problems, which is great. The problem with automations is our engineers can leap straight to the automation as being the challenging problem to solve and completely forgetting that it’s actually the business value that’s the problem that needs solving.
Don’t just take my word for this, check out this 3 minute snippet from Elon Musk below talking about OSS/BSS design… or it could be about rocket design or Tesla design… I’m not sure. You be the judge. BTW. You can stop watching after 4:27 if you like, but there are a few other interesting ideas from Martin along the way, such as his quote, “I underestimated the problem and overestimated myself.” I’ve ticked that same box more times than I’d like to admit!!
Now, if you look a little closer at the video, you’ll notice that it’s actually an excerpt prepared by the inventor of Marble Machine X, a machine that’s probably aligned with some OSS/BSS designs – It’s beautifully engineered, an absolute piece of precision art. However, it arguably fails step 1 in Elon’s 5 step process – Make your requirements less dumb! It arguably also fails step 3 – The most common error of a smart engineer is to optimise the thing that should not exist!
Anyway, let’s do a recap of those five new rules of OSS/BSS design directly from the mouth of Elon Musk:
| Step | Elon’s Rules | Additional notes from Elon |
| 1 | Make your requirements less dumb | Your requirements are definitely dumb. It does not matter who gave them to you. It’s particularly dangerous if a smart person gave you the requirements because you might not question them enough. Everyone’s wrong, no matter who you are. |
| 2 | Delete the part or process | If you’re not occasionally adding things back in, you’re not deleting enough. |
| 3 | Simplify or optimize | It’s possibly the most common error of a smart engineer is to optimise the thing that should not exist. Everyone has been trained in high school and college that you’ve gotta answer the question. Convergent logic. So you can’t tell a professor [ed. or in our case a client] your question is dumb. You will get a bad grade. So everyone is basically, without knowing it, they’ve got a mental straight-jacket on. They’ll work on optimising the thing that should simply not exist. |
| 4 | Accelerate cycle time | You’re moving too slowly. You have to go faster. But don’t go faster until you have worked on the other three things first. If you’re digging your grave, don’t dig it faster. Stop digging your grave. |
| 5 | Automate | And then the final step is automate. Now I have personally made the mistake of going backwards on all five steps, multiple times. I automated, accelerated, simplified and then deleted. |
I couldn’t agree more. So many of our OSS/BSS designs are based on dumb requirements that keep perpetuating across the industry. So many of our cleverest people are jumping straight to step 5 to solve a problem. When it comes to OSS/BSS, it pays to walk before you run and question everything you see along the way before trying to automate it. There are so many examples where it just doesn’t make sense to automate. With OSS being software, we can do (almost) anything. But my motto – Just because we can, doesn’t mean we should!
To close out with a final caption from Martin……
BTW, if you’d like to watch the entire 53 minute source video of Elon, you can find it here https://www.youtube.com/watch?v=t705r8ICkRw but be warned that there’s a lot of rocket-scientist geekery going on throughout. Great if you like that kind of thing!!
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
