You've all probably seen this scene from the Tom Hanks movie, Apollo 13 right? But you're probably wondering what it has to do with OSS? Well, this scene came to mind when I was preparing a list of user stories required to facilitate Autonomous Networking. More specifically, to the use-case where we want the Autonomous Network to quickly recover (as best it can) from unplanned catastrophic…
Read More »I must've written dozens of posts about us needing to collectively invest a lot more effort into UI / UX. I've written quite a few over the last few months especially. This one in particular springs to mind. As an industry, we typically don't do user experience journeys (UX) or user interfaces (UI) very well at all yet. I know thousands of OSS experts, but only…
Read More »A slightly left-field thought dawned on me the other day and I'd like to hear your thoughts on it. We all know that almost all telemetry coming out of our networks is time-stamped. Events, syslogs, metrics, etc. That makes perfect sense because we look for time-based ripple-out effects when trying to diagnose issues. But therefore does it also make sense to geo-stamp telemetry data too? Just…
Read More »In yesterday's post, we talked about what needs to happen for a network operator to build an autonomous network. Many of the factors extended beyond the direct control of the OSS stack. We also looked at the difference between designing network autonomy for an existing OSS versus a ground-up build of an autonomous network. We mostly looked at the ground-up build yesterday (at the expense of…
Read More »....I want to make my network so observable, reliable, predictable and repeatable that I don't need anyone to operate it. That's clearly a highly ambitious goal. Probably even unachievable if we say it doesn't need anyone to run it. But I wonder whether this has to be the starting point we take on behalf of our network operator customers? If we look at most networks, OSS,…
Read More »"For those starting out in product, here's a tip: Design, Defaults*, Documentation, Details and Delivery really matter in software."Jeetu Patel here. * Note that you can interpret "Defaults" to be Out-Of-The-Box functionality offered by the product. Let's break those 5 D-words down and describe why they really matter to the OSS industry shall we? Design - The power of OSS product development tends to lie with…
Read More »In last Tuesday's post, I asked the community here on PAOSS and on TM Forum's Engage platform for ideas about how you would benchmark complexity. I also provided a reference to an old post that described the concept of a NSS (Net Simplicity Score) for our OSS/BSS. Due to the complexity of factors that contribute to a complexity score, the NSS is a “catch-all” simplicity metric. Hopefully…
Read More »It seems that OSS/BSS are always an afterthought. And always seen as a cost centre rather than a revenue generator. Now I'm biased of course, but I think that's such a narrow view. And we need everyone in our industry to spread the same gospel. I like to think of it like this... Sales teams identify the customers and revenue (let's call them THE BUY-SIDE). Network teams…
Read More »I'd love to ask you an important question... how do we benchmark OSS/BSS complexity? To measure how complex our systems are and therefore provide a signpost for simplification.A colleague has opined that the number of apps in a stack could be used a proxy. I can see where he's going with that, but I feel that it doesn't account for architectural differences such as monolith versus…
Read More »There's an old adage that "the confused mind always says no." Consider this from your own perspective. If you're in a state of confusion about something, are you likely to commit wholeheartedly or will you look to delay / procrastinate? The paradox for digital transformation is that our projects are almost always complex, but complexity breeds confusion and uncertainty. Transformation may be urgently needed, but it's…
Read More »In Monday's article, we suggested that the three technical factors that could get the big boss fired are probably only limited to: Repeated and/or catastrophic failure (of network, systems, etc) Inability to serve the market (eg offerings, capacity, etc) Inability to operate network assets profitably In that article, we looked closely at a human factor and how current trends of open-source, Agile and microservices might actually…
Read More »In Monday's article, we suggested that the three technical factors that could get the big boss fired are probably only limited to: Repeated and/or catastrophic failure (of network, systems, etc) Inability to serve the market (eg offerings, capacity, etc) Inability to operate network assets profitably In that article, we looked closely at a human factor and how current trends of open-source, Agile and microservices might actually…
Read More »In Monday's article, we suggested that the three technical factors that could get the big boss fired are probably only limited to: Repeated and/or catastrophic failure (of network, systems, etc) Inability to serve the market (eg offerings, capacity, etc) Inability to operate network assets profitably In that article, we looked closely at a human factor and how current trends of open-source, Agile and microservices might actually…
Read More »Not sure whether you have a clear answer to that question - either the thought is enticing (you want the CEO to get fired), unthinkable (you don't want the CEO fired) or somewhere in between. You'd invariably get different answers from different employees within most organisations (you can't please all of the people all of the time). Today's post also has no singular situation, so it…
Read More »I'm currently reading a book entitled, "Jony Ive. The genius behind Apple's greatest products." I'd like to share a paragraph with you from it (and probably expect a few more in coming days): "...Apple's internal culture heavily favored the engineers within the product groups. The design process was engineering driven. In the early days of Frog Design, the engineers had bent over backward to help implement…
Read More »When I first started the Passionate About OSS site / blog many years ago, I was lucky to get a handful of views per day. It's grown by many multiples since then, fortunately. The launch of The Blue Book OSS/BSS Vendor Directory generated some exciting metrics yesterday. The directory alone came within 5 pageviews of the highest count we've ever seen on PassionateAboutOSS.com (and PAOSS is…
Read More »We're excited to announce that “The Blue Book OSS/BSS Vendor Directory” has officially gone live here at https://passionateaboutoss.com/directory It provides a comprehensive directory of over 400 suppliers that produce OSS, BSS and/or related network management tools. Company details, product details and functionality classifications are included. Every network operator has a unique set of needs from their operational software – software that includes OSS (Operational Support Systems),…
Read More »We've spoken at length about TM Forum’s, “Time to kill the RFP? Reinventing IT procurement for the 2020s,” report so far this week. We've also spoken about the feeling that the OSS/BSS RFP (Request For Proposal) still has relevance in some situations... as long as it's more of a lighter-touch than most. We've spoken about a more pragmatic approach that aims to find best available fit…
Read More »Yesterday's post described the approach to get from 400+ possible OSS/BSS suppliers/products down to a more manageable list without: Having to get into significant discussions with vendors (yet) Gathering all your stakeholders together to prepare a detailed list of requirements We'll call this "the long list," which might consist of 5-20 suppliers. We use this evaluation technique (which we'll share more about on Monday) to ensure…
Read More »You may have noticed that we've run a series of posts about OSS/BSS procurement, and about the RFP process by association. One of the first steps in the traditional procurement process is preparing a strategy and detailed set of requirements. As TM Forum's, “Time to kill the RFP? Reinventing IT procurement for the 2020s,” report describes: "Before an RFP can be issued, the CSP’s IT or network…
Read More »As per yesterday's post, I'll continue to reference a TM Forum report called, "Time to kill the RFP? Reinventing IT procurement for the 2020s" today. Mark Newman and the team have captured and discussed so many layers to the OSS/BSS procurement process. There's no doubt the current stereotypical RFP approach to procurement is broken. It needs to be done differently. That's why we have been doing…
Read More »