Embracing open IT: Enabling the permeable enterprise

Embracing open IT: Enabling the permeable enterprise
By positioning IT capabilities as a platform composed of open, self-describing, modular services with reliable interfaces, CIOs can enable the permeable enterprise and create new strategic options in digital ecosystems.
By Bud Mathaisel, Patrick Shankland, and Vinod Baya

If CIOs are going to be successful in the new world of social, mobile, analytics, and cloud (SMAC) trends, they need to think differently. Legacy ways do not scale well to the possibilities of digital ecosystems. To increase the speed of development and co-create their futures with internal and external third parties, CIOs need to adopt a new mantra: go open. This co-creation mandates a new open platform enabled through application programming interfaces (APIs), especially representational state transfer (RESTful) APIs. More than a technology purchase, “go open” is an architectural transformation necessary to create and participate in digital ecosystems and to enable permeable enterprises. (See the article, “Exploiting the growing value from information,” on page 06.)

As business ecosystems become more digital, the value drivers increasingly come from the information (bits) augmenting the physical product or service (atoms) it represents. By engaging with emerging digital ecosystems, CIOs are tapping into these value drivers, seeding a digital operating model and creating new strategic options for their organizations.

RESTful APIs are the catalytic enablers for the open digital ecosystem. They are the self-describing interfaces and data packages organized in business-relevant and logical hierarchies, accessible via HTTP.1 They define the idea of open, accessible, self-service interfaces, which are also important for engaging with the consumerization of IT trends. By making an organization more permeable, RESTful APIs establish a universal shared architecture and collaboration model for linking software and systems as networks, bringing the benefits of Metcalfe’s Law2 to software components.

IT can take a quantum step to deliver on the promised value of information for both internal and external users. The key to delivering this value is RESTful APIs, which provide the technical underpinnings for loose coupling as detailed in the article, “Consumerization of APIs,” on page 34. Without this loose coupling, the complex interdependencies of traditional systems integration generally lead to steep learning curves for programmers, less reliable software components, the possibility of very long development times, and user frustration over what is delivered. RESTful APIs are the major ingredients that have made the new digital ecosystem possible over the past five years. “It’s a confluence of many things,” says John Donovan, senior executive vice president of technology and network operations at AT&T. “It’s the quality of the APIs; it’s the skill set of the API developers; it’s the evolution of the JavaScript; it’s the evolution of how code is developed.”

The time is right to take advantage of this confluence.

The open IT transformation

“Statistics we have collected suggest that using [RESTful] APIs reduces development time by 50 to 75 percent.”
—Devon Biondi, Mashery

Open IT delivers information services that internal and external audiences build on rather than passively accept as the endpoint in an information supply chain. It requires a change from delivering and maintaining full, end-to-end applications to delivering a platform with modular capabilities expressed as reliable interfaces. (See Figure 1.) This change is now possible due to the sharply lower cost and complexity of integration during the development of new capabilities. “Statistics we have collected suggest that using [RESTful] APIs reduces development time by 50 to 75 percent. What used to take six to eight months to integrate now requires hours or days,” says Devon Biondi, vice president of strategy services at Mashery, an API management vendor.

Figure 1:
Open IT builds on prior or ongoing SOA efforts and reorganizes IT capabilities in modular chunks to allow co-creation with internal and external partners

Figure 1: Open IT builds on prior or ongoing SOA efforts and reorganizes IT capabilities in modular chunks to allow co-creation with internal and external partners

The combination of self-describing interfaces (RESTful APIs), identifiers (Uniform Resource Identifiers [URIs]),3 and standard access methods (HTTP) helps mitigate the long lead times for development and high costs created by tightly coupled, proprietary integration methods. AT&T, for instance, now exposes a growing catalog of RESTful APIs—such as billing, subscriber profiles, device characteristics, and messaging—that cut the time developers require to deploy their applications on AT&T’s network from months to days.

“A lot of employees today are savvier with IT, as they have grown up with the Internet and associated technologies and services. They want to be able to get their work done and have the capability to build or procure IT services.”
—Brian Katz, Sanofi

IT organizations typically have long lists of projects proposed by internal customers—lists that seem to grow longer over time. SMAC trends are likely to exacerbate this issue, leaving business units even more frustrated. “When they take a request to IT, the answer is often ‘no’,” says Brian Katz, head of mobility industrialization and engineering at Sanofi, a global diversified healthcare leader. Such dynamics prevail where the IT function continues to operate as the sole provider of end-to-end application functionality. However, the world outside IT has changed. “A lot of employees today are savvier with IT, as they have grown up with the Internet and associated technologies and services. They want to be able to get their work done and have the capability to build or procure IT services,” Katz says.

The central IT function is clearly responsible for delivering core systems and services. The distribution of responsibilities is shifting, however. “We in IT don’t have to do all the coding anymore,” says David Zanca, senior vice president of IT, customer access, and revenue systems at FedEx Services. “The key role for my group is to be the owner, producer, and platform of the services.” With a RESTful-inspired architecture, IT can deliver robust and reliable interfaces against the core systems. Business unit leaders and their business-unit IT staff can take advantage of these interfaces by combining them with self-generated or sourced functionality to create new capabilities. Through this co-creation process, marketing, sales, and other internal groups can become full partners with the IT organization.

CIOs must make these investments. “If the CIO’s team doesn’t understand this market and is waiting for technologies to mature or standards to emerge, competitors are going to eat your lunch by being more nimble,” warns John Musser, founder of ProgrammableWeb.

The good news is that the broad outlines of how to open IT are amply demonstrated on the consumer web, and enterprise-class tools and supportive infrastructure are becoming available. “CIOs historically haven’t had the toolkit to provide open services,” says Sam Ramji, vice president of strategy at Apigee, provider of an API management platform. API management solutions allow enterprises to take their existing IT assets and turn them into platforms that bring the enterprise into the digital ecosystem.

API interfaces: A new boundary to link IT with business

At many enterprises, a typical IT stack for applications might look like the example in Figure 2, composed of three layers. The core, enterprise resource planning (ERP), and other large enterprise-wide applications and associated data warehouses remain the foundation, and they are the source and repository for data for transactions. These data are the most precious enterprise assets. The middle layer contains the functional applications that use these data assets and support functions, such as pricing, inventory, finance, web retail store, and others. The third layer is at the edge, closer to engagement with employees and customers, and builds on the other two layers to provide role-specific solutions such as collaboration, reporting, and so on.

Figure 2
The IT application stack in traditional IT and open IT and highlights of some of the changes necessary

Figure 2: The IT application stack in traditional IT and open IT and highlights of some of the changes necessary

In traditional end-to-end ownership of IT, the information flows from the core systems to the edge applications accessed by employees and customers. The flow could be mediated by middleware, proprietary or internal APIs, service-oriented architecture (SOA) efforts, or other mechanisms. But central IT maintains full control and responsibility for the full stack from the core to the edge. In contrast, in open IT, the information flows between the core systems and the RESTful APIs and open APIs. These APIs, which represent a new edge or boundary, expose the capabilities across the IT stack of the enterprise and the related information assets as services, becoming the building block for new services. Central IT does not have responsibility for the end-user application at the edge, but has the responsibility to support the level of traffic and the service level agreement that API usage might entail. Figure 2 also highlights other key changes in each of the layers when transitioning from a traditional stack to an open IT stack.

RESTful APIs enhance the commercial value of enterprise data and information assets in a digital ecosystem. These interfaces even make it easier to organize IT in a manner synergistic with business, a challenge IT has faced all along. Streetline, for example, defines business requirements and API logic together as the company builds out its digital ecosystem for parking operations. “There are APIs for each use case: a parking status API, a meter payment API, a payment status API, and so on,” says Peter Leiser, vice president of engineering, platforms, and applications at Streetline, a global provider of smart parking solutions.

Reorganizing and energizing the IT function for open IT is a key to the digital future. To realize the full potential of a digital operating model, there are four leadership opportunities for the CIO:

  • Embrace a new architecture.
  • Address a new audience: internal and external developers.
  • Overcome new challenges from openness.
  • Upgrade organizational skills.

A new architecture

A good layered IT architecture—distributed, client/server, object-oriented—has been important for more than 30 years, but not until today, with the emergence of web-based services and consumerization of IT, have enterprises had such a compelling reason to revisit their IT architecture.

“At the highest level, this is an architectural change. You need to architect your platform and environment for co-creation and treat APIs as products that you publish and maintain for long periods of time.”
—David Zanca, FedEx Services

Open IT, based on RESTful APIs, will require changes inspired by platform thinking and loosely coupled, self-describing, modular capabilities. “At the highest level, this is an architectural change. You need to architect your platform and environment for co-creation and treat APIs as products that you publish and maintain for long periods of time,” advises Zanca of FedEx. The goal is an architecture designed for compatibility with emerging digital ecosystems. One characteristic of RESTful APIs consistent with this architecture is their readiness for a pull-centric world, where users invoke existing services and create new services, versus the traditional notion of IT pushing services.

Traditional architectures are optimized for batch calls against the core, usually high-volume electronic data interchange (EDI) or Extensible Markup Language (XML) format interchanges. This requirement is unlikely to change in the digital ecosystem. What will change is access calls through APIs that will put additional stress on the core. The new architecture should harden the core while providing more permeable binding for API requests.

Also influencing this architectural change is a higher pace of new application adoption in the enterprise caused by SMAC technologies. This adoption cycle lies in stark contrast to how fast core systems can or should be changed. An architecture that takes the core capabilities and makes them into platforms with modular interfaces allows a faster pace of application evolution at the edge. AT&T organized its API program to match this pace. “It is an architectural choice one makes for speed,” says Donovan, explaining why AT&T created an API program.

In addition to publishing services for others to consume, most enterprises will also consume external services to enable their business. Also, all major enterprises do operate a large pool of vendor-bought solutions. The CIO organization therefore will become an orchestrator of services—across vendor capabilities, published services, and consumed services—a role that the new architecture will need to acknowledge and enable.

The growing number of devices used by employees and customers to access enterprise IT is also a consideration in the new architecture. “We also have a continuously connected strategy where we create a thin layer of services, which are independent of end-user devices and use cases,” describes Zanca. FedEx created this thin layer of customer experience services on top of its enterprise services to expose them as RESTful web services.

An API-friendly architecture shift also has implications for IT security at two general levels. Security for the core is intrusion prevention oriented, and it may also be optimized around batch movement of data. Security in support of an API strategy is both intrusion prevention oriented and rights managed—a certificate issued to a specific user for a specific data element for a specific period of time.

New channel, new audience

“ The real opportunity for CIOs is to develop the strategy for how the enterprise participates in the digital indirect channel.”
—Sam Ramji, Apigee

Open IT positions enterprise IT assets to engage with the digital ecosystem internally and externally. For many IT groups, this engagement will require a new competency—to work with a developer community outside the IT organization. With published APIs, third parties are encouraged to, and will, develop capabilities that will benefit the enterprise and the third parties. “The real opportunity for CIOs is to develop the strategy for how the enterprise participates in the digital indirect channel,” says Ramji. For Ramji, the digital indirect channel is what APIs make possible by giving access to a large and growing pool of internal and external developers. “[CIOs] need to get the channel leader, marketing leaders, and technology leaders in one room and say, ‘We have a new channel,’” Ramji adds.

To expedite the adoption of open platforms, some IT organizations establish a developers’ resource center or an API program by productizing the chosen capabilities and features as modular services with stable interfaces. Although AT&T has had a developer program for years, the company has accelerated its use of RESTful interfaces and related open architecture during the past two years. This transition allows AT&T and the developers to surface new opportunities to monetize AT&T’s network assets. The intent is to make all of the network capabilities addressable by enterprise or commercial developers. “Where do you put APIs? You literally put them everywhere. That’s how you do internal development; that’s how the IT shop works; that’s how your outsourcer does development for you; that’s how you build services,” suggests Donovan.

Such an undertaking is akin to shifting the role of the CIO to be more like the CEO of a software product company, one that provides the APIs and software as part of a proprietary package for customers and developers. “When I talk about the priorities in my digital access group, one of them is to think and act the way a best-in-class software company would,” says Thomas Wicinski, vice president of digital access marketing for FedEx Services. In addition to procuring and implementing vendor solutions, CIOs also need to design and architect a platform and interfaces that remain reliable over generations of use.

As an IT organization works to empower external developers, it may follow a maturity path as illustrated in Figure 3. The journey starts with exposing some basic capabilities and associated documentation. As a company matures, it will attract more developers and make more comprehensive capabilities available, creating a partnership-oriented business model. “We’re getting faster, and one result is that the architecture is shifting to allow more partnerships,” says AT&T’s Donovan. AT&T today exposes APIs for location, messaging, speech, device capabilities, and billing, and many other APIs are in the future road map.

Figure 3
Stages of maturity in developing an internal- or external-facing developer program

Figure 3: Stages of maturity in developing an internal- or external-facing developer program

Successful developer programs include numerous elements that complement each other to achieve market objectives. (See Figure 4.) As they develop their programs, organizations will analyze and consider many features, such as program fees, API access fees, and developer or app certification in their go-to-market strategies. They will gauge success by analyzing measures such as the number of engaged developers (internal or external), the quality and quantity of third-party applications, the volume of API calls, end-customer engagement, and monetization of the service. Measures also extend to internal activities. “Another measure [for the API program] that we’re using is how many new APIs we are releasing as a cadence around our progress in opening up more of the network,” shares Jacob Feinstein, executive director of new technology at AT&T.

Figure 4
A successful developer program has many elements to achieve market objectives

Figure 4: A successful developer program has many elements to achieve market objectives

Addressing API adoption challenges

While the RESTful API programming model and integration architecture are fairly well established and scalable to accommodate large enterprise services, most enterprise IT organizations have little experience with them. Moreover, APIs span a wide range of past and present technologies, as detailed in the article, “Consumerization of APIs,” on page 34. Going forward, enterprises need to evolve approaches for consuming and offering RESTful APIs that address several challenges.

Challenges in consuming APIs:

  • Diverse API technologies—Although an enterprise may prefer RESTful APIs, API architectures, protocols, and interfaces may vary across publishers of APIs. This diversity complicates the development of enterprise and mobile applications that serve or utilize services from multiple providers.
  • Reliance on provider capabilities—The quality of interfaces may be inconsistent, and they may have poor definitions regarding contracts and service schemas. Variations in quality of service and independent API versioning schedules across APIs can cause disruptions.

Challenges in offering APIs:

  • Asset vulnerability—API adoption introduces enterprise assets to new vulnerabilities. Interaction with third-party providers exposes applications to message manipulation and injection attacks from external sources.
  • Performance delivery—The use of third-party functionality introduces additional hops and can increase the length of round-trip requests. Restricted capacity and processing performance limit devices’ ability to efficiently develop, consume, and utilize large service messages.

As providers and consumers gain experience with RESTful APIs, some best practices for addressing these challenges are emerging. Table 1 organizes some of these methods.

Table 1
Mitigation approach to the key challenges in consuming and providing RESTful APIs

Table 1: Mitigation approach to the key challenges in consuming and providing RESTful APIs

Upgrading the IT organization for the digital ecosystem

Moving into the new digital ecosystem is an organizational challenge for the CIO. First, if the enterprise IT group (and outside service providers) historically has been optimized around the design, deployment, and operation of core systems, it is unlikely the organization has many of the new skills needed.

Second, the traditional structure of formal, separate organizations for development, infrastructure, security, and so forth are unlikely to enable the flexible invention that is the pulse of the digital ecosystem.

Third, the methodologies employed by most IT organizations, including capability maturity models, the IT Infrastructure Library (ITIL), and the methodologies that come with large systems, such as ERP, are inconsistent with the fast development cycles needed to pioneer the new capabilities.

Recognizing such impediments, CIOs can use the digital ecosystem opportunity to perform a current state assessment of their organization’s capabilities. This exercise will allow them to establish the future state organization design, skill sets, and methodologies for development and deployment. If IT wants to perform the role of a software company, much more emphasis must be placed on platform architecture, on technical openness, and on marketing, sales, packaging, and support than is normally the case.

The IT organization must assess its skills and tools in light of the new context. Many IT organizations have not updated their skills, especially in the economic downturn. One major constraint can be the lack of understanding about RESTful API capabilities. The CIO’s team needs RESTful API literacy. “RESTful API ignorance is a risk that no CIO wants to be accused of a couple of years from now,” says Musser.

Many job descriptions still feature experience with decades-old technology. Many IT organizations have outsourced custom development—perhaps all development—and have no insight into the details of the job skills contracted for. A move to open IT would be an opportunity to offer attractive career growth to staff who have the skills the organization needs to participate in a digital ecosystem.

The CIO needs to focus on building a web-, mobile-, and cloud-competent IT organization. To achieve such an organization, CIOs are separating web development and deployment teams from those that develop and deploy the core, placing them under leadership separate from the applications development organization. Some digital ecosystem CIOs are establishing incubator groups, centers of excellence for SMAC and/or RESTful development that sometimes are located off the main campus. These groups focus on building up a competency in a given area and acting as evangelists for the methods, tools, and so forth that will be used in the future. In addition, the members of these centers might begin to plan, execute, and gain experience building the future state architecture that has been laid out by the CIO. The great news is that many in the IT organization today are anxious to upgrade their skills, and they would welcome the opportunity to learn new skills and technologies. Additionally, the digital ecosystem job opportunities are what attract the people who have the skills needed for the evolving IT group.


Many CIOs are concerned about the chaos that could be caused by the accelerating disruptions associated with SMAC trends. For some, however, it’s a blessing in disguise. These CIOs are learning to proactively engage with SMAC by adopting a digital operating model, powered by RESTful APIs and supported by API management platforms. In the process, they also open up new business opportunities for their enterprises in permeable digital ecosystems.

As SMAC trends accelerate, PwC expects that most enterprises will increasingly incorporate features of information (bits), even if they are still in a physical business (atoms) such as retail, distribution, manufacturing, and healthcare. To successfully navigate this transition, enterprise IT organizations must adopt many core competencies of software companies; in particular, they must create platforms the way that software companies do. Just as software companies build successful platforms, enterprise IT will build and manage APIs in a manner that opens up IT for the co-creation of new services internally and externally.

An open platform does not call for a frontier mind-set, where fragmented API generation replaces a carefully managed applications portfolio that CIOs strive to maintain. CIO leadership must keep a balance in this evolution and manage IT assets in new ways. The advice to CIOs is to approach the evolution in four dimensions: business need or purpose, an enterprise architecture for a digital operating model, developer community management, and gaps in organizational capabilities.

First, recognize the hidden potential created by unlocking the enterprise’s information assets, and identify specifically which data would be exposed for what business purpose.

Second, devise the new architecture inspired by RESTful APIs and platform thinking. RESTful APIs are pull-centric, not the traditional push model. The new architecture hardens the core while thoughtfully exposing the valuable assets captured by the core—information—via RESTful API connections.

Third, approach the digital ecosystem opportunities by targeting an audience of developers who can create new business value based, in part, by extending your capabilities. You can start with existing mobile projects that can benefit most from APIs, and let the momentum build from there toward a platform and API program.

Fourth, use the digital ecosystem opportunity to upgrade your organizational structure and skills in the context of the inexorable shift toward a new operating model. Apply new leadership approaches to recruit and manage these new skills. Let the organization learn and develop around early trials. Partnering with outside experts is a valuable way to prime these internal capabilities.

1 HyperText Transport Protocol

2 Although initially defined in relation to tele-communications networks, Metcalfe’s Law today applies to all networks and states that the value of a network is proportional to the square of the number of nodes in the network. See more details at http://en.wikipedia.org/wiki/Metcalfe's_law.

3 In computing, a Uniform Resource Identifier (URI) is a string of characters used to identify a name or a resource. See Wikipedia: http://en.wikipedia.org/wiki/URI