Editor’s note: James Fairweather, chief innovation officer at Pitney Bowes, has played a key role in modernizing the product offerings at this century-old global provider of innovative shipping solutions for businesses of all sizes. In today’s post, he discusses some key challenges the Pitney Bowes team overcame during its digital transformation, and some of the benefits it has enjoyed from building new digital competencies.

Pitney Bowes will celebrate its 100th birthday in April 2020. Over the past century, we’ve enjoyed great success in markets associated with shipping and mailing. Yet, as with so many established and successful enterprises, we faced slowing growth in the markets that served us so well for so long. While package growth was accelerating, the mail market was declining, creating opportunities and challenges.

To change our growth trajectory and “build a bridge” to Pitney Bowes’ second century, we needed to offer more value to our clients. We needed to move to growth markets, and that required new digital competencies. In 2015, we began a deliberate journey to transform our services, including shipping and location intelligence, for the digital world and make them available via the cloud. We learned a lot throughout this journey. In this post we’ll take a look at three things, in particular, that led to the success of this project—and will help future projects succeed, as well.

Setting expectations and realistic milestones

Organizations tend to undertake product development with a sense of optimism—and it’s often not particularly realistic. You set out thinking something will take a certain amount of time and that you will incur a specific cost, but estimates in technology and development may be optimistic, and costs almost always incrementally increase throughout the development process. 

With a digital transformation effort, there’s an additional challenge: You aren’t really heading to a well-defined destination, so the path your team takes can be even more ambiguous. Digital transformation doesn’t have an end state. It’s a process of constant evolution.

For these reasons, and more, it’s important to set informed, realistic expectations—in schedule, in budget, in project scope. It’s also critical that you identify milestones along the way, and recognize and celebrate when you reach them.

When you’re working on a massive, multi-year corporate transformation, after all, it can be hard to recognize that every little action you take each week, everything you win day-to-day, is a part of your progress, your change. So, it’s really important, as a leader, to bring consistency and execution discipline—and be able to point to the progress being made and celebrate accomplishments.

We did our best to follow this advice during our digital transformation. Late 2015 was a critical time for Pitney Bowes as we laid out the technology strategy that would get us to the next century. We were aware of the potential hazards that could arise. You set the strategy, celebrate its publication as an accomplishment… and then nothing happens. To avoid this issue, we broke our strategy out into specific tactics supported by numerous smaller, interim goals. When we started putting big, green checkmarks next to each accomplished milestone, people started realizing that we were making real progress, and were serious about our execution.

One key milestone, for example, was implementing an API management platform. This comprised several granular goals: Selecting a partner, training a subset of our 1,100 team members on the platform, and rolling out our first offering that was built on top of that capability. 

We knew that an API platform would be a key part of our digital transformation for three major reasons. First, we had acquired several companies, but their technologies were difficult to share for use cases across the organization. Every time a team needed to use our geocoding or geoprocessing capability, for example, they had to spin up a new environment. By building these capabilities as APIs across the organization, it made it easy to democratize their usage and speed up development. 

Secondly, we were running a big enterprise business system platform transformation program and wanted our product teams to be able to consume data from our back-end business systems. This meant that we needed a solid catalog of all these services, so new members of the team could easily find and use them.

Finally, we had a couple of business units that wanted to go to market with APIs. They had a business strategy that entailed selling a service or value, with a vision to build a platform or ecosystem around these capabilities. An API platform (specifically, Google Cloud’s Apigee API management platform) is a huge accelerant in enabling all three of these objectives—it’s how you do this well.

Reusability and the Commerce Cloud

The Apigee platform and team helped us build a key offering that arose from our digital transformation: the Pitney Bowes Commerce Cloud. It’s a set of cloud-based solutions and APIs that are built on our assets and connect our new cloud solutions to our enterprise business systems, such as billing and package management.

Today, we have close to 200 APIs delivered from the Commerce Cloud in the areas of location intelligence, shipping, and global ecommerce. The Commerce Cloud isn’t just a success as a customer-facing platform, however. We often talk about whether our development teams themselves have leveraged its services when developing new products. These discussions help us understand whether a product team has thought through the digital capabilities we’ve already built, assessed which capabilities fits into its roadmap, and adopted the right technology, capabilities, and practices to align with our corporate digital transformation strategy.

Internal use of these shareable services shaves up to 70% off of our design cycles, because so many decisions are already made. Commerce Cloud adoption means you’ve gotten on the path internally, lowered the friction, and are aligned with the broader company digital transformation strategy. 

Measuring success

We’re proud of what we’ve accomplished so far at Pitney Bowes. But pride only takes you so far. To determine a project’s success, you need to be able to measure it. 

We do have some encouraging external measures: our percentage of revenue from new products climbed to roughly 20% of sales in 2018, compared to 5% back in 2012. And our Shipping APIs, which enable customers to integrate U.S. Postal Service capabilities into their own solutions, has gone from a standing start to an over $100 million business in a few years.

On top of those external results, our business has transformed. We’re no longer just participating in a one-time sale of a product, software, or services; we’re participating in transactions every day that drive client outcomes. The more you can improve the quality and effectiveness of those services, the more you and your client enjoy the benefits of the commercial relationship. That’s a very big business model transformation for Pitney Bowes.

We’ve also sped up our time to market and tightened our service-level agreements. But perhaps most importantly, we’ve developed and adopted a new set of internal processes and a mindset that helps us quickly adapt to changing market conditions. Again, digital transformation isn’t a destination. It’s really a set of processes that enable us to be nimble and keep building a bridge to Pitney Bowes’ future.

For more on the Pitney Bowes transformation, check out these videos and this case study.

Google Cloud and the DORA research team are excited to announce our eight sponsors for the 2021 State of DevOps report. We recently launched the 2021 State of DevOps survey, a 25-min survey for the DevOps community to share how they are using DevOps to improve software delivery performance. So if you haven’t taken the survey yet, this is your chance! 

For those unfamiliar with the State Of DevOps report, it is the largest and longest running research of its kind. It provides an independent view into how teams and companies can drive powerful business outcomes, no matter what stage of the DevOps journey

With the State of DevOps reports we aim to capture how teams and companies are driving excellence in technology delivery through the implementation of DevOps practices, no matter what stage of the DevOps journey your team is in. If you’re wondering how your team measures up in your industry take our DevOps Quick Check and discover which capabilities you should focus on to improve your performance.

To capture a diverse array of information on how those in the DevOps community are performing, our eight sponsors of the 2021 State of DevOps survey are focussed on helping organizations of all sizes and industries to develop and deliver software faster across the whole DevOps lifecycle. Captured below, you’ll find more information on our sponsors for this year and why they chose to sponsor the State Of the DevOps 2021 Report.

Armory

Armory enables enterprise companies to ship better software, faster through trusted, reliable, safe, and secure deployments — at its core, Armory is powered by Spinnaker OSS.

“Armory exists to unlock innovation through software. To achieve this, we help enterprises reliably deploy software at scale, naturally aligning with DevOps practices to improve software delivery performance. Given this, we applaud efforts like the State of DevOps Report that provides an independent view into the practices and capabilities that organizations can employ to drive better performance.” 

Carl Timm, Senior Director of Product Marketing at Armory

CircleCI

The world’s best software teams deliver quality code, confidently, with CircleCI. The world’s best software teams use CircleCI to go from next-up to feature shipped, at the speed ambitious businesses require. 

“Though the DevOps space is only over a decade old, it moves incredibly quickly. Google’s State of DevOps report is both a reflection and projection of the industry, capturing how DevOps culture drives business results and where DevOps practitioners can look to improve. At CircleCI, we rely heavily on this survey data to glean valuable insights into our market and our customers overall. We also build upon these insights to guide our own research into how engineering teams move code through pipelines in our annual State of Software Delivery report. Taken together, this research highlights teams’ reported and actual behavior and paints a vibrant picture of how technology-driven organizations drive for success.”

Emma Webb, VP, Corporate Communications, CircleCI 

Continuous Delivery Foundation

CD Foundation is an open-source community improving the world’s ability to deliver software with security and speed.

“Good decision-making is based on good data. Open source is a critical piece of the technology roadmap for DevOps, and the 2021 State of DevOps Report will provide actionable information for high performing teams in organizations of all types and sizes. The report will show where open source and DevOps intersect, and in a space that is changing so quickly, new relevant data is critical,” said Tracy Miranda, Continuous Delivery Foundation Executive Director. “CD Foundation members are deeply involved with producing this annual report, with over 10 years of historic research. Thank you to Google and our other members who have worked so hard on it. This report is a tangible result of working together.”

Tracy Miranda, Continuous Delivery Foundation Executive Director

Deloitte

Deloitte provides audit and assurance, tax, consulting, and risk and financial advisory services to a broad cross-section of the largest corporations and governmental agencies. At Deloitte, they are continuously evolving how they work and how they look at marketplace challenges so they can continually deliver measurable, sustainable results for their clients and communities.

“Software delivery is evolving rapidly and we know our customers need unique and compelling insights to make the right decisions. State of DevOps is a widely used report and considered as an Industry standard to understand the drivers for excellence in Software Development and Delivery. Deloitte is excited to help the team at DORA and Google Cloud in publishing this report through our sponsoring since we believe the insights from this report will help make software delivery better.” 

Manoj Mishra, Consulting Managing Director, Deloitte Consulting LLP

GitLab

GitLab is the open DevOps platform built from the ground up as a single application for all stages of the DevOps lifecycle enabling Product, Development, QA, Security, and Operations teams to work concurrently on the same project.

“We’re happy to sponsor the DORA Report and the vital work behind it. The more we understand the DevOps journey, the better we and our GitLab community can contribute to its future. We’re particularly interested to see this year’s results and the impact COVID-19 and remote work have had on DevOps. We appreciate the chance to be part of this exciting, informative process.”

Brendon O’Leary, Senior Developer Evangelist

Liquibase

Liquibase helps millions of developers easily manage database schema changes by enabling teams to track, version, and deploy database changes by delivering on the promise of CI/CD for the database.

“With their rigorous methodology, the DORA research team delivers actionable information with the simple goal of helping organizations of any size accelerate the development and delivery of software. Liquibase is honored to sponsor the 2021 State of DevOps Report and its role in helping so many organizations build value for their customers and shareholders”

Matt Geise, VP of Marketing at Liquibase

PagerDuty

PagerDuty is a digital operations management platform that empowers the right action, when seconds matter.

“As a leader in digital operations management, PagerDuty is proud to sponsor this year’s report as it aligns with our dedication to helping DevOps professionals make better decisions. This report will inform tech and business leaders about the trends/challenges developers are facing and the opportunities there are to accelerate their own DevOps transformation.” 

Carolyn Guss, VP of Corporate Marketing

SysDig

Sysdig is driving the secure DevOps movement, empowering organizations to confidently secure containers, Kubernetes and cloud.

“There is a learning curve with all new technology, cloud is no exception. Learning from mistakes and sharing best practices is how we will ultimately ship secure applications, faster. For seven years, DORA and Google have partnered to understand the State of DevOps to help vendors and cloud practitioners to learn from each other and implement standards for best practices,”

Loris Degioanni, CTO and founder of Sysdig

Google Cloud, the DORA team, and our sponsors are very excited about this year’s report. We look forward to hearing from you, your colleagues, and networks about how DevOps is integrated into your workflow and ways we can help to further improve your performance. Please share your experience with software delivery by completing our survey that will be used to foster the next generation of DevOps best practices. To provide ample time for the DevOps community to contribute to this industry wide report we have extended the deadline for the survey until July 2nd.

Thank you to everyone who has participated so far, and the Google Cloud DORA team looks forward to hearing from even more of you soon!

NBP, Pakistan’s largest government-owned bank, serves private and commercial customers and also acts as the government treasury bank. This means that it handles all government transactions—including disbursements and cash collection. In the past, every government transaction had to be handled physically through the NBP branch network. But in a populous country like Pakistan, managing the huge volume of financial transactions is a big task, especially if a single bank is the only conduit. While we’re still in the early stages, here are a few ways that we’re actively working to find solutions that overcome these challenges. 

Using APIs to increase access
Our digital banking implementation team, which includes product developers and a small in-house think tank, is responsible for developing new technology and out-of-the-box solutions tailored to the requirements of different areas of the bank. Our implementation partner Abacus played a key role in evaluating and implementing Apigee for NBP.

Recently, we developed a plan to open up the NBP government mandate to other banks and third-party fintech partners. Under this new model, instead of relying solely on our own channels, customers can now transact through fintech apps and other approved Pakistani banks. To be able to roll out a solution that would be reliable, scalable, and secure enough to meet our needs, we adopted Google Cloud’s Apigee API management platform. This platform allows us to accelerate our product development, so that we can compete in the fintech space. It also gives our customers access to a wide range of banking services through our own and partner channels.

As a government bank, NBP has to deal with a lot of procedural hurdles, which have slowed down our entry into the fintech market. Additionally, legacy systems required us to develop solutions for each particular channel and use case. APIs and API management increase the reusability of our services, while also bringing ease and speed of getting our services to market. In fact, we’ve seen the time it takes to offer a new solution reduced by 20%. Apigee not only helps us to achieve our go-to-market goals—it enhances our capacity to capture new and unique use cases across multiple channels. We appreciate the speed, agility, and security that Apigee brings us, along with its many out-of-the-box features. 

Reducing barriers to consumer services
One example of how we’re using Apigee is our passport collection use case. In Pakistan, to obtain a passport, citizens have to visit an NBP branch. This can involve waiting in long lines to deposit the government-required passport insurance fee. The sheer volume of these transactions was overwhelming our local branch teams, and costs for this type of manual transaction were high. Furthermore, the government had problems reconciling the fee collection with the passport transactions. 

To address these concerns, we developed an API that allows not only NBP branches, but also third-party banks and fintechs, to accept passport issuance fees.Customers can now visit the bank or fintech provider of their choice, reducing the load on NBP, while the government passport department inspectors can now easily reconcile these transactions. 

We also developed a bill payment solution with Apigee that gives customers the possibility of paying utility bills online. Previously, the NBP process was inefficient. We had an in-person bill payment mechanism operating in our 1,500+ bank branches. Now, we’ve integrated the payment API with the branch channel so that bill payment is automated, whether it takes place in a branch or online. 

Increasing the API footprint inside and outside the bank
Now that we’ve implemented the Apigee platform, our partner ecosystem is benefiting from it and growing, too. We’ve enrolled a wide range of fintechs that are developing products in the corporate payment space. We’re also planning to partner with several incubation centers to provide our APIs via sandbox environments, once our Apigee developer portal goes live. Other fintechs will be enrolled through the incubation centers as well. Finally, alternative third-party partners, such as fintechs and banks, will consume our APIs and/or partner with us for product development.

We’ve currently published 10 APIs and by the end of this year, we expect to have 25 to 30 live. We’re looking forward to implementing monetization, but not necessarily with revenue as the primary focus. As NBP is a government-owned bank, we have a responsibility to act as a catalyst for smaller players, and we see monetization expertise as an opportunity for fulfilling our mandate to help fintech startups grow and mature. In the long run, API revenues will certainly become more important, but the short-term goal is seeding innovation in the marketplace and providing the best possible retail banking experience for our customers, nationwide.

Cloud infrastructure offers so many advantages: on-demand scalability, built-in security, and a bevy of tooling to scale your business at the speed of the Internet.

It enables companies to pursue “blitzscaling,” as Reid Hoffman calls it. Capital expenses that take years or decades to pay off are no longer required to establish global networking, compute capacity, storage resources, and application enablement tooling. By renting these assets from cloud providers, you can translate capital costs to operational costs, help your company to manage resources efficiently, keep expenses aligned with growth trajectory, and develop a portfolio of business-driving technology assets faster than would have previously been possible.

Certainly, this is the message from many founders and venture capitalists: move to the cloud, build a ton of software, scale like crazy, and win. Sounds great, right?

But history has shown us that the process is not quite this simple. Scale can be great and is a prerequisite to many of today’s most exciting business opportunities — but scale also frequently produces unintended consequences. You need to be able not only to achieve scale but also to manage it.

When scale produces bloat

To understand how unforeseen impacts can ripple out from a rapidly-scaled technology, consider the first mass-produced vehicle, the Model T. The first production model was produced in 1908, and less than two decades later, Ford had produced 15 million. This rapid growth profoundly affected urban living for decades.

Thanks to cars, fewer workers needed to live near cities or along major public transportation lines. The ease-of-access to personal transportation led to suburban population centers and, ultimately, urban sprawl. “Sub-cities” extricated homeowners from the density of urban population centers but also created a complex web of unintended consequences: new and often duplicative administrative bodies, new taxes, new zoning laws, and more intricate infrastructure projects. We are arguably still dealing with this fallout today as communities grapple with antiquated zoning laws and, in their attempts to find ways forward, often produce only more sprawl.

If your technology is in the cloud, you may be challenged with similar issues. For example, when developers build software in the cloud, many of the barriers to building software are removed. As a result, developers build a lot of software — but often without a lot of intentional design. This in turn results in companies building a large number of disparate systems and overwhelming app sprawl.

The cloud can help you proliferate technologies so quickly, in other words, that effective management and re-use of resources becomes incredibly tough.

Managing scale

Software assets are often seen as comprising the “brains” of a company — but to effectively grow, you should consider not only brains but also the digital nervous system. You need systems that connect the brains to all of the other important limbs that have to coordinate in order for your company to drive value.

One way of creating this nervous system and managing this complexity is to leverage the facade design pattern: applying an API layer that abstracts the underlying complexity of multiple systems into an elegant, reliable interface that encourages discovery and re-use of applications, functions, and other technology artifacts such as build and deployment pipelines.

For example, too many enterprises build a new digital “road” for each application that needs to authenticate or authorize users. Instead, you can leverage a facade pattern to help establish one “main road” for these purposes, encourage reuse of the road for new projects, and — with API management — monitor and control all traffic along the road. For tasks such as aligning risk and compliance operations or unifying developer onboarding functions, the distinction between reusing elegant roads and continually building new complicated ones could not be more important.

API management tools mean you can establish a single-pane-of-glass view into your network of digital roads and destinations or, if you prefer the biology metaphor, into the nervous system routes connecting your company’s software brains. This view becomes a point at which suspicious API usage patterns can be detected, reported, and handled and through which business-driving insights from legitimate traffic can be gleaned. Rather than dealing with IT sprawl, you can maintain visibility over your assets, control how they are used, roll out experimental digital products and get immediate feedback on adoption, and generate analytics to help you effectively divest from and invest in opportunities as the market demands.

More is not always better

More is not always better, and, in fact, it is sometimes worse.

It’s a time-worn sales axiom that would-be customers are more likely to make a choice when presented with two or three options rather than fifty, for example, and virtually all of us can relate to moments of “analysis paralysis” triggered by too many choices. These dynamics of choice are such that the diminishing marginal utility of each choice can detract from each option: with each choice comes a little stress, and as these stresses accumulate, customer satisfaction suffers. IT systems are no different; if developers building new connected experiences are left to their own designs, rather than encouraged with standardized resources and best practices, their work may add to complexity and customer dissatisfaction.

One need look only at the various open air markets around the world to see this point in action. They may offer many things to see but the experience is anything but efficient. The multitude of shops selling similar and duplicate items, the zigzag layout, and the expected friction from bargaining with each vendor all mean concepts such as market-wide product discovery and product inventory go out the window. If your developer experience mirrors these marketplaces, your efforts to scale are more likely to tangle up your operations than to satisfy customers.

Contrast this experience with luxury retail experiences where product areas are clearly demarcated in different retail spaces, product explanations accompany showcase items, inventory is available locally or ready to ship, clear pricing is readily available, and similar stores are intentionally anchored to strategic physical areas to encourage customer flow among them. The developer programs that cloud efforts are often meant to enable require a similar focus on luxurious experiences.

If your growth strategy creates bloat, internal developers will not use resources efficiently and your ability to share resources with external partners will likely be hamstrung. Applying API facades helps to ensure that your growing software portfolio is not a complicated maze to be navigated but rather a series of technology products for developers to leverage.

Indeed, you should think of the API itself as a product, not just a way of surfacing or connecting technology. The better the product, the more easily it can be managed, the better the experience developers will have using it, and the more control you’ll have harnessing the cloud to extend your business’s footprint.