In yesterday's fourth part of this series about modern network service assurance, we wrote this: I also just stumbled upon OpenTelemetry, an open source project designed to capture traces / metrics / logs from apps / microservices. It intrigued me because just as you have the concept of traces / metrics / logs for apps, you similarly have traces / metrics / logs for networks. In…
Read More »Yesterday's post introduced the concept of active measurements as the better method for monitoring and assuring customer services. Like the rest of this series, it borrowed from an interesting white paper from the Netrounds team titled, “Reimagining Service Assurance in the Digital Service Provider Era.” Interestingly, I also just stumbled upon OpenTelemetry, an open source project designed to capture traces / metrics / logs from apps /…
Read More »Yep, this is the third part, so that might suggest that there were two lead-up articles prior to this one. Well, you'd be right: The first proposed that most of what we refer to as "service assurance" is really only "network infrastructure" assurance. The second then looked at the constraints we face in trying to reverse-engineer "network infrastructure" assurance into data that will allow us to…
Read More »In yesterday's article, we asked whether what many know as service assurance can rightfully be called service assurance. Yesterday's, like today's, post was inspired by an interesting white paper from the Netrounds team titled, "Reimagining Service Assurance in the Digital Service Provider Era." Below are three insightful tables from the Netrounds white paper: Table 1 looks at the typical components (systems) that service assurance is comprised…
Read More »I just came across an interesting white paper from the Netrounds team titled, "Reimagining Service Assurance in the Digital Service Provider Era." You can find a copy here. It's well worth a read, so much so that I'll unpack a few of the concepts it contains in a series of articles this week. It rightly points out that, "Alarms and fault management are what most people…
Read More »We sometimes attack OSS/BSS planning at a quite transactional level. For example, think about the process of gathering detailed requirements at the start of a project. They tend to be detailed and transactional don't they? This type of requirement gathering is more like the WHAT and HOW rings in Simon Sinek's Golden Circle. Just curious, do you have a persona map that shows all of the…
Read More »Last week we shared an article that talked about the different expectations from suppliers and clients when undertaking an OSS implementation project. The diagram below attempts to demonstrate the concept visually, in the form of three important sliders. When it comes to the technical delivery, it makes sense that most of the responsibility falls upon the supplier. They obviously have the greater know-how from building and…
Read More »Over the many OSS implementation projects I've worked on, UI/UX (user interface / user experience) has been an afterthought (if even thought about at all). I know there are OSS UI/UX experts out there (I've met a handful), but none have ever been assigned to the projects I've worked on unfortunately. UI has always just been the domain of the developer. If the functionality worked (even…
Read More »OSS implementations / transformations are always challenging. Stakeholders seem to easily get their heads around the fact that there will be technical challenges (even if they / we can't always get their head around the actual changes initially). When a supplier is charged with doing an OSS implementation, the client (perhaps rightly) expects the supplier to lead the technical implementation and guide the client through any…
Read More »I was speaking with a friend today about an old OSS assurance product that is undergoing a refresh and investment after years of stagnation. He indicated that it was to come with about 20 out of the box adaptors for data collection. I found that interesting because it was replacing a product that probably had in excess of 100 adaptors. Seemed like a major backward step...…
Read More »This is the third part of a series describing a really exciting analysis I've just finished. Part 1 described how we can turn simple log files into a Sankey diagram that shows real-life process flows (not just a theoretical diagram drawn by BAs and SMEs), like below: Part 2 described how the logs are broken down into a design tree and how we can assign weightings…
Read More »As the title suggests, this is the second part in a series describing a process flow visualisation, optimisation and decision support methodology that uses simple log data as input. Yesterday's post, part 1 in the series, showed the visualisation aspect in the form of a Sankey flow diagram. This visualisation is exciting because it shows how your processes are actually flowing (or not), as opposed to…
Read More »In your travels, I don't suppose you've ever come across anyone having challenges to capture and/or optimise their as-is OSS/BSS process flows? Once or twice?? :) Well I've just completed an analysis that I'm really excited about. It's something I've been thinking about for some time, but have just finished proving on the weekend. I thought it might have relevance to you too. It quickly helps…
Read More »"Whatever is well conceived is clearly said, And the words to say it flow with ease." Nicolas Boileau-Despréaux. I'd like to hijack this quote and re-direct it towards architectures. Could we equally state that a well conceived architecture can be clearly understood? Some modern OSS/IT frameworks that I've seen recently are hugely complex. The question I've had to ponder is whether they're necessarily complex. As the…
Read More »"...as technology gets more complicated, it becomes more difficult for buyers to acquire the skills needed to make even a basic assessment of value. Without such an assessment, it’s hard to get a project going, and in particular hard to get one going the right way." Tom Nolle. Have you noticed that over the last few years, OSS choice has proliferated, making project assessment more challenging?…
Read More »Over the years in OSS, I've spent a lot of my time helping companies create their OSS / BSS strategies and roadmaps. Sometimes clients come from the buy side (eg carriers, utilities, enterprise), other times clients come from the sell side (eg vendors, integrators). There's one factor that seems to be most commonly raised by these clients, and it comes from both sides. What is that…
Read More »For most end-customers, the OSS/BSS we create are merely back-office systems that they never see. The closest they get are the customer portals that they interact with to drive workflows through our OSS/BSS. And yet, our OSS/BSS still have a big part to play in customer experience. In times where customers can readily substitute one carrier for another, customer service has become a key differentiator for…
Read More »The last four posts have discussed how our OSS/BSS need to cope with different modes of working to perform effectively. We started off with the thread of "group flow," where multiple different users of our tools can work cohesively. Then we talked about how flow requires a lack of interruptions, yet many of the roles using our OSS actually need constant availability (ie to be constantly…
Read More »"I believe in the principle that deep work and constant availability are repulsive concepts (in the magnetic sense)." Tyler Mumford in comment 2 to this post. This blogging thing really amazes me at times. I'm regularly left shocked at the serendipitous connections that form when writing posts. Take today's post. I did a web search looking for the thread of an idea that had no relation…
Read More »Our most recent post last week discussed the research organisations like DARPA (Defense Advanced Research Projects Agency) and Google are investing into group flow for the purpose of group effectiveness. It cites the cost of training ($4.25m) each elite Navy SEAL and their ability to operate as if choreographed in high pressure / noise environments. We contrasted this with the mechanisms used in most OSS that…
Read More »Yesterday's post talked about the difference between "flow state" and "office state" in relation to OSS delivery. It referenced a book I'm currently reading called Stealing Fire. The post mainly focused on how the interruptions of "office state" actually inhibit our productivity, learning and ability to think laterally on our OSS. But that got me thinking that perhaps flow doesn't just relate to OSS project delivery.…
Read More »