Good intentions & indolent portfolio management lead to legacy quicksand

The downward spiral (driven by budgeting, risk-aversion, and ROI-think) that make legacy IT bloom like algae in a stagnant creek, from Chris Tofts:

With a limited budget for maintenance or improvement, how will it be allocated to the various systems managed by IT? Remember that in having to justify the spend at all, the primary need is to demonstrate business impact and – equally – guarantee that there is no risk to continued operations.

Inevitably, depending on organisational perspective, there are essentially three underlying approaches. First, maximise the number of systems that have been updated: demonstrate lots of work has taken place. Next, minimise the risk that any update will fail: have no impact on the ongoing organisation. Finally, maximise the apparent impact on the direct customers for IT systems – improve the immediate return to the business.

If the organisation maximises the number of systems updated then the clear imperative is to choose systems that are easy (cheap) to update. The systems that are cheap to update are invariably the ones with the least difference between in-use and current. In other words, the systems that were updated during the last round of updates. So the organisation will choose to improve those systems just beyond some minimum obsolescence criteria and until all of the budget is spent.

And then, you get bi-modal infrastructure:

It’s hard to say what the fix is beyond “don’t do that.” Perhaps a good rule of thumb is to attack the hard, risky stuff first.

Getting The Business to pay attention to legacy like they do cash-losses is also an interesting gambit:

As boring as it sounds, if organisations had to carry technical debt on their books – just like they carry the value of their brand on their assets – then, finally, they might understand both their exposure and necessary spend on their critical IT assets.

Link

The coming billions in updating bank’s COBOL stacks

Commonwealth Bank of Australia, for instance, replaced its core banking platform in 2012 with the help of Accenture and software company SAP SE. The job ultimately took five years and cost more than 1 billion Australian dollars ($749.9 million).

Being conservative, multiply $500m across the top 20 banks, and you’ve got $10bn, using $749.8m directly, you get much closer to $15bn.

Better start planning.

Source: Banks scramble to fix old systems as IT ‘cowboys’ ride into sunset

HPE Software sold for $8.8bn, to Micro Focus

While HPE is getting $2.5bn in cash, the whole deal value is more like $8.8bn, the non-cash being stock. More details:

The Numbers

  • “Under the deal, HP Enterprise shareholders are expected to end up with Micro Focus shares currently valued at about $6.3 billion. Micro Focus will pay HP Enterprise $2.5 billion in cash.” (WSJ)
  • There’s about 12,000 people in HPE Software. (WSJ)
  • HPE Software revenue: “HPE’s software unit generated $3.6 billion in net revenue in 2015, down from $3.9 billion in 2014.”
  • Put another way, from TBR: “2Q16 software revenue [had a] decline of 18% year-to-year, driven down by a license revenue decline of 28% year-to-year.”
  • HPE has been divesting a lot, getting a hoard of cash: “In earlier transactions, HP Enterprise in May completed a $2.3 billion deal in China to sell a 51% stake in a venture there called H3C that sells networking, server and storage hardware and related services. Later the same month, HP Enterprise announced a deal to spin off a computer services business that employs about 100,000 people—two-thirds of the company’s total head count—and merge it with operations of Computer Sciences Corp.”
  • Also: “The company sold at least 84 percent of its 60.5 percent stake in Indian IT services provider Mphasis Ltd to Blackstone Group for $1.1 billion in April.”

What now for HPE?

Continue reading HPE Software sold for $8.8bn, to Micro Focus

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.

What I’m looking forward to at SpringOne Platform

The biggest cloud native conference is coming up at the first week of August, SpringOne Platform. To plan out my time I took at look at the sessions. Here’s what I’m looking forward to and what I think you, dear readers, will find interesting as well. Doing a list like this, of course, ends up excluding some awesome sessions, so be sure to check out the talk list yourself as well.

Also, if you’re interested and haven’t registered yet, be sure to use the code pivotal-cote-300 to get $300 off.

Dealing with legacy

Almost every conversation I have with large organizations involves a discussion about dealing with legacy software. While you may not be running JFK era IT, you probably have to deal with legacy. Here’s some sessions on that topic:

Cloud Native Coding

Moving to The New, New Thing requires different ways of architecting and coding your software. Here’s some sessions that go over those new ways:

Case Studies

While cooked up demos of Pet Stores and Breweries are education, I’m most interested in hearing tales of what’s actually happened out in the world. Here are some of the case studies that look interesting:

The Usual Chuckle-heads

And, to highlight talks from my team:

(And, remember: if you want to come, you can get $300 if use the code pivotal-cote-300 when you register.)

Five Things You Need To Know About Microservices | EMCInFocus

“For those not familiar with the concept, microservices is essentially a software architectural design pattern. The fundamental premise of microservices is that value can be unlocked through decomposing large, monolithic legacy applications into a set of small independent, composable services that each can be accessed via RESTful APIs.”

Five Things You Need To Know About Microservices | EMCInFocus