Software delivery is no longer a job restricted to corporate IT departments. For every dollar spent by corporate...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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; it has to support delivery of the components that business units can use to build their own digital products and services.
Application 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 application 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 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 corporate IT departments 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 recognize that what the enterprise wants is simplification and speed. Thinking in terms of these outcomes leads to not just IT-led production of APIs but the development of tools and environments that allow business users to develop their own APIs. In other words, corporate IT doesn't need to be a producer, but an enabler -- and ideally should only build APIs when it brings a distinct advantage to task.
One company used its business capability mapping to focus corporate IT development on the APIs that had the most complex information risk and compliance requirements -- areas where corporate IT 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 adhered to its philosophy that, with appropriate risk management, development should be something that corporate IT enables rather than owns.
3. Build a marketplace, not a store.
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 corporate IT. They provide a simpler path to development for the enterprise as a whole.
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?
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 IT practice leader at CEB, a best practice insight and technology company, where he works with IT leaders in infrastructure and applications.
Recent advice from the experts at CEB:
Running Agile at scale
Fundamentals of the new IT-business engagement model
What is product line management?