The most basic form of densification involves increasing the number of cell towers. Problem is, that’s not really easy, particularly because network carriers are running into challenges with getting approval from local governments and landowners for adding new transmission points. The situation has become so challenging, in fact, that the US FCC recently had to issue a ruling clarifying the rules for 5G network infrastructure deployment. The new ruling essentially limits how much local governments can slow upgrades to existing network infrastructure, such as cell towers. Additionally, most of the early concepts for 5G densification depended on building and installing a lot of small cells—essentially shipping box- or even shoebox-size devices that could be used to enhance the network. The problem is, most of the small cell efforts were targeted towards mmWave, and it’s clear now that those efforts (and the technology overall) are going to take much longer to widely deploy than initially expected. Not only is it difficult to get small cells installed, the costs for the equipment remain high—and the ROI isn’t as clear for many network providers as they first thought.
Misalignments between teams can focus on priorities, scope or direction. Imagine that a team finds itself blocked as it is unable to finish a piece of work until work is completed by another team. The other team might not consider this a high priority item for them, in which case there is a misalignment of priorities. Or the other team might consider the work outside of their scope, in which case it needs to be resolved who should deliver the work. Or more seriously it could be a disagreement about direction - the other team might understand the request but consider it a bad request that they do not want to see fulfilled ... A common practice is to dedicate teams to particular features with an intended system. Each team has members with different specialisations and is intended to be able to build a ‘vertical slice’ of functionality that could be delivered to users. For example, the team wouldn’t contain only frontend developers so that they would have to wait for backend developers from another team in order to progress. Teams that provide outputs for other software teams rather than for users are called component teams rather than feature teams.
Research suggests that, prior to the coronavirus outbreak, only about 5% of the UK's 33 million workers worked mainly from home. Despite the regulations, it is relatively easy for employers to refuse a request for home working on one of the prescribed grounds outlined in the legislation, and employees have little opportunity for recourse. As such, presenteeism ruled: workers needed to be seen in the office to ensure they were working. Now, of course, everything has changed. As Wincanton CIO Richard Gifford recognises, the lockdown-enforced shift to remote working is a total reversal of the usual approach in most big companies until now. "Our HR policy was written in a way that previously, if you wanted to work at home, you could, but you'd have to come in and give some good reasons and a decision would be made. Now we're saying, 'you will work at home and you need to give me some good reasons why you need to be in the office'. So, it's a complete turnaround," he says. Gifford has had to maintain a limited on-site presence to manage his firm's on-premise data centre during the outbreak. Yet the vast majority of the firm's 4,500 office-based are working at home – and the result, aided by a solid VPN and a bunch of cloud applications, is likely to be a long-term shift in the perception of remote working.
If something goes wrong with a website or even an API, you can publish an updated version without the end user even being aware of it. Not so with mobile. If you release a new version, Apple and Google could take hours or days to approve and publish it. Even if you get it fast-tracked, and it is in the App Store hours later, you have no guarantee that the end-user will install the updated version with the fix. Which is why it is absolutely critical to have an API and mobile strategy and follow best practices when designing, developing, and publishing your mobile apps and APIs. ... When projects start going over-budget or over-time, proper testing is often one of the first things that gets cut or reduced. Your APIs and Mobile Apps need. You need a plan for this as well because having a few people randomly using the app IS NOT TESTING! As an enterprise business, you absolutely must have thorough test plans. This needs to be created by an experienced, senior QA Architect. If you are outsourcing your testing, get involved to see who is creating the plan and have a 2nd (or 3rd) set of eyes on the draft and final plans to be sure it is a solid and thorough plan.
MAUI is essentially the next evolution of Xamarin.Forms. It is a framework that will allow us to create native user interfaces for desktop and mobile devices, and the most surprising thing about this is that it has a single code base and a single project. In other words, no more different heads for each mobile OS (iOS and Android)! Alongside MVVM, MAUI will also support The Elm Architecture popularly known as the MVU (Model View Update) design pattern. MVU encourages a code-first development experience that rapidly updates the UI. Microsoft understands the power of the MVU pattern and has introduced a new unified way to build cross-platform native front ends from a single code base. ... With the arrival of MAUI, we will have a single project. We can also choose deployment between different devices or emulators even if we have a single project. But what about application resources like images? The tooling will manage shared sources on each platform as well as the management and creation of images adapted to each platform. ... MAUI is a renewed Xamarin.Forms with similar characteristics but greater features. The structure of Xamarin.Native (Xamarin.iOS and Xamarin.Android) will not change, only the name in .NET 6 will.
Based on the Deloitte survey results among executive decision-makers, network metrics don’t seem to be driving the shift as a majority of decision-makers are “satisfied” or “extremely satisfied” with a range of traditional performance characteristics of their current wireless networks, including reliability and resilience, data speed, latency, coverage, location accuracy, energy efficiency, and device density. What is driving the expected shift is that there are signs that organizations are looking beyond traditional network metrics such as reliability and coverage and are instead adopting advanced wireless technologies to hopefully unlock competitive advantage and create new avenues for innovation in their operations and offerings. What the survey stated is that the current technology is often considered to prevent them from addressing the innovative use cases they would like to target. This strong belief in the transformative power of advanced wireless connectivity is especially impressive, considering that both 5G and Wi-Fi 6 are the latest generations of technologies that originated more than 20 years ago and have been evolving ever since.
In an experiment created by the study authors, 302 examiners and/or doctors had to assess dermoscopic images of benign and malignant skin changes, both with and without the support of Artificial Intelligence. The AI assessment was provided in three different variants. In the first case, AI showed the examiner the probabilities of all possible diagnoses, in the second case the probability of a malignant change and, in the third case, a selection of similar images with known diagnoses, similar to a Google image search. As a main finding the authors observed that only in the first case did collaboration with AI improve the examiners' diagnostic accuracy, although this was significant, with a 13% increase in correct diagnoses. "Interestingly, less experienced examiners benefit more from AI support than experienced ones. Less experienced examiners trusted AI more than did the experienced ones. The latter only accepted the AI suggestions to change their original diagnosis in cases where they themselves were unsure," the authors wrote. A second experiment showed that all examiners, even acknowledged experts, can be misled by AI, if the output was changed to indicate false diagnoses.
MuleSoft's Anypoint Platform includes a native testing framework (MUnit) that allows Mulesoft experts to conduct unit and API tests on Mule apps. You can also mock APIs to run tests (shift left) before going live. However, MUnit specifically tests Mule flows. The reality is that today's average business transaction involves 35 or more API connections. While MUnit frees developers and engineers to productize APIs easily in Anypoint Studio, MUnit does not extend testing coverage to the APIs that are outside of your Anypoint platform. If solely depending on MUnit for global API quality, your team will not have the clarity to uphold internal and external SLAs for API uptime and performance. The ultimate goal of modern API testing is to ensure that functional, integration, performance, and data-driven tests capture the entire API consumer flow. This is primarily to catch the most common root cause of API problems: human error. ... With human error behind most of your current and future API quality headaches, you must ask whether siloed testing efforts, even if they are bridged by sending test result data to a platform like Elastic, can connect the dots to detect human error.
Effective governance of data and information risk management require discipline in specification: identifying and organizing the different types of data vulnerabilities, determining the threats that can exploit those weaknesses, understanding the scope of the consequences, and assessing the probability that a threat will take place and--if it does--assessing the probability that there will be consequences. You might think that the best approach would be enumerating the different vulnerabilities and then working from there to consider how those vulnerabilities can be exploited. And, in fact, there are some published guidelines and practices that suggest surveying your organization to assess, describe, and categorize risks as a prelude to developing controls and monitoring for information risk events. Yet, that approach may not be the most practical to take if your information risk management framework is to be aligned with resource allocation and preventative controls. One immediate challenge is that the domain of potential risks is expansive, and one can survey an entire enterprise of data assets and consider the risks before any substantive vulnerabilities are revealed.
There are a whole host of challenges that building these more complicated architectures create. I think it's definitely one of the top challenges we face. It depends on how distributed this architecture is, for any given application. But if you're ever depending on these edge devices, which may have keys that allow them to access your corporate corporate network, because they have to be able to send data back to your centralized system, you know security is a huge risk there. These are devices that are out in the field and have less physical security. A use case for one of our customers is that they have computers running our software on every train locomotive in North America. At every switch, and every train crossing are these shacks, at the side of the railroad tracks, hundreds of miles from civilization. Maintenance is an issue and security is an issue because potentially someone could walk up and tamper with these systems. So you need to make sure that the platform is secure from, you know, from the CPU off to avoid any sort of potential security risk.
Quote for the day: