Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

What IT Can Learn From the Beatles' Breakup

DZone's Guide to

What IT Can Learn From the Beatles' Breakup

It may not seem like the Beatles split means anything to IT, but trying to be too many things can teach us a lesson about building our DevOps toolchains.

· DevOps Zone ·
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

Image title

Why did the Beatles break up? Was it the death of their legendary manager Brian Epstein in 1967, the disruptive presence of Yoko Ono, or the creative differences between Paul McCartney and John Lennon?

All of those played a part for sure, but many music historians argue that it was the out-of-control bloating of Apple Corps, Ltd., the company the Beatles founded for their record label, which led to the epic split.

You may be surprised, but this is actually a cautionary tale for software delivery organizations as they plan their toolchain roadmaps.

From Good Intentions to Pandamonium

The Beatles originally founded Apple in 1968 to benefit from the lower tax rates afforded to corporations. The first division of the company, Apple Records, released many of the Beatles albums and subsequent solo albums in the 1970’s.

The group had a vision for Apple beyond taking care of their own financial and business affairs: Apple would help struggling artists get their projects off the ground.

Lacking any real business or financial competence, the Beatles began doling out money to any “freak” who walked in the door (George Harrison’s words), rarely seeing a penny in return. In addition, friends, executives, and hangers-on started receiving hefty salaries and spending outrageously at the company’s expense.

Through a combination of naïveté, benevolence, and a desire to change the world, under the Beatles’ direct management, Apple spun up dedicated business divisions for everything under the sun; consumer electronics, film, publishing, theater, retail, recording studios, and even real estate.

Yet they did none of those things well. Apple Electronics spent £300,000 (the equivalent of $6.5M today) to design impractical products that never sold. Amazingly, the Apple Boutique, which sold Beatles paraphernalia to troves of fans, was never profitable due to shoplifting by both staff and fans.

Instead of focusing on what the Beatles did well - making music and helping others make music - they tried to become everything to everyone, and all hell broke loose.

As a result of all the artist signings, silly investments and uncontrolled spending, Apple's expenses soared. The company and the group slid into financial chaos.

In 1969, both Paul and John realized they needed a professional to manage the company, but they could not agree on who that would be. John prevailed over George and Ringo to support his choice, Allen Klein, a man Paul simply could not stomach. According to Rolling Stone magazine, this “set off the conflagration that killed the Beatles.”

Will Your Toolchain Share the Fate of Apple Corps, Ltd.?

Every decade has its rockstar tools, tools that take the software delivery community by storm. Everyone is using them, everyone loves them. It’s 1965 and they are the Beatles of the IT toolchain.

Why do they so quickly become a favorite? Because they are perfectly suited to the way their users want to work. Perhaps it’s an Agile planning tool with a centralized space where everyone can work, contribute and comment. Or perhaps it’s an IT Service Management tool that structures workflow perfectly in a clutter-free UI that fosters collaboration.

Even though these tools are the darlings of their age and are used by hundreds, if not thousands of IT staff, enterprise software development organizations still use many other specialized tools for collaboration.

For example, business owners and program managers rely on their choice of planning and strategic portfolio management tools to provide the broader perspective and portfolio view they need. Requirements management and visual modeling tools provide product owners, business analysts, and architects with the governance, traceability and precision they need.

The variety and choice of tools available boosts productivity, with each and every practitioner working in the tool they love.

Still, every organization wants to be a high performer. Executives and practitioners alike realize that to accelerate lead times (and not just cycle times), people need to be collaborating seamlessly, with data and handoffs flowing between the tools automatically. Many organizations are now asking themselves, would it just make more sense to rationalize all these tools and put everyone on one single tool?

We smell a break-up.

Here, There and Everywhere

If you force everyone to work in one single tool, somehow that tool is going to have to meet the distinctly diverse needs of lots of different roles. There are two ways to accomplish that:

The first option is to bloat the tool. The vendor could add all the missing functionality to its tool to satisfy all those different roles. While possible, piling so much new functionality onto the tool will change it to no end. The leanness will be gone, the simplicity will be gone, and the people who loved it so much will no longer enjoy working in it. It'll be like taking Apple Music and adding Apple Consumer Electronics and Apple Films to it. The tool will quickly lose its identity.

The second option is to use plugins. You could fit that one tool with plugins that satisfy each and every team's needs. This, too, is possible but ill-advised. Plugins are often developed by small vendors with partial results, questionable support, and unclear roadmaps. Not to mention that plugins are restricted by the functionality exposed by the central tool and what its repository can accommodate.

In either case, by forcing everyone in your organization to work in one tool you risk losing agility in your toolchain architecture. An agile toolchain is no less important than an agile software architecture. In five years you will find yourself saddled with this extremely heavy single system, where nothing is modular or easily changed. Apple Records will be weighed down by Apple Publishing, which is weighed down by Apple Real Estate.

Let’s roll back a minute and recheck the rationale for consolidating tools in the first place. Often it’s executive pressure to cut costs on tool licenses. Yet executives fail to understand that you can actually reduce costs when you have multiple tools.

While somewhat counterintuitive, you can save money by reducing the number of licenses on expensive tools and increasing the number of licenses on cheaper tools. Moreover, by having only one tool, you diminish your negotiating power for its licenses. Despite having volume, you are so singularly dependent on that tool, you will be forced to pay any price for it.

The other driver for rationalizing is the desire for simplicity and improved collaboration. Management can sometimes feel the proliferation of tools means there’s no single source of truth. Information is scattered in several different repositories and in order to get a complete picture of what’s going on you have to log in to multiple applications and gather it piecemeal.

It is indeed true that an agile, best-of-breed tool strategy results in artifacts and workflows distributed in lots of different repositories. However, linking your tools through an off-the-shelf enterprise integration infrastructure can make them work together like one well-oiled machine.

Unlike consolidation on a single tool, with an integrated best-of-breed toolchain productivity will be maximized by giving every single practitioner the information they need, when they need it, in their preferred tool. And management will have a single source of truth - the integration layer - to view and measure performance, detect bottlenecks and prioritize future IT investments.

In Summary: Let It Be

As great as any single tool is, it cannot be everything to everyone. Let it be for its intended audience, the people who actually love using it.

The proliferation of tools is really not the source of any software delivery organization’s performance shortcomings. On the contrary, specialized tools are needed to make the specialized work of building great products possible.

Instead of lumping everyone together on a single tool, lay down an enterprise integration layer that will support your future toolchain choices. It’ll help you accelerate and reduce time-to-market by catering to your teams’ nuanced needs while allowing your toolchain to evolve and absorb changes without disruption.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
devops ,software delivery ,optimization ,agile ,toolchains

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}