The key, I found, was to agree on new objectives. First, we tackled the question of documentation. In the old model, QA’s job was to make sure that documentation was complete—that each required section of the official template had been filled in with enough information to satisfy our overseers. But in conversation, the head of QA and I agreed that concisenesswas also an important aspect of quality. The project teams had been spending a lot of time writing text that was never read, creating documentation that was repetitive and in places inconsistent. Some sections of the templates made no sense for the types of projects we were doing. So the goal of QA, we agreed, should be to make sure that every document was as shortas possible and didn’t include any irrelevant information, even if that meant leaving template sections blank.
Of course this wouldn’t please our government overseers, who expected every section to be filled out in great detail, but that was my job to take care of—a kind of impediment removal. QA’s job was to ensure quality, which included concision and effective use of time. So QA began to demand simplifications to documents rather than insisting that they be padded with unnecessary words, and I went off to negotiate with overseers on their behalf.
The cliché we all recite is that technology isn’t the problem, culture is. Put another way: if the hardware and software are fine and fresh, it must be the meatware that smells. Come hear several de-funking recipes from the world’s largest companies whose meat now smells proper.
I answered a few attendee questions in the webinar, and answered the rest in a Twitter thread afterwards.
Innovation – use IT to help change how the current business functions and create new businesses. Rental car companies want to streamline the car pick-up process, governments want to go from analog and phone driven fulfillment to software, insurers want to help ranchers better track and protect the insured cows. Innovation is now a vacuous term, but when an organization can reliably create and run well designed software, innovation can actually mean something real, revenue producing, and strategic.
Keep making money – organizations already have existing, revenue producing businesses, often decades old. The IT supporting those businesses has worked for all that time – and still works! While many people derisively refer to this as “keeping the lights on,” it’s very difficult to work in the dark. Ensuring that the company can keep making money from their existing IT assets is vital – those lights need to stay on.
Restoring trust in IT’s capabilities – organizations expect little from IT and rarely trust them with critical business functions, like innovating. After decades of cost cutting, outsourcing, and managing IT like a series of projects instead of a continuous stream of innovation. The IT organization has to rebuild itself from top to bottom – how it runs infrastructure, how it developer and runs software, and the culture of IT. Once that trust is built, the business needs to re-set its expectations of what IT can do, reinventing IT back into everyday business.
There’s some good “how do I actually get my organization do all this unicorn stuff” comments in this interview with DreamWorks Animation’s Doug Sherman.
Here’s one sample bit on winning people over to microservices. Instead of going into the lab for six months to work on a tool that they think will be useful, they do a lot more user-driven work upfront and then do (it sounds like) weekly small batches to keep the users apprised of the tools and, you’d guess, give continuous feedback:
You have to understand what people want to do in their domain. In the past, Ive gotten it wrong. Ill come up with an idea I think is sound I think its the coolest thing ever and Ill work six months in isolation with my team, and then well do this big reveal. And every time we’ve done that, its gone horribly wrong, because 1) people feel like were lecturing to them, like we know better than them. And then 2) we would typically have over-engineered it! It would be like the 747 cockpit, you know? There would be this overwhelming amount of knobs and bits and pieces that I think are great to have, but from their viewpoint, they only need to do a few things, and thats an overwhelming amount of stuff to have to sign up to be able to do. So now, Ive gotten into a habit: before I even write a single line of code, I interview everybody that potentially will use the solution that Im going to write, and I keep them in lockstep with me and my team just about every week. We keep them engaged, helping to influence the direction Im basically trying to echo out in code all of what they want. Its gone so much better, because they feel invested. They don’t feel like in six months I’m revealing this big, mysterious thing. They feel like this is just something they’ve seen through iterations. And whats empowering about that, too, is if you can get the spiritual leaders of the different departments that you’re trying to encourage to use your solution, they’ll help sell it for you.
And then a bit on their progress:
Were about 50% of the way in having some amount of production coverage powered by microservices which are deployable in cloud containers powered by technologies such as Spring and Spring Cloud.
There’s more, good cultural change stories in the interview.
I’m always interested to hear how management manages to change how software is done in large organizations – it can seem impossible! As ever, Allstate provides a fascinating stream of information here, and I was lucky to get the chance to interview Opal Perry there on how Allstate has been doing with all that cloud-native stuff.
Also, if you want to hear more, Matthew Curry and I had a similar conversation a few weeks ago at OSCON.
It’s another survey about business/IT alignment. Who knows how accurate these leadgen PDFs are, but why not? This one is of “646 CIOs and other IT leaders and 200 line of business leaders.” Some summaries from Minda Zetlin:
When LOB leaders were asked about the role their companies’ CIOs play, 41 percent said the CIO is a strategic advisor who identifies business needs and opportunities and proposes technology to address them. Another 22 percent said the CIO is a consultant who provides advice about technology and service providers when asked.
But 10 percent said their CIO was a “roadblock” who raises so many obstacles and objections to new technology that projects are difficult to complete. And another 9 percent said the CIO was a “rogue player,” with IT making technology decisions on its own, and creating visibility and transparency challenges.
Meanwhile, 36 percent of LOB leaders and 31 percent of IT leaders believe other departments “see IT as an obstacle.” And 58 percent of IT leaders but only 13 percent of LOB leaders agreed with the statement, “IT gets scapegoated by other departments when they miss their own goals.”
There’s still, as ever, plenty of room to improve business/IT alignment.
Speaking of that, also in that IDG/CIO Magazine survey, there’s a weird mismatch between the perception of The Business and IT about what IT does:
What does The Business want anyway?
- Almost twice as many CEOs are intent on building up in-house technology and digital capabilities as those plan on outsourcing it (57 percent and 29 percent, respectively).
- Forty-seven percent of CEOs are directed by their board of directors to make rapid progress in digital business transformation, and 56 percent said that their digital improvements have already delivered profits.
- 33 percent of CEOs measure digital revenue.
Point being: The Business wants IT to matter and be core to how their organizations evolve. They want programmable businesses. Here’s some examples from another summary of that Gartner survey:
Although a significant number of CEOs still mention eCommerce, more of them align new IT infrastructure investments to advanced commercial activities – such as digital product and service innovation, exploring the Internet of Things (IoT), or adopting digital platforms and associated supplier ecosystems.
According to the Gartner assessment, some CEOs have already advanced their digital business agenda – 20 percent of CEOs are now taking a digital-first approach to business development. “This might mean, for example, creating the first version of a new business process or in the form of a mobile app,” said Mr. Raskino.
Furthermore, 22 percent are applying digital business technologies to their traditional processes. That’s where the product, service and business models are being changed, and the new digital capabilities that support those are becoming core competencies.
There’s demand there, the final result of “the consumerization of enterprise IT,” as we used to crow about. IT needs to catch-up on its abilities to do more than “just keep the lights” on or there’ll be a donkey apocalypse out there.
You seem people like Comcast doing this catching-up, very rapidly. The good news is that the software and hardware is easy. It’s the meatware that’s the problem.
Free food, during a limited, half-hour window, both saves people some hassle and gets them to show up at the same time to kick off the workday.
To understand why this is so important, picture Pivotal without free breakfast. Let’s start with the obvious. Most developers would sleep late if it were up to them. They’d roll into the office around 10 or 11 AM. Which means they’d grab a coffee, maybe respond to a few emails, and then sync up with the team.
Before you know it, the morning is over and it’s time for lunch. But hey, that’s okay, we live in a digital world, and you can show up whenever, so long as you get your work done, right? Wrong. Pair programming only works when you have people to pair with. And that means you need to sync their schedules.
We ring a cowbell at 9:05 AM. (The Toronto office smacks a golden gong with a mallet.) It signals that breakfast is over and the office-wide meeting is about to start. After the five-minute standup, the teams have their own standup meetings, and then pairs break off to get rolling at their workstations.
While posed as a pair programming enabler, take out pairing from the above and it also gets the point of having people show-up on-time, not dick around, and do actual work.
If you’ve seen me talk you know the joke of “how a developer spends their day” which usually includes 1-2 hours of actual coding because of all the meetings, you know, those 30 minute sitdown-standup meetings, architectrual reviews, deciding where to go to lunch, the post-lunch-buffet comma, “researching on the Internet, etc…. it’s all just unsynchronized schedules and little not attention spent on actually managing your staff’s time.
If there’s one complaint that I hear consistently in my studies of IT in large organizations, it’s that government IT, as traditionally practiced, is fucked. Compared to the private sector, the amount of paperwork, the role of contractors, and the seeming separation between doing a good job and working software drives all sorts of angst and failure.
Mark Schwartz’s book on figuring out “business value” in IT is turning out to be pretty amazing and refreshing, especially on the topic of government IT. He’s put together one of the better “these aren’t the Droids you’re looking for” responses to ROI for IT.
You know that answer: you just want to figure out the business case, ROI, or whatever numbers driven thing, and all the DevOps-heads are like “doo, doo, doo-doo – driving through a tunnel, can’t hear you!” and then they pelt you with Goldratt and Deming books, blended in with some O’Reilly books and The Phoenix Project. “Also, you’re argument is invalid, because reasons.”
A Zen-like calm comes over them, they close their eyes and breath in, and then start repeating a mantra like some cowl-bedecked character in a Lovecraft story: “survival is not mandatory. Survival is not mandatory. Survival is not mandatory!”
Real helpful, that lot. I kid, I jest. The point of their maniacally confusing non-answers is, accurately, that your base assumptions about most everything are wrong, so before we can even approach something as precise as ROI, we need to really re-think what you’re doing. (And also, you do a lot of dumb shit, so let’s work on that.)
But you know, no one wants to hear they’re broken in the first therapy session. So you have to throw out some beguiling, mind-altering, Lemarchand’s boxes to change the state of things and make sure they come to the next appointment.
Works as Designed
Anyhow, back to Schwartz’s book. I’ll hopefully write a longer book review over at The New Stack when I’m done with it, but this one passage is an excellent representation of what motivates the book pelters and also a good unmasking of why things are the way we they are…because we asked for them to be so:
The US government is based on a system of “checks and balances”—in other words, a system of distrust. The great freedom enjoyed by the press, especially in reporting on the actions of the government, is another indication of the public’s lack of trust in the government. As a result, you find that the government places a high value on transparency. While companies can keep secrets, government is accountable to the public and must disclose its actions and decisions. There is a business need for continued demonstrations of trustworthiness, or we might as well say a business value assigned to demonstrating trustworthiness. You find that the government is always in the public eye—the press is always reporting on government actions, and the public is quick to outrage. Government agencies, therefore, place a business value on “optics”—how something appears to the observant public. In an oversight environment that is quick to assign blame, government is highly risk averse (i.e., it places high business value on things that mitigate risk).
And then summarized as:
…the compliance requirements are not an obstacle, but rather an expression of a deeper business need that the team must still address.
Which is to say: you wanted this, and so I am giving it to you.
The Agile Bureaucracy
The word “bureaucracy” is something like the word “legacy.” You only describe something as legacy software when you don’t like the software. Otherwise, you just call it your software. Similarly, as Schwartz outlines, agile (and all software processes) are insanely bureaucratic, full of rules, norms, and other “governance.” We just happen to like all those rules, so we don’t think of them as bureaucracy. As he writes:
While disavowing rules, the Agile community is actually full of them. This is understandable, because rules are a way of bringing what is considered best practices into everyday processes. What would happen if we made exceptions to our rules—for instance, if we entertained the request: “John wants to head out for a beer now, instead of fixing the problem that he just introduced into the build?” If we applied the rules capriciously or based on our feelings, they would lose some of their effectiveness, right? That is precisely what we mean by sine ira et studio in bureaucracy. Mike Cohn, for example, tells us that “improving technical practices is not optional.”15 The phrase not optional sounds like another way of saying that the rule is to be applied “without anger or bias.” Mary Poppendieck, coauthor of the canonical works on Lean software development, uses curiously similar language in her introduction to Greg Smith and Ahmed Sidky’s book on adopting Agile practices: “The technical practices that Agile brings to the table—short iterations, test-first development, continuous integration—are not optional.” I’ve already mentioned Schwaber and Sutherland’s dictum that “the Development Team isn’t allowed to act on what anyone else [other than the product owner] says.”17 Please don’t hate me for this, Mike, Mary, Ken, and Jeff, but that is the voice of the command-and-control bureaucrat. “Not optional,” “not allowed,” – I don’t know about you, but these phrases make me think of No Parking and Curb Your Dog signs.
These are the kind of thought-trains that only ever evoke “well, of course my intention wasn’t the awful!” from the other side. It’s like with the ITIL and the NRA, gun-nut people: their goal wasn’t to put in place a thought-technology that harmed people, far from it.
Gentled nestled in his wry tone and style (which you can image I love), you can feel some hidden hair pulling about the unintended consequences of Agile confidence and decrees. I mean, the dude is the CIO of a massive government agency, so he be throwing process optimism against brick walls daily and too late into the night.
The cure, as ever, is to not only to be smart and introspective, but to make evolution and change part of your bureaucracy:
Rules become set in stone and can’t change with circumstances. Rigidity discourages innovation. Rules themselves come to seem arbitrary and capricious. Their original purpose gets lost and the rules become goals rather than instruments. Bureaucracies can become demoralizing for their employees.
So, you know, make sure you allow for change. It’s probably good to have some rules and governance around that too.
I started a new booklet project, the Cloud Native Cookbook.
The premise is this:
The premise of this book is to collect specific, tactical advice transitioning to a cloud-native organization. The reader is someone who “gets it” when it comes to agile, DevOps, cloud native, and All the Great Things. Their struggle is actually putting it all in place. Any given organization has all of it’s own, unique advantages and disadvantages, so any “fix” will be situational, of course.
This cookbook draws from actual experiences of what worked and didn’t work to try to help organizations hack out a path to doing software better. While we’ll allow ourselves some “soft,” cultural things here and there, each of the “recipes” should be actionable, tangible items. At the very least, the rainbows and unicorns stuff should have concrete examples, e.g., how do you get people to actually pair program when they think it’s a threat to their self-worth?
As with my previous cloud-native booklet, I have this one open for comments as I’m working on it. It’d be great to get your input.
Here’s some slides I’ve been using around all this.
My colleague Richard has a nice post suggesting the new functions enterprise architects can play in a cloud-native organization. I like this one in particular, help make the change:
Champion new team organization patterns. As an architect, you can bring developers and operations teams together. Recognize that functional silos slow down delivery. A DevOps-type approach really works. Architects are perfectly positioned to pioneer new team structures that increase velocity and customer attentiveness.
It’s brief, but there’s plenty of other good chunks of advice in there.
In a report giving advice to mainframe folks looking to be more Agile, Gartner’s Dale Vecchio and Bill Swanton give some pretty good advice for anyone looking to change how they do software.
Here’s some highlights from the report, entitled “Agile Development and Mainframe Legacy Systems – Something’s Got to Give”
Chunking up changes:
- Application changes must be smaller.
- Automation across the life cycle is critical to being successful.
- A regular and positive relationship must exist between the owner of the application and the developers of the changes.
This kind of effort may seem insurmountable for a large legacy portfolio. However, an organization doesn’t have to attack the entire portfolio. Determine where the primary value can be achieved and focus there. Which areas of the portfolio are most impacted by business requests? Target the areas with the most value.
An example of possible change:
About 10 years ago, a large European bank rebuilt its core banking system on the mainframe using COBOL. It now does agile development for both mainframe COBOL and “channel” Java layers of the system. The bank does not consider that it has achieved DevOps for the mainframe, as it is only able to maintain a cadence of monthly releases. Even that release rate required a signi cant investment in testing and other automation. Fortunately, most new work happens exclusively in the Java layers, without needing to make changes to the COBOL core system. Therefore, the bank maintains a faster cadence for most releases, and only major changes that require core updates need to fall in line with the slower monthly cadence for the mainframe. The key to making agile work for the mainframe at the bank is embracing the agile practices that have the greatest impact on effective delivery within the monthly cadence, including test-driven development and smaller modules with fewer dependencies.
It seems impossible, but you should try:
Improving the state of a decades-old system is often seen as a fool’s errand. It provides no real business value and introduces great risk. Many mainframe organizations Gartner speaks to are not comfortable doing this much invasive change and believing that it can ensure functional equivalence when complete! Restructuring the existing portfolio, eliminating dead code and consolidating redundant code are further incremental steps that can be done over time. Each application team needs to improve the portfolio that it is responsible for in order to ensure speed and success in the future. Moving to a services-based or API structure may also enable changes to be done effectively and quickly over time. Some level of investment to evolve the portfolio to a more streamlined structure will greatly increase the ability to make changes quickly and reliably. Trying to get faster with good quality on a monolithic hairball of an application is a recipe for failure. These changes can occur in an evolutionary way. This approach, referred to in the past as proactive maintenance, is a price that must be paid early to make life easier in the future.
You gotta have testing:
Test cases are necessary to support automation of this critical step. While the tooling is very different, and even the approaches may be unique to the mainframe architecture, they are an important component of speed and reliability. This can be a tremendous hurdle to overcome on the road to agile development on the mainframe. This level of commitment can become a real roadblock to success.
Another example of an organization gradually changing:
When a large European bank faced wholesale change mandated by loss of support for an old platform, it chose to rewrite its core system in mainframe COBOL (although today it would be more likely to acquire an off-the-shelf core banking system). The bank followed a component-based approach that helped position it for success with agile today by exposing its core capabilities as services via standard APIs. This architecture did not deliver the level of isolation the bank could achieve with microservices today, as it built the system with a shared DBMS back-end, as was common practice at the time. That coupling with the database and related data model dependencies is the main technical obstacle to moving to continuous delivery, although the IT operations group also presents cultural obstacles, as it is satis ed with the current model for managing change.
A reminder: all we want is a rapid feedback cycle:
The goal is to reduce the cycle time between an idea and usable software. In order to do so, the changes need to be smaller, the process needs to be automated, and the steps for deployment to production must be repeatable and reliable.
The ALM technology doesn’t support mainframes, and mainframe ALM stuff doesn’t support agile. A rare case where fixing the tech can likely fix the problem:
The dilemma mainframe organizations may face is that traditional mainframe application development life cycle tools were not designed for small, fast and automated deployment. Agile development tools that do support this approach aren’t designed to support the artifacts of mainframe applications. Modern tools for the building, deploying, testing and releasing of applications for the mainframe won’t often t. Existing mainframe software version control and conguration management tools for a new agile approach to development will take some effort — if they will work at all.
Use APIs to decouple the way, norms, and road-map of mainframes from the rest of your systems:
wrapping existing mainframe functions and exposing them as services does provide an intermediate step between agile on the mainframe and migration to environments where agile is more readily understood.
Contrary to what you might be thinking, the report doesn’t actually advocate moving off the mainframe willy-nilly. From my perspective, it’s just trying to suggest using better processes and, as needed, updating your ALM and release management tools.
Read the rest of the report over behind Gartner’s paywall.
Instead, the post emphasized new ways NASA is thinking about acceptable risk for these launches. During the space shuttle era, launch sites were governed by some 2,200 safety requirements. NASA worked to “strip down the expensive rules and came up with just 500 core safety requirements for launches.”
But, the post notes, ”at commercial launch sites, there are only 55 safety requirements.” This “underscores perhaps the single biggest difference between NASA and its commercial partners: risk tolerance. NASA likes to have next to none, and pays for it, while the companies tend to embrace calculated risk as a way to iterate and learn while still developing their products.”
This a major point in companies fixing up their software process: you probably have all sorts of rules and regulations that no longer apply. Just like with managing a legacy application portfolio, you have to aggressively manage your compliance portfolio to eliminate rules that no longer apply.
Matt Curry covers this point with a funny boat-metaphor at the start of his brand talk from last year. You also hear some cases of federal agencies forcing this culling by simply not following the rules and seeing if anyone complained: the compliance equivilent of just turning off old, dusty servers to see who’s using it.
Under the auspices of “how can we DevOps around here?” I’ve had numerous conversations with organizations who feel like they can’t get their people to change over to the practices and mind-set that leads to doing better software. The DevOps community has spent a lot of time trying to gently bring along and even brain-hack resistant people and there are numerous anecdotes and studies that doing things in DevOps/cloud native/agile/etc. way not only make businesses run more smoothy and profitably, but make the actual lives of staff better (interested in leaving work at 5pm and not working on weekends?)
Still, for whatever reasons, the idea of “the frozen-middle” is reoccurring. In government work, there’s often the frozen-ground” with staff throwing down their heels as well.
Most of the chatter on this topic is at the team level, and usually teams in already flexible, new organizations (like all those logos on scare-slides in presentations from people like Pivotal: UBER! AIRBNB! TESLA! SOFTWARE-IS-EATING-THE-WORLD, INC.!) If you’re already in a company that can change its culture every year, the pain of these “frozen” people is almost nil in comparison to being in government, a 50-100 years old company, or otherwise “in the real world.”
Right here, I’m supposed to establish empathy with these frozen people to get them to change. I should stop calling them “frozen people” and treating them like “resources,” and think of them as people. That is all true, but what do I do after I’ve cavorted with them in empathy splash-pads for months on end and we still can’t get them to configure the firewall so we can do the DevOps? What do you do with enterprise architects who have become specialists in telling you how impossibly fucked up everything is? How do you work with all those “frozen middle-managers” who are acting as a “shit umbrella” (or maybe in this case, a “rainbow umbrella”?) to all your fanciful DevOps notions?
There’s one last ditch tactic: money and firing. When it comes to changing the culture in a large orginizations, this is the big hammer that upper-level management has. That is, the middle-manager’s manger is the one who has to tools to fix the problem. By design, the surest, easiest, sanctioned way to change behavior is to change cash pay-outs and other compensation based on not only the performance of people (management and staff), but their willingness to adapt and change to new, better ways of operating. That is: you reward and punish people based on them doing what you told them to do, or not.
There’s all sorts of “little and cheap” things to do instead of bringing out the big hammer:
- Giving out acrylic trophies, showering people in attention from high-level execs
- Fame and glory internally and externally
- T-shirts (no, really! They work amazingly well)
- Sanctioning goofing off (“we may have a 15 day holiday policy, but, you know, you should leave work at 4 every day and don’t log vacation”)
Matt Curry covers most of these management-hacks in a great talk on changing large organizations. But let’s assume those aren’t working.
At this point, “leadership” (middle-management’s management) needs to reward and punish the unfreezing or freezing. If middle-management changes (“unfreezes”), they get paid more. If they don’t unfreeze at least their pay needs to freeze, and at “best” they need to get quarantined or fired (as a tone-note, back when I was young and the idea of getting “laid-off” or “RIFed” started being used I reprogrammed myself to only ever say “fired” in reference to loosing your job: those soft, BS words obscure the fact that you’ve been, well, fired – so, feel free to s/// whatever more HR-correct phrase you like into there).
If you look at the patterns of change in most companies going cloud native, they do exactly this. Organizations that successful change so that they can start doing software better set up separate “labs” where the “digital transformation” happens. These are often logically and physically separate: they often have new names and are often “off-site” or well hidden, in the skunk-works style. They do this because if they stay mentally and physically in the “old” system, they end up getting frozen simply due to proximity. The long-term, managerial strategy, here, is an application of the strangler pattern to the “legacy” organization: eventually, the new “labs” organization, through value to the business and sheer size, becomes the “normal” organization.
The staff process they use – almost as a side-effect! – is to only move over people who are willing to change. I’d argue that “skills” and aptitude have little to do with the selection of people: any person in IT can learn new ways of typing and right clicking if the company trains them and helps them. We’re all smart, here.
What happens is that you cull the frozen people, either leaving them behind in the old organization (where there’s likely plenty of work to be done keeping the legacy systems alive!), or just outright firing them. That’s all brutal and not in the rainbows and sandals spirit of DevOps, but it’s what I see happening out there to successfully change the fate of large organizations’ IT departments.
You don’t really hear about this in cheery keynotes at conferences, but at dark bars and (I shit you not) in quiet parking garages I’ve talked with several executives who paint out this unfreezing-by-attrition process as something that’s worked in their organization. One of them even said “we should have gotten rid of more people.”
This pattern gets more difficult in highly labor-regulated industries – like government work and government contractors – but setting up brand new organizations to shed the frozen old ways is at least something to try.
And, barring all else, as I like to say, if nothing is working, and people won’t actually change, Pivotal is always hiring.
If that’s too grim, don’t despair! My buddies have a much light-hearted, hopefully whack at the problem in a recent discussion of ours:
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.
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.”
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.
…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.
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.
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.
Using Apple Watches to assist waitstaff is interesting, but sort of over kill.
I’d assume they’d still need to take orders which probably works best with paper (or just memorizing), or at best a tablet or phablet. The watch is not very good for reading and gathering information: it’s better at taking quick actions, just getting quick info like the time or current temperature, and small notifications.
Still, any new use case people come up with is interesting:
Second, the use of the Apple Watch adds an interesting layer to day-to-day hospitality practices. Guest notes within reservations are nothing new, but employing a dynamic, real-time system to make sure that the people who need to read the notes actually do read the notes is a major step. The Apple Watch, for its… shortcomings, is arguably less intrusive than a mobile phone or larger screen, and can be checked far more discreetly. I can’t speak for restaurant floor managers, but from this side of the keyboard, this seems like an efficient technological upgrade.
Another interesting tidbit buried in the Eater piece: soon, ResyOS will support the ability to add other diners to a reservation so the restaurant has a clearer picture of everyone at the table — great news for couples who keep track of which reservation profiles have all of the “good notes.” (We all do that, right?)
Re-reading Nick’s piece on “digital transformation,” I like how he explains what’s new and different from past waves of IT innovation (lik ERP and econmerce), e.g.:
“Going digital results in an explosion in the amount of data you have. New channels of engagement between customers and organizations have resulted in new sources of information coming into the organization at speeds not seen before. In the past, customer interaction was mostly one-way – from the organization to the customer. Now it is about customer-directed, on-demand two-way engagement anywhere on any device. Customers want to communicate on their terms in their preferred channels. That causes organizations to have to transform the way they handle such information, since having a large call center may not be enough – or even that relevant in the future, given that so much communication will come via social media, in messages or increasingly via video. Add to that the explosion in information from Internet of Things (IoT) devices, and it’s pretty clear that the days of management by gut-feel and hunch are over, and data-driven decision-making is the only way to go.
And also, some numbers:
- “Less than 25% of organizations that participated in a recent 451 Research survey (451 Research VoCUL, April 2016) said they had a well-defined formal digital transformation strategy. So we’re in the early stages of digital transformation, and there’s lots of work to be done.”
- “Erik Brynjolfsson, Lorin Hitt and Heekyung Hellen Kim from MIT and University of Pennsylvania found that companies with data-driven decision environments have 5% higher productivity, 6% higher profit and up to 50% higher market value than other businesses.”
- “Our research shows about 65% of IT decision-makers using agile methods and about 40% adopting DevOps today (VotE Software-Defined Infrastructure Q4 2015).”
It’s easy to take all the recent advances in photography for granted. They all just sort of work. This overview from Sinofsky on the bokeh effect in the new iPhones explains what’s going on, and also highlights a mainstream – consumer! – case of how software, IoT, and hardware (mobile phones) are innovating what was a moribund field:
If you extrapolate from today you can start to see how mobile photography that incorporates multiple sensors, machine learning, and real-time compute will continue to create new types of images.
It’s a good example of what we mean by “digital transformation.” It means using IT to the maximum and, I think, is best understood by contemplating what exactly the opposite is: “analog.” There are so many things in our daily lives (both business and personal) that are not being augmented by software, let along “sensors” and “machine learning.” There’s almost an endless TAM out there to gobble up; rather, an infinite future of opportunity to create fun, new experiences and productivity.
From Gary Gruver, one of the better “how to do agile and DevOps stuff in large organizations” authors:
For these organizations implementing DevOps principles (the ability to release code to the customer on a more frequent basis while maintaining or improving stability and quality) is more about creating a well-designed deployment pipeline that builds up a more stable enterprise systems on a regular basis so it is much easier to release the code on a more frequent basis. This is done by creating a deployment pipeline that integrates the code across the enterprise system on a much more frequent basis with automated testing to ensure that new functionality is not breaking existing code and the code quality is kept much closer to release quality.
From my perspective this approach to DevOps is rather different from the more unicorn type approach described in this article. It though does address the biggest opportunity for improvement that does exist in more large traditional organizations which is coordinating the work across teams. In these cases the working code in the deployment pipeline is the forcing function used to coordinate work and ensure alignment across the organization. If the code from different teams won’t work together or it won’t work in production, the organization is forced to fix those issues immediately before too much code is written that will not work together in a production environment. Addressing these issues early and often in a deployment pipeline is one of the most important things large traditional organizations can and should be doing to improve the effectiveness of their development and deployment processes.
Some interesting ideas to improve debit (and credit, one’d presume) with software-driven features:
CardGuard provides additional protection against fraud, since customers are able turn their debit card “on” or “off.” When the card is “off,” no withdrawals or purchases will be approved, with the exception of previously authorized or recurring transactions. Additionally, transaction controls can be set according to location, meaning transactions attempted outside of the geographic parameters set by the customer will be declined.
With CardGuard, customers are able to better manage their spending by establishing limits for debit card purchases based on the amount of the transaction. Additional controls can be set to manage spending in different categories by enabling or disabling transactions for certain merchant groups, such as gas, grocery or retail stores.