The age of the customer demands more of companies, forcing them to change how they develop, market, sell, and deliver products and services. In response, CIOs must invest in business technology (BT) — the technology, systems, and processes to win, serve, and retain customers. At Forrester’s Forum For Technology Leaders in Lisbon (June 2-3), leaders from firms like BMJ, Portugal Telecom, BBVA, Mastercard, Alliander, DER Touristik and UniCredit will share strategies that you can use to achieve Read more
Formula One has gotten us all used to amazing speed. In as little as three seconds, F1 pit teams replace all four wheels on a car and even load in dozens of liters of fuel. Pit stops are no longer an impediment to success in F1 — but they can be differentiating to the point where teams that are good at it win and those that aren’t lose.
It turns out that pit stops not only affect speed; they also maintain and improve quality. In fact, prestigious teams like Ferrari, Mercedes-Benz, and Red Bull use pit stops to (usually!) prevent bad things from happening to their cars. In other words, pit stops are now a strategic component of any F1 racing strategy; they enhance speed with quality. But F1 teams also continuously test the condition of their cars and external conditions that might influence the race.
My question: Why can’t we do the same with software delivery? Can fast testing pit stops help? Today, in the age of the customer, delivery teams face a challenge like none before: a business need for unprecedented speed with quality — quality@speed. Release cycle times are plummeting from years to months, weeks, or even seconds — as companies like Amazon, Netflix, and Google prove.
A Continuous Delivery pipeline is a (mostly) automated software tool chain that takes delivered code, builds it, tests it, and deploys it. This simple concept gets complicated by tool chain realities: no one vendor does everything that needs to be done in the pipeline, and new solutions are evolving every day.
To make sense of the CD pipeline tool chain, I have taken a close look at the market and have identified a set of tool categories. I'm sure I've missed something, and you may not agree with my categories, and in either case I would like to hear from you! You can either comment on this blog, reach me on twitter (@ksbittner), or email me (firstname.lastname@example.org). If you think the categories sound right, I'd like to hear that, too. This is your chance to help define the continuous delivery tools market.
Continuous Delivery Tools & Technologies
Continuous Delivery is a process by which source code is built, deployed to testing environments, test, and optionally deployed to production environment using a highly automated pipeline. Many different kinds of tools need to be brought together to automate this process. The tool categories described below provide the building blocks of the automated Continuous Delivery process.
The pace of change for App Dev leaders has always been rather hectic. In my 32+ years as an "apps guy" - I can't recall a time when supply of technology resources ever fully satisfied all demand for the work that business leaders would like to do. Satisfying that demand has always been a challenging and constant balancing act. The past few years have heralded the age of the customer, where the voice of customers is amplified by social media and enabled by mobile applications - accelerating the pace of change for app dev & delivery leaders to a relentless pace. If you're hoping for a brief respite in 2015, it's time for rethink.
I have a love/hate relationship with "technical debt". Having covered apps modernization, rationalization, and portfolio management at Forrester for more than a decade, I have a keen appreciation for the concept of technical debt - in all its permutations.
So I love the term for the sentiment it expresses about the need for change:
As we have modernized applications over the past 4 decades, we have "kicked the can" down the road far too many times - opting for expediant change over "refactoring to make it right"
Within any mature single app, technical debt spawned by years of compromise can accumulate to daunting levels
The debt eventually reaches the point of becoming a self-fulfilling prophecy - today's debt is too big to tackle, so we kick it down the road and watch it grow out of control
Across the entire apps portfolio, the accrued debt cripples firms by gobbling up huge percentages of the available business technology (BT) spend
As we rush to build out customer facing and mobile apps to address the age of the customer, the technical debt within the systems of record act like an anchor on change velocity - at both the app AND portfolio levels
And I hate the term because well-intentioned techies wield it like a bludgeon to pound business leaders with an urgency to act. But imagine for a moment how it sounds to business leaders, how they react to the term:
"If it's technical, then its your problem Mr App Dev leader, not mine - I'm a business leader"
"This debt you want to hand me ... YOU created it, YOU made technology decisions - it's your problem, don't try to hand me a bill to clean up YOUR mess"
The modern business world echoes with the sound of time-tested business models being shattered by digital upstarts, while the rate of disruption is accelerating. Organizations that will win in this world must hone their ability to deliver high-value experiences, based on high quality software with very short refresh cycles. Customers are driving this shift; every experience raises their expectations and their choices are no longer limited. Like trust, loyalty takes years to build and only a moment to lose. The threat is existential: Organizations need to drive innovation and disrupt their competitors or they will cease to exist.
I had the good fortune of moderating a panel on the state of digital business at the Chief Digital Officer Global Forum in Singapore yesterday morning. The event showcased a who’s who of digital business leadership in the region, including my panelists Veena Ramesh of Johnson & Johnson, Jerry Blanton of Citi, and Veronique Meffert of Great Eastern Life.
Organizational issues are the greatest hurdle. There was not a single dissenting voice on the fact that organizational challenges represent the biggest impediment to digital business progress. The greatest organizational challenges are functional silos, business unit resistance, a lack of clear guidance from the CEO, rigid backward-looking mindsets, and a shortage of the skills needed to drive change. One approach — shared by Rahul Welde of Unilever — is to drive “digital experimentation funds” and “foundries” to drive co-creation innovation.
Media command centers are becoming critical marketing assets. Both representatives from Unilever and Philips spoke of the critical role that media command centers now play in their marketing campaigns. In the case of Philips, I was surprised to learn that its social media command center in Singapore employs 200 people — and that it is planning for expansion!
Unified information architecture, data governance, and standard enterprise BI platforms are all but a journey via a long and winding road. Even if one deploys the "latest and greatest" BI tools and best practices, the organization may not be getting any closer to the light at the end of the tunnel because:
Technology-driven enterprise BI is scalable but not agile. For the last decade, top down data governance, centralization of BI support on standardized infrastructure, scalability, robustness, support for mission critical applications, minimizing operational risk, and drive toward absolute single version of the truth — the good of enterprise BI — were the strategies that allowed organizations to reap multiple business benefits. However, today's business outlook is much different and one cannot pretend to put new wine into old wine skins. If these were the only best practices, why is it that Forrester research constantly finds that homegrown or shadow BI applications by far outstrip applications created on enterprise BI platforms? Our research often uncovers that — here's where the bad part comes in — enterprise BI environments are complex, inflexible, and slow to react and, therefore, are largely ineffective in the age of the customer. More specifically, our clients cite that the their enterprise BI applications do not have all of the data they need, do not have the right data models to support all of the latest use cases, take too long, and are too complex to use. These are just some of the reasons Forrester's latest survey indicated that approximately 63% of business decision-makers are using an equal amount or more of homegrown versus enterprise BI applications. And an astonishingly miniscule 2% of business decision-makers reported using solely enterprise BI applications.
The battle over customer versus internal business processes requirements and priorities has been fought — and the internal processes lost. Game over. Customers are now empowered with mobile devices and ubiquitous cloud-based all-but-unlimited access to information about products, services, and prices. Customer stickiness is extremely difficult to achieve as customers demand instant gratification of their ever changing needs, tastes, and requirements, while switching vendors is just a matter of clicking a few keys on a mobile phone. Forrester calls this phenomenon the age of the customer. The age of the customer elevates business and technology priorities to achieve:
Business agility. Forrester consistently finds one common thread running through the profile of successful organizations — the ability to manage change. In the age of the customer, business agility often equals the ability to adopt, react, and succeed in the midst of an unending fountain of customer driven requirements. Forrester sees agile organizations making decisions differently by embracing a new, more grass-roots-based management approach. Employees down in the trenches, in individual business units, are the ones who are in close touch with customer problems, market shifts, and process inefficiencies. These workers are often in the best position to understand challenges and opportunities and to make decisions to improve the business. It is only when responses to change come from within, from these highly aware and empowered employees, that enterprises become agile, competitive, and successful.
Our bi-yearly Forrester Agile survey suggests that Agile development (or simply "Agile") continues to see consistent, strong adoption. However, the same survey data shows that only a small percentage of firms are outsourcing Agile application development due to a lack of experience with the development sourcing approaches and governance models needed to make it work. Successfully outsourcing Agile development, either fully or partially, involves redefining roles and responsibilities, change management processes, metrics and SLAs, service descriptions, and other contractual elements. Merely using traditional outsourcing language and practices risks jeopardizing the benefits of Agile. There is no single way of doing this right.