At first, you’re like, “oh, another piece where someone makes fun of us nerds and misunderstands our damagingly sarcastic way of saying everything that belies the privilege we all live under.” Then you’re like, “oh, this is actually a good piece.” E.g.:
Human rights work attempts to prevent the abusive deployment of power against those who have little of it. While technology might disrupt some power structures, it might also reinforce them, and it is rarely designed to empower the most vulnerable populations. Human rights defenders are innovative, and they have used software to do work it wasn’t designed to do, such as live-streaming police violence against civilian populations to press for government accountability. But perpetrators of mass violence are innovative too. Software alone is unlikely to provide clear human rights victories.
Assuming that adopting the tool is feasible, do the benefits this tool provides outweigh the cost of disrupting your existing workflow?
People rarely consider that, in all walks of life.
Source: Tech folk: ‘Move fast and break things’ doesn’t work when lives are at stake
Whether it’s “DevOps,” “digital transformation,” or even “cloud” and “agile,” middle-management is all too common an issue. They simply won’t budge and help out. This isn’t always the case for sure, but “the frozen middle” is a common problem.
With a big ol’ panel of people (including two folks from RedMonk), we talk about tactics for thawing the frozen middle.
There’s a pretty good, brief overview of what all this digital, IoT, etc. stuff could mean for the auto industry by Victor Kingery (of GE) over on DZone.
He outlines are three areas:
- Connected cars – gathering all the info onboard and using it for, at least, preventive maintenance and some auto insurance tweaking.
- Self-driving cars – “More than likely, semi-autonomous vehicles will allow for the mundane tasks of driving to be done by the vehicle’s computers, such as monotonous highway driving, but allow the driver to take over the vehicle when compelled to do so due to unforeseen circumstances.”
- Electric vehicles – “It will take more than automakers improving battery technology. It will take governments and private business working together to create the infrastructure to enable wide scale battery recharging possible.”
Source: “Automotive Evolution and Digital Industrial Transformation.”
One current attempt at machine-made burgers comes from a San Francisco startup called Momentum Machines, whose founders have estimated that their burger-making robot will save the average restaurant $135,000 a year in wages. Momentum says their machine can also customize burgers to include different blends of meat and special cheeses, neither of which the AMFare could handle. “Our device isn’t meant to make employees more efficient,” co-founder Alexandros Vardakostas has said. “It’s meant to completely obviate them.”
Also, one of the better headlines you’ll see today: “America has been trying to automate cheeseburgers for more than 50 years”
From a 451 report on outsourcing in cloud-land:
From our Voice of the Enterprise research, we can see that about two-thirds of organizations are operating with moderate transformation, while a fifth describe themselves as undertaking significant transformation.
And what do these new projects look like?
In the manufacturing sector and in transaction-heavy back-office process areas, automation continues to improve the top line for businesses. In banking, financial services and insurance, the main challenge is how to manage compliance cost-effectively so that productivity is not impacted.
Source: “The curious case of cloud services and the demise of multi-sourcing.”
…a survey of the top retailers in the US and Europe. About 75 percent of them said that despite all the unprecedented investments they’ve made in retail over the last several years, they feel ill-prepared to handle and provide omni-channel capabilities.
Meanwhile, it’s clear that you need so look at online as the starting point of most purchases: “60 percent or more of in-store purchases start online ‘through digital engagement.’”
Amazon is quick to enter new retail markets:
Amazon reports e-commerce growth of 30 percent, whereas core retail is growing at only 2 percent. Amazon Fashion launched in a “very nascent way” in 2002 – it’s now the biggest fashion player in the U.S. Amazon has spent about $17 billion dollars on R&D around e-commerce. Walmart has spent under a billion. If Walmart cannot spend the money necessary to stay with Amazon, how will other retailers keep pace?
All of this was from a SFDC retail-focused person, no details on the survey.
Source: Salesforce Commerce Cloud CEO at NRF – 75 percent of retailers are “ill-prepared” for the omni-channel
Reda Hmeid over at InfoQ does a good job at trying to define “digital”:
Being Digital is the re-imagining of business processes to be by default a fully online, fully automated process from end user interaction to back office processing, with no need for human intervention.
…down to several characteristics of such an approach like immediate process loops for end-users (“real time”), automating most everything, being online, and well designed.
Source: What Does “Being Digital” Actually Mean?
At the top of the year, companies are setting their IT agendas. Most high level executives seem to be lusting for “digital transformation,” but that phrase is super-squishy. In my Register column this month, I offered my advice on what it should be: simply “digitizing” existing, manual work-flows by perfecting how you do software.
This, of course, is the core of what I work on at Pivotal; see my wunderkammer of knowledge, the soon to be PDF’ed “Crafting your cloud native strategy,” for example.
What do these opportunities look like in businesses? Here’s a chunk that cut out of the piece that provides some examples:
A project to “digitize” the green card replacement program in the US provides a good example of the simple, pragmatic work IT departments should be curating for 2017. Before injecting software into process it’d “cost about $400 per application, it took end user fees, it took about six months, and by the end, your paper application had traveled the globe no less than six times. Literally traveled the globe as we mailed the physical papers from processing center to processing center.”
After discovering agile and cleaning up the absurd government contracting scoping (a seven year project costing $1.2bn, before accounting for the inevitable schedule and budget overruns), a team of five people successfully tackled this paper-driven, human process. It’s easy to poke fun at government institutions, but if you’ve applied for a mortgage, life insurance, or even tried to order take out food from the corner burger-hut, you’ll have encountered plenty of human-driven processes that could easily be automated with software.
After talking with numerous large organizations about their IT challenges, to me, this kind of example is what “digital transformation” should mostly about, not introducing brain-exploding, Minority Report style innovation. And why not? McKinsey recently estimated that, at best, only 29% of a worker’s day-to-day requires creativity. Much of that remaining 71% is likely just paid-for monotony that could be automated with some good software slotted into place.
That last figure is handy for thinking about the opportunity. You can call it “automation” and freak out about job stealing, but it looks like a huge percentage of work can be “digitized.”
Check out the full piece.
My co-worker Richard wrote up a laundry list of tactics to cultivate and maintain developer skills. It’s drawn from the tactics we’re seeing organizations put in place and a recent survey from the Cloud Foundry Foundation.
While I used to scoff at internal brown bags and workshops, I’ve seen those be highly effective in organizations looking to buff up at their developer skills. It both transmits actually new information and shows developers that the company actually cares. Upping morale and skills is hard to beat.
Also, it looks like the continual cross-training you get from pair programming is effective. Staff keeps up to date from the micro level of new keyboard short cuts to the big picture stuff like architectural patterns and domain knowledge. Plus, they learn and practice working together and trusting each other.
More survey findings
The developer survey that Richard kicks off with has some more interesting answers. Here’s some details from the survey:
– “By a nearly 2:1 margin, they are choosing training over hiring or outsourcing as the preferred method for addressing a shortage of skills in their own companies.”
– “We suspect that the companies further along in their cloud journey are doing more interesting things and are more risk tolerant; developers find those jobs more attractive. However, those companies that still primarily rely on legacy architectures, don’t push the envelope or are only very sluggishly making efforts toward digital transformation, struggle to hire and retain people that have the skills necessary.”
– “the majority of companies (62%) express confidence in the abilities of their developers to “keep current” with their IT knowledge and skills. At an individual level, however, only 47% of developers express confidence in their own ability to keep current.”
– “By a large percentage (60%), companies say they first adopt a technology—then upskill, train, or hire as necessary. This is preferred to selecting a new technology based on the skills already available in the company (40%).”
– “By and large, companies are addressing the shortage of skills by training or upskilling existing people rather than outsourcing (61% versus 39%) or hiring (62% versus 38%). They are making use of a variety of training methods from formal internal trainings, vendor-led trainings to informal trainings like ‘lunch-and-learns.'”
– It was done in 2016Q3, over 845 respondents in an online survey. “The survey divided respondents into four broad IT ‘roles’: Developer 30%, Operations 30%, Manager 20%, and Line of business leadership 20%.” And spread across geographies and industries.
The premise of this book, for most anyone, is painfully boring: planning out and project managing the installation of COTS software. This is mostly lumbering, on-premises ERP applications: those huge, multi-year installs of software that run the back office and systems of record for organizations. While this market is huge, touches almost every company, and has software that is directly or indirectly touched by almost everyone each day (anytime you buy something or interact with a company)…it’s no iPhone.
If you’re in the business of selling enterprise software and services, however, Beaubouef’s book is a rare look inside the buyer’s mind and their resulting work-streams when they’re dealing with big ol’ enterprise IT. As a software marketer, I read it for exactly that. I was hoping to find some ROI models (a scourge of my research). It doesn’t really cover that at all, which is fine.
There’s a core cycle of ideas and advice flitting in and bout of the book that I like:
- COTS software will do, you know, 80% of what you like. The rest is customizing it through configuration, your own code layered on-top, or getting the vendor to add in new features.
- The more you customize the software, the harder it will be to change. But, the less you customize it, the less it creates differentiation for your business processes.
- Most of the problems and challenges you’ll encounter, though, will be human based.
- Much of these human problems are about managing the requirements process to make sure the software is matching the needs of the business.
- Process-wise, to do this we like to take on a waterfall approach (try to specify everything up front, implement it all, then verify if it works). This results in a lot or risk of waiting for that final verification to see if it works and you were right about matching the COTS implementation to business needs.
- Instead, and iterative approach that focuses on learning and honing the COTS/business match-up seems like a good idea.
- Role-wise, getting someone(s) who have a tops-down view of the business process and enough technical understanding to map that to the COTS project is a really good idea, though hard to put in place.
While the book focuses on on-premises software, the overall thinking could easily apply to any implementation of a large IT-driven, vendor provided system: SaaS would work, and to an extent the kind of infrastructure software we sell at Pivotal. As the points above go over, the core thrust of the book is about managing how you make sure your IT is actually helping the business, not bogging down in its self.
If you’re pretty vague on what you should do in these large IT initiatives, you could do a lot worse than read this book.
Check out the book: *Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations *