WDM, Product & Service Design, Customer Experience, Business Processes, DOS, Scope Creep

Post date: May 23, 2016 3:32:02 PM

A nice article about wdm networking technology. Nothing new, but a good quite compact summary. Works also as a good primer, so you know what you don't know and what to study more.
Read a book about Product & Service design. Service Design for Business: A Practical Guide to Optimizing the Customer Experience - Product & service design. User Interface Design, Usability Testing, Content Planning and Management, User Interaction design. User Experience Expert. User & Customer Centric Design. Service-Dominant Logic. Product & Service value. System Architecture. Business Logic. Business Consulting, Business Analytics & Business Intelligence. Enterprise Architecture. Different perspectives on project, system architect, management, project manager, developer, it department. Experimenting and Experimental software, quick iterations, lean development, lean management, lean project. Versus Completeness, Consistency, Correctness. Customer outcome, service channel, touchpoint, context. Value Proposal and Brand values. Customer Life-Cycle Map, Customer Journey Map, Service Blueprint. Innovations. Customer and Client feedback. Innovation verification process. Service script, service path. Key Performance Indicators (KPI). Cost to Serve. Information, Interaction, Transaction. Client / User story. Customer centric. Customer persona story. Service as a Product. IoT, customer targeting, customer analytics. Service Scalability. Minimum Viable Product (MVP). Building a perfect customer experience. Continuous iterative process. Optimizing customer service path. Process tools and process flow. Do not start with "This is how we've be always doing this". Measuring customer experience. New disruptive market players with new concepts or technologies. Process Visualization. Interactive process and user interface validation from other groups. Systemic approach to product & service development. Offer request, offer, contract, requirements specification, implementation, testing, reviews, changes, deployment, maintenance, bug fixes, updates. The never ending spiral of (analysis, evaluation, development, planning). Business process simulation. Information Systems helping in Decision Making. Strategic level, tactical level, operational level. Interaction, communication, collaboration.
After this it's funny to notice how some businesses are able to fail sales / customer service processes very badly. You just call them and tell that now it's time to cancel all the bleeping services. I've had this kind of experiences with Electricity Company and Telecom Operators. Most of then this is related to sales processes which are completely screwed. They fail to provide proper information about services etc. It's not too hard to follow normal concepts, where information about product and pricing is given and then customer can negotiate / decide if they want to order the service. Also these large companies often out source their sales, and this is one of the reasons why it's so utter crap. If they can't follow proper procedure, I might also forget the rules how things should be played. Usually these companies also make it very hard to make any changes or even cancel services. Which is just one extra nail to their coffin. Unfortunately I'm busy with other stuff. If I would have extra time, I could play some really nice games, reverse engineering their systems and checking if they have proper protections against internal system exploitation. In many cases it's easy to forget that threats can be internal, instead of only focusing on external threats. Actually they should pay me for doing basic system performance & security testing. Many services are out right slow / buggy. Which probably means that the quality isn't great, so it's also quite likely to find out something exploitable when exploring and experimenting with the system. Shouldn't the norm for system testing be that they've had the red team which has tried all possible ways to exploit / break the system? In many cases I've noticed that service service portals where customer is already authenticated and logged in, aren't nearly as well protected as 'public' services. If the credentials check process is light, great. But what if the customer stars to change email address million times per second? Or queries past invoices or something with extremely high rate? Or generally does something which isn't expected by the system designers and is something, which is deeply integrated into other systems and is therefore slow and the service hasn't ever been designed to be used as API with massive loads. This is especially true, if the service is such that it's limited to something like hardware devices which usually limit the performance / actions per second rate. But who says that someone couldn't replicate the protocol and do the same request at million actions per second compared to the normal rate? Just packet capture the protocol requests, write a custom client, modify payload and have fun. Replace random bytes or bits in that request and see if it causes any interesting effects etc. AFAIK, if services are properly done, none of this should have any effect. But we all know what the horrible reality of software quality is.
Somehow this reminded me from WinNuke, Ping of Death and one of my old cell phone Ericsson GH388. It had 160 character SMS message limit of course. But if I moved the cursor back from the end of message and inserted a new character in between the 160 characters long SMS message, it caused the phone to always boot. Fail.
One game platform always replicated the player list to all clients when it changed. Yet they didn't realize that I could change my user name in the game millions of times per second, basically causing all of the services outbound buffers to become totally flooded and finally crashing it. How stupid is that? Writing the code required really little extra work. Because as long as I had authenticated session, I only needed to capture the UDP packet as it was, and then change the required bytes and start sending it in massive quantities. The most trivial way of exploiting existing protocols with minimal amount of work.
So many projects with Scope Creep again... Aww... The usual case. - No details, but we all know it's the norm anyway. That's why I'm wondering what's the part worth of mentioning here. And it would be nice if it would ...