How Cloud Native Computing Is Evolving

In the last 15 years, application delivery has moved from being bound to physical servers to running on virtual machines with a full operating system and now to containers with Docker where developers can specify every aspect of deployment, he added.

The move has also been a shift from a heavyweight application deployment model to a lightweight model that takes less time to start up and deploy applications. Additionally, there has been a move from being bound to a single closed-source vendor to an open-source model with multiple vendors, less risk of lock-in and more choice.

And, on the maturity front:

not all organizations are ready for the move, according to Donnie Berkholz, research director at 451 Group. He pointed to a recent survey his firm conducted that found that most IT organizations are still running lots of manual process and aren’t in the DevOps world, and many aren’t even using agile development methods either. For cloud native to make sense, organizations need to make use of continuous integration and continuous development technologies, Berkholz said.

“You can’t do cloud native if you don’t have the right processes to support it,” Berkholz said. “For some of the world, it’s a long way to go on the journey to cloud native, and it will take at least five years to get there.”

Source: How Cloud Native Computing Is Evolving

Why do you have to burn $4bn to add mobile apps to taxis?

In the first quarter of this year, Uber lost about $520 million before interest, taxes, depreciation and amortization, according to people familiar with the matter. In the second quarter the losses significantly exceeded $750 million, including a roughly $100 million shortfall in the U.S., those people said. That means Uber’s losses in the first half of 2016 totaled at least $1.27 billion.

Meanwhile, revenue:

Bookings grew tremendously from the first quarter of this year to the second, from above $3.8 billion to more than $5 billion. Net revenue, under generally accepted accounting principles, grew about 18 percent, from about $960 million in the first quarter to about $1.1 billion in the second.

It’s expensive to start a global, meat-space business, even if you’re “assetless”:

Uber, which is seven years old, has lost at least $4 billion in the history of the company.

I find the continuous usage of Uber as an example of “the way forward” in business unhelpful. Not because it’s not an interesting business, but because without these kinds of numbers in context, you think it’s easy. If you’re prepared to burn through $4bn before profit, sure thing!

The advantage established businesses should have is less spending to build a market: they just need to do better serving their existing customer base at first, not spend all that money to start from zero. What I find devilishly fascinating is why it’s so hard for those large organizations to take advantage of the assets they already have and why, possibly, it’s easier just to start from scratch, as Uber has been doing with that $4bn.

Source: Uber Loses at Least $1.2 Billion in First Half of 2016

Agile Development’s Biggest Failure Point—and How to Fix It

Companies commonly make one of two mistakes when selecting a product owner. Often they tap a junior employee with ­limited experience and therefore a limited understanding of how the project fits into the larger mission. Product owners need enough seniority to inspire and motivate peers across multiple business units. By earning the respect of teams in customer experience, enterprise architecture, and risk and compliance, for example, the ­product owner can help ensure that ­projects move smoothly without costly ­bottlenecks. Other companies err in the ­opposite direction, selecting a senior ­executive who is too harried to devote ­adequate time and may not adapt well to the highly responsive, iterative nature of agile development.
So what should companies look for when appointing product owners? In our view, the key is to find people who think and ­behave like entrepreneurs.

Much of the advice here falls under the category of “if you do good things, good things happen”:

success comes from simply managing a sound process: conducting market ­research, understanding the customer’s needs, identifying where the product will create the most value, prioritizing the most important features, testing ideas, capturing customer feedback, and continuously ­refining their vision over time.

The tasks is setting up and environment, processes, even “culture” that encloses and rewards good behavior like this. And the protecting that structure from corporate barbarians. That’s a job – and the responsibility – of management. So, perhaps it’s good to get some management consulting advice on what good looks like.

Source: Agile Development’s Biggest Failure Point—and How to Fix It

How Asset Managers Can Succeed with Advanced Analytics

A nice overview of what you’d use analytics fit in investing:

Armed with these advanced techniques, digitally forward asset managers can gain a significant information advantage over peers who rely mainly on traditional data sources and analytical practices. They can crunch through vast quantities of data; scour video and satellite imagery to gauge a retailer’s Black Friday prospects; extract insights from social media, texts, and e-mail to divine market sentiment; and parse a CEO’s comments during an earnings call to estimate the potential impact on the next quarter’s results. They can discern how unexpected weather disruptions might affect their portfolio, and even disprove long-held beliefs about how markets work. Smart, dynamic investment technology also helps managers assess their own performance to see whether they may be making the right decisions at the wrong times, buying too late, or listening to “influencers” who push them in the wrong direction.

There’s also a good overview of how to introduce new approaches like the above into the organization without it be Big Bang projects, likely to fail:

In experimenting with new technologies, firms should prioritize a small number of targeted initiatives that can deliver immediate tangible benefits in a focused, resource-­constrained way. In doing so, they should resist two temptations: the “esoteric science experiment,” whose focus is so narrow that the initiative can’t yield scalable results; and the “big bang rollout,” whose scope is so ambitious that it has a daunting price tag and takes too long to demonstrate value.

Source: How Asset Managers Can Succeed with Advanced Analytics

Working with legacy applications, systems, and portfolios

Elisabeth Greenbaum Kasson asked me recently for advice on working with legacy applications. Check out her piece on it. Here’s the full reply I sent to her in email:


Her topics:
– The steps someone could take to get themselves up to speed on their employer’s legacy software.
– How this knowledge can make them indispensable (I know that term is relative)
– Why this type of expertise is so necessary, especially when it comes to integrating said software with new and/or evolving products.

When it comes to “dealing with legacy,” there aren’t that many good options. We often think of “legacy” as software that must be changed but that we’re afraid to change. If you’re not afraid to change it, you often just think of it as “our software.” Legacy has this connotation of it being risky, scary, or maybe just boring.

If someone wants to go down into the mines of legacy management, the first thing I’d recommend is doing some history work to find out why the legacy system in question was created, what it’s currently used for, and, hopefully, who the current stake-holders/owners are. You’d be surprised – or maybe not! – how often some or all three of those are totally unknown: with unknown stake-holders, I sometimes hear tale stories of IT departments just shutting down systems and waiting to see who calls them.

Understanding the why, what, and who of a legacy system will tell you most of what you need to know when it comes to managing it. Further up the management chain, having a good grasp of and on portfolio management is valuable. Given the why, what, and who, you should be able to prioritize any given “legacy application” relative to another with respect to funding and attention. Is fixing the application that’s used to schedule office party birthday cake orders more important than the application used to re-order plungers for the warehouse bathrooms? You won’t know between cakes or plungers if you don’t do portfolio management.

The other aspect is simply learning the technologies you need – operationally, programming, and sometimes physical management – to keep the thing up and running and to modify it. This might mean learning, for example, about operating systems for mainframes, AS/400, UNIX, older versions of Windows, and sometimes even exotic things like OS/2. There’s dozens of programming languages out there, and you’ll need to learn not only the appropriate “old” language, but how the build, version control, and project management tools around those old stacks function.

For more, I wrote about dealing with legacy in my cloud native journey booklet last year.

To be effective, strategy needs living context

img_6146

[T]he art of strategy based upon situational awareness remains one of those topics which are barely covered in business literature. The overwhelming majority depends upon alchemist tools such a story telling, meme copying and magic frameworks like SWOTs. It is slowly changing though and every day I come across encouraging signs.

Other than the “why don’t you tell me how you really think” tone there at the end (hey, I clearly have nothing wrong with that kind of dismissive style), that fits my experience working on strategy.

Your strategy team is forced to freeze time at the launch of the process, looking at their industry as an unchanging process (value chain diagrams, anyone?). As most strategy work takes 3-6 months at best (if not a year to year and half to fit into the corporate budget cycle and then get through The New Years hang over: no one really starts working again until February, then the business units have to plan, allocate budget, and execute), you’re behind: you’re looking at an understanding of the world that’s around a year out of date.

Worse than this, strategy teams are rarely given the tools (time, money, authority, and staff) to actually test out any theories, let alone learn from adapt the results of those tests. There’s no room for OODA/PDCA/lean startup, small batch thinking20.

Centralized strategy in a large company is weird in how unhelpful it can be for industries that are constantly changing or threatened by competitors. Like so many other corporate functions, the fix looks to be shortening the cycle time and getting as close to the actual work and customers as possible.

That’s a long way from the drab cubes of strategy drones and the luxurious double cubes with round tables of their bosses.

Source: What makes a map?

Questioning DRY

tl;dr

Recently, I’ve been in conversations where people throw some doubt on DRY. In the cloud native, microservices mode of operating where independent teams are chugging along, mostly decoupled from other teams, duplicating code and functionality tends to come more naturally, even necessarily. And the benefits of DRY (reuse and reducing bugs/inconstancy from multiple implementation of the same thing), theoretically, no longer are more valuable than the effort put into DRYing off.

That’s the theory a handful of people are floating, at least. I have no idea if it’s true. DRY is such an unquestionable tenant of all programming think that it’s worth tracking it’s validity as new modes of application development and deployment are hammered out. Catching when old taboos flip to new truths is always handy.
Continue reading Questioning DRY

Bimodal IT leads to technical debt that must be paid, with interest

Instead, it has created a great divide, said Pucciarelli. “This siloed, divided approach brings frustration, disappointment and failure in multiple ways.” For one thing, it doesn’t support healthy team spirit, he said, and the innovation side tends to operate fast to deliver business solutions without the accountability around reliability, quality and security that is expected from the traditional IT side. “It leads to redundancy and inefficiency.”

Source: Bimodal IT leads to technical debt that must be paid, with interest

Maybe “bi-modal” is about temperament, not just enabling “sad IT”

More for the “I don’t think bi-modal is that far from what all us methodology hipster talk about” file here:

Q. Have you seen organizations that have officially reorganized around a Bimodal approach? What kind of job titles/job descriptions are you seeing?

It’s much less an organizational structure change, and much more about culture, process and method. But yes, it is not unusual in the short to mid-term to differentiate teams. Mode 2 usually starts life as being quite small, and often needs “protection”, to prevent the organizational anti-bodies killing it off. It is better to go narrow and deep and focus the capability on a particular part of the enterprise, or on particular domains like mobile for example. Small IT organizations (<50) don’t have the option to create any kind of split of course).

I'd still wager that most people who complain about bi-modal haven't read up on it too much (it's hard to do, and there's bat-shit expensive paywalls around it). Also, I think Gartner has been filling out the nuance of the original, clear idea: softening it and making it more practical, which makes it more ambiguous.

My theory here – based on conversations with people transforming large organizations – is that the focus here should be on the temperament of the people, not the process. For any given project, the proven process of small batches applies, but you’ll often want “cow-pokes” (risk takers who hate long term commitment) for new projects and “city-folk (enjoy stability) for post-1.0 projects.

There’s a chance for judgement about who the cool kids are vs. the old folks there, but I’d suggest finding that distinction is all about the perceiver. In my career, I’ve found people who are perfectly happy being in one of those two boxes. Problems arise (I think Apple’s negligence for apps their no longer interested in is a good bad result to ponder here), but I feel like it fits the staffing and prioritization needs of most large organizations.

But, I don’t call it “theory” for nuthin’.