App development teams need to adapt to business-led IT

App development teams are at an inflection point: They can act as sole producers -- and fail to meet digital demands -- or enable business-led IT with application building blocks.

Software delivery is no longer a job restricted to corporate IT departments. For every dollar spent by corporate IT, the rest of the enterprise spends at least another 49 cents on "digital" -- whether through direct procurement or efforts by "citizen developers" working in business lines.

The growth of business-led IT has influenced CIOs to rethink corporate IT's operating model, from planning and engagement through delivery and support. In the age of business-led IT, software development cannot just be a matter of delivering finished systems; application development teams must also support delivery of the components that business units can use to build their own digital products and services.

App development teams thus have to reposition themselves to provide the building blocks for business and enterprise digital strategy, enabling development to scale across a wider ecosystem of business units and third parties -- and ultimately meet digital demands.

This repositioning to support business-led IT can take many forms, including:

  • self-service portals that enable business users to change and configure software with minimal assistance;
  • APIs and microservices that allow teams to isolate and connect application features; and
  • platforms that enable distribution of new applications.

But the shift in positioning by app development teams isn't just a matter of making components and code available to business lines. It also requires a change in mindset toward thinking about the building blocks of applications as products that meet a business user's needs.

In other words, the first question applications leaders need to ask is what components, tools, and oversight do the business lines and their partners need in order to use and/or assemble application building blocks on their own.

API-first strategy: Three guidelines

Leading companies put this product mindset into action through "API-first" strategies in which APIs offered to business units and third parties become the primary product of the IT development teams.

Three lessons have emerged as these approaches have evolved: 

    1. Consider the digital business perspective first.

It's tempting for app development teams to crank out APIs under the premise that the more created, the more digital services the enterprise's business-led IT teams can build. This overlooks the critical first step in any digital strategy: understanding the current state of the enterprise's business capabilities and mapping how and where they need to advance in order to meet digital objectives. While this may sound academic, it's essential to both prioritizing the production of APIs and avoiding APIs that won't see adoption or usage.

One company we work with looked at its business capabilities through the lens of digital interoperability. For the capabilities they deemed most important to achieving their digital objectives, they asked how easily new systems, services and data could tie into those capabilities. They used that assessment to determine where the enterprise should prioritize API development -- for example, in areas that represented clear business opportunities as interoperability improved.

    2. Figure out corporate IT's comparative advantage.

Even when business capability mapping is used to help prioritize API development, many app development teams shoulder the full burden of development. But this approach risks falling into an old mindset -- that the enterprise wants APIs, so IT will produce them, even if IT developers will struggle to keep pace with demand.

Smart API-first strategies, on the other hand, recognize that what the enterprise really wants is not APIs but simplification and speed. Thinking in terms of these outcomes leads to not only the production of APIs by app development teams but the delivery of tools and environments that allow business users to develop their own APIs. In other words, app development teams don't need to be the sole producers, but API enablers -- and ideally should only build APIs when their involvement brings a distinct advantage.

One company used its business capability mapping to focus its app development team efforts on just those APIs that had the most complex information risk and compliance requirements -- areas where IT professionals had the most expertise and insight. For APIs with less complex requirements, corporate IT provided oversight and coordination but permitted business units to lead API development independently. By doing so, the IT department and its app development teams adhered to its philosophy that, with appropriate risk management, development should be something that IT enables rather than owns.

    3. Build a marketplace, not a store. 

Corporate IT development functions are at a strategic inflection point -- do they continue to emphasize their role as producers, or consider pivoting to become enablers of a broader and potentially more rewarding development ecosystem?

Corporate IT development functions -- app development teams included -- are at a strategic inflection point: Do they continue to emphasize their role as producers, or consider pivoting to become enablers of a broader and potentially more rewarding development ecosystem?

At enterprises where corporate IT sees itself as sole producer, APIs are often offered to the business through a store similar to an app store. This model presupposes that corporate IT runs the store, and that everyone else is a consumer. But if the goal is to enable API development (and sharing) within business lines, corporate IT should offer a marketplace, not a store.

A marketplace offers not just APIs to potential consumers, but also the tools for other potential producers to build, test and share their own APIs. It serves as a hub to build and offer APIs, complete with descriptions, usage statistics and consumption readiness information. This makes corporate IT an enabler for business-led IT, setting up the guidelines to ensure all APIs meet regulatory standards, avoid redundancies and help consumers use APIs effectively and independently. The ideal marketplace is facilitated by corporate IT, but functions as an active environment for learning, building, testing and sharing, scaling development across a wider ecosystem.

App development teams at inflection point            

As technology advances, there's been a clear trend toward simplification in development, from low-code environments to tools that enable simple, modular design and code reuse. This creates opportunity for many enterprises to scale development against digital demands, whether through citizen developers in business lines, third parties or even crowdsourcing techniques.

Application building blocks -- the raw materials that will form new digital products and services -- provide more than just a simpler path to development for the IT organization and its app development team. They provide a simpler path to development for the enterprise as a whole.

Opportunity is with the enablers of business-led IT. Providing the building blocks of applications ensures that every business project can, without a great deal of additional effort, become a technology project.

 About the author:

Mark Tonsetic is a former IT practice leader at CEB, now Gartner, specializing in infrastructure and applications.


Next Steps

Recent advice from the experts at CEB:

Running Agile at scale

Fundamentals of the new IT-business engagement model

What is product line management

Dig Deeper on Enterprise application development, DevOps and software agility