August 2nd, 2013

Getting Mobile Mojo Through App Innovation: The Enterprise View

Mobile MojoAPIs first found their footing among consumer Web sites wanting to transform into platforms. APIs let Web sites foster developer communities that could build apps anchored to their services. Innovative apps would attract new users to the Web site, help keep existing users engaged and –with a little bit of luck – make some money.

APIs Engage Developers, Developers Build Apps, Apps Enable Innovation
This virtuous cycle of APIs and innovation does not have to be limited to consumer Web sites. Enterprises have countless data and application resources distributed across their datacenters. All of these could be opened to internal developers via APIs. Done right, this could drive development innovation. Internal programmers with access to diverse internal information resources could build more compelling mobile and cloud apps, in less time.

Centralize API Discovery Through a Directory
Enablement is the starting point for getting developers building better apps, faster. Apps need data and APIs provide the windows into data, both inside the enterprise and out in cloud. Finding the APIs that front the data sources which enrich mobile apps is no easy task. Back in the days of SOA, service directories emerged as the vehicle for helping developers find software service elements that could be reused and composed into diverse business processes.

An API portal can assume a similar role in providing a centralized point of API discovery and reuse in mobile. An API portal provides the core directory, developer management and developer collaboration features that aid mobile innovation. It presents information on what data resources are available and how these resources can be accessed, along with documentation, code samples and so on, all in a simple Web-based format.

Inside vs. Outside Developers
For some time, vendors have been making API portals available from the cloud, with an eye to aiding the external long-tail developer. But that same technology brought inside the datacenter can also be used by internal developers. While external developers can provide a forum for experimentation and education, the real ROI for most enterprises will occur inside the DMZ. Making internal developers building mobile apps productive and agile will help organizations deliver effective consumer and employee-facing apps faster.
But to do this, the API portal will need to be brought inside the firewall where the enterprise will be able manage internal developers securely. This will increase productivity, which will result in more and richer apps, in less time.

Powering the Internal Developer
Having seen the potential service directories had for organizing internal development efforts, Layer 7 has effectively bridged the lessons of SOA to mobile. The Layer 7 API Portal is unique in that it can support classic SOAP services along with newer REST interfaces and can be deployed 100% inside the datacenter. This enables enterprises to use API portals strategically – not just for powering external developer communities. By placing itself at the center of an internal app-building ecosystem, the Layer 7 API Portal can spur innovation across mobile development teams.

July 17th, 2013

Secure APIs: The Road to Business Growth

CA Technologies Mobile SolutionsBusinesses today are under intense pressure to reach new customers, collaborate with new partners and build new mobile apps that transform business processes.

If you’re a bank, you might want to sign customers up using a tablet on the street corner. If you’re servicing cell phone towers, you might want a technician’s tablet or cell phone to know his location, open the right support ticket and send him the proper documentation for that work site. If you’re selling to end customers, you want to give them exactly the information they need, when they need it, on whatever device they choose, when they’re ready to buy.

But when the business comes to IT for such applications, we often tell them “no” – or, at least, “not now.” One reason is that IT is short on developers. But IT’s hesitance also stems from an appropriate concern with issues like access control or the possibility that backend systems might crash under the load from mobile applications or the cost of converting data for these new services and devices. As we learned from connecting our backend systems to the Web, adding a new platform can mean a profound change in how these systems are used – instead of checking a flight once when the travel agent makes a reservation, people now check on-flight information dozens of times as they search for the best flight on the Web or check their mobile phones to see whether Grandma’s flight has arrived yet.

IT can help meet these needs if we realize the business is not asking for a series of huge new standalone apps. What it’s asking for is the ability to experiment, to try a lot of new ideas quickly and at low enough risk and cost that even if some ideas fail, that’s still okay – as long as one or two succeed in a big way. As Linus Pauling put it, “If you want to have good ideas you must have many ideas. Most of them will be wrong and what you have to learn is which ones to throw away.”

Such experimentation is often impossible in-house and not just because of a lack of the skills. The hand-coding process used in most organizations today forces them to build the same app multiple times, once for the browser, once for mobile, once for Google Glass or whatever the next platform is. That not only delays deployment, it also increases cost and risk so much that experimentation in the business is not possible.

But secure APIs can make that experimentation possible. Here’s how.

Secure APIs provide a single gateway for developers from smaller companies that are in your organization’s “ecosystem” to access and monetize the backend systems, databases and information that are your core assets. If you can support outside developers in creating great apps for you, you avoid grinding out that code yourself. That makes you much more agile and reduces your cost and delivery times. It also lets you tap outside developers if you need help in a new or emerging area, such as a Google Glasses app or Big Data or for a short-lived app like one that works with a Super Bowl promotion.

In addition, outside developers might see ways to monetize your internal systems that you cannot. They might come up with, say, a social banking app that builds brand loyalty by using a customer’s social group to encourage her to contribute to a retirement account. They might develop a branded pedometer app for a health plan to track a member’s exercise routine. This is no different than when Twitter or any other social media platform lets third-party developers connect to their information systems, delivering revenue in ways the business might never have imagined.

Organizations taking advantage of this market opportunity are building on a platform that allows them to abstract security and data transformation tasks into a technology layer purpose built to enable this innovation. Think of this as a mobility Gateway that streamlines development and reduces risk by eliminating the need to write everything from security to access control, caching and load management for every application. If those functions are delivered from the Gateway, developers can focus on quick revisions of the front-end application to go after those potential big market wins.

At CA Technologies, we are now providing such a secure Gateway, following our acquisition of Layer 7. The Layer 7 technology provides a secure Gateway that sits in front of your backend systems, exposing them via simple and secure APIs. It provides everything from identity verification to caching through a single security and IT optimization layer, giving developers – and the business – the freedom to experiment and innovate.

The way to build out your APIs is to start slowly using budget from individual projects but keeping the long-term architecture in mind. Don’t try selling it to the business in terms of APIs, caching and security layers. Instead, tell it how you’re giving it the ability to rapidly and securely experiment with new business models at low cost. Talk about how you’re letting it roll out a new mobile application more quickly or giving an outside developer the tools to find a new route to market for you.

We’re seeing that customers who build APIs, not applications, are leveraging the creativity of a world of clever developers. What challenges and rewards have you found on your API journey?

July 11th, 2013

Federation Evolved: How Cloud, Mobile & APIs Change the Way We Broker Identity

Identity Federation WebinarThe adoption of cloud by organizations looking for more efficient ways to deploy their own IT assets or as a means to offset the burden of data management drives the need for identity federation in the enterprise. Compounding this is the mobile effect from which there is no turning back. Data must be available any time, from anywhere and the identities accessing it must be asserted on mobile devices, in cloud zones, always under the stewardship of the enterprise.

APIs serve federation by enabling lightweight delegated authentication schemes based on OAuth handshakes using the same patterns as used by social login. The standard specifying such patterns is OpenID Connect where a relying party subjects a user to an OAuth handshake and then calls an API on the identity provider to discover information about the user thus avoiding having to setup a shared secret with that user – no identity silo. This new type of federation using APIs is easier to implement for the relying party as it avoids parsing and interpreting complex SAML messages with XML digital signatures, both of which tend to suffer from interoperability challenges.

Now, let’s turn this around. Sometimes what needs to be federated is the API itself, not just the identities that consume it. For example, consider the common case of a cloud API consumed by a social media team on behalf of an organization. When the social media service is consumed from mobile apps, the cloud API is consumed directly and the enterprise has no ability to control or monitor information being posted on its behalf.

Cloud api consumption by mobile - not federated

In addition to this lack of control, this simplistic cloud API consumption on behalf of an organization by a group of users requires that users share the organization account itself, including the password associated with it. The security implications of shared passwords are often overlooked. Shared service accounts multiply the risk of a password being compromised. There are numerous recent examples of enterprise social media being hacked with disastrous PR consequences. Famous examples from earlier this year include Twitter hacks of the Associated Press leading to a false report of explosions at the White House and Burger King promoting competitor McDonalds.

Federating such cloud API calls involves the applications sending the API calls through an API broker under the control of the organization. Each of these API calls is made through an enterprise identity context, that is each user signs in with its own enterprise identity. The API broker then “converts” these API calls into API calls to the cloud provider using the identity context of the organization.

Cloud api, federated

In this case, federating the cloud API calls means that the enterprise controls the organization’s account. Its password is not shared or known by anybody outside of an administrator responsible for maintaining a session used by an API broker. Users responsible for acting on that cloud service on behalf of the organization can do so while mobile but are authenticated using their enterprise credentials. The ability of a specific user to act on behalf of an organization is controlled in real time. This can, for example, be based on attributes read from a user directory or a predefined white list in the broker itself.

By configuring policies in this broker, the organization has the ability to filter the information sent to and received from the cloud provider. The use of the cloud provider is also monitored and the enterprise can generate its own metrics and analytics relating to this cloud provider.

On July 23, I will be co-presenting a Layer 7 webinar with CA’s Ehud Amiri titled Federation Evolved: How Cloud, Mobile & APIs Change the Way We Broker Identity. In this webinar, we will examine the differences between identity federation across Web, cloud and mobile, look at API-specific use cases and explore the impact of emerging federation standards.

April 22nd, 2013

How to Make Your Developers Mobile Innovators (Psst… It’s in the API Presentation Layer!)

Mobile InnovatorsAPIs have multiple purposes inside an enterprise. Most of the early excitement around API stemmed from the potential for APIs to foster communities of “long-tail” developers. With data becoming the new mobile currency, opening up data to legions of developers held out the promise of multiplying revenue and reach for start-ups and enterprises alike.

While several start-ups have demonstrated the potential of tapping the long-tail developer community (look at examples like Twillio, Tapjoy, Stripe and Braintree) the number of enterprises that have seen similar success is less clear (Amazon Web Services is an obvious counterpoint).

One reason for this is simple – enterprises have conflicting interests and are almost never set up to successfully service these communities at all costs. This doesn’t negate the value of fostering relations with the long tail. External developer programs make sense for enterprises and should be viewed as strategic, even if the immediate payback is not obvious. With the advent of the app economy, developers represent as important a channel to market as traditional distributors.

However, often overlooked in the race to launch an external API developer program is the potential benefit of an internal API developer program. Enterprises have, in many cases, thousands if not tens of thousands of developers internally. Often, internal developers are supplemented by contractors. Enabling all these developers to become mobile innovators through APIs holds out the promise of delivering the kinds of leaps in productivity, agility and experimentation that will benefit any enterprise.

To make internal developers innovation leaders, it is essential to provide a canonical way for these developers to access all corporate application and data resources. An API abstraction layer delivered through an ESB or API Gateway simplifies the process of API-ifying information resources and consuming APIs.

But that’s not enough because developers will still need a central directory or registry of APIs to discover which APIs are available and what these APIs do. In the WS*-centered Web services world of SOAP-oriented APIs, which most enterprises still inhabit, this function would be handled by a UDDI directory and some accompanying “repository” software. But in the API world, no exact analog has existed – in part because every API Management vendor has insisted on provisioning its API portal in the public cloud only, a place most enterprises are reluctant to post APIs aimed at internal developers. Layer 7 aims to bridge the gap.

The Layer7 API Portal is the first turnkey API developer portal that can be deployed 100% inside a customer’s private cloud, datacenter or IT facility. Moreover, it is the first developer portal to offer simultaneous support for both RESTful APIs and SOAPy APIs, meaning it can act as a substitute for existing UDDI-style services while providing a pathway to newer RESTful services. Best of all, it can be implemented with different grades of privacy so that the same API Portal can support internal, contract and external developers at the same time – with each group seeing only what the enterprise chooses.

By centralizing where APIs are presented for discovery and consumption by developers, enterprises can make it easier for their service innovators to build new capabilities and mash multiple existing services into newer composite business functions. They can introduce new apps and applications faster. They can respond to change faster. They can build and iterate on new mobile apps in less time, with less error. It all comes down to the API presentation layer.

April 18th, 2013

Intel Buys Mashery! Is it Because the Cloud Will Have an API Inside?

Intel-MasheryFor close to five years, Intel has had a stake in the API space. All the while, I’ve often asked myself why. Intel originally acquired an API Gateway from a prior Intel Capital investment that never fully blossomed. And despite the oddness of having a tiny enterprise software franchise lost inside a semiconductor behemoth, Intel persisted in its experiment, even in the face of questionable market success and lukewarm analyst reaction. So, why double down on APIs now?

With the steady decline of the PC business, Intel clearly has to look elsewhere for its future growth. The cloud datacenter is not a bad place to start. Cloud server farms clearly consume lots of processors. Still, servers powering Web sites can operate fine without APIs, thank-you. But servers powering mobile is a different story. Mobile apps (whether HTML5, hybrid or native) get the data that makes them valuable from applications that reside in datacenters. And APIs are the key to letting cloud data be sharable with mobile apps.

Clearly, app-centric “smart” phones and tablets and TVs and cars and watches and glasses are changing the way we go about our daily business. And APIs will power these smart devices by giving enterprise and Internet companies a way to push their data to apps. That hope of bridging the cloud with mobile is probably why Intel has kept its current API product intact. Mashery broadens Intel’s API scope by providing a way to not only share data with mobile apps but now also the developers that build these apps. But will this plan succeed?

If it does, it will take quite a bit of time. The reality today remains that Intel – even despite the semi-recent McAfee acquisition – is not oriented to selling software or even cloud services into the enterprise. It’s missing the sales force. It’s missing the history. And in many ways, it’s missing the rest of the software stack it needs to power the networking, infrastructure and application parts that underpin data in the cloud. That will make selling an API platform comprising a legacy API Gateway and newfound API developer platform a harder proposition. It’s kind of out there alone.

Another obvious roadblock to making the Mashery acquisition successful is that Intel’s existing API Gateway and the Mashery API service are designed for two very different audiences inside the enterprise, with un-reconcilable needs. The API Gateway is designed for an IT department that wants to run its API Management layer in its own datacenter. The Mashery offering is designed for a non-IT buyer (a mobile program manager, say) who wants to run everything in someone else’s cloud.

One is technical, the other is not. One is on-premise, the other is SaaS. One sells traditional software licenses, the other pure subscription. The first aims to address internal and external API integration challenges. The latter is only really concerned with the challenge of acquiring external API developers (though Mashery would probably protest this point).

Will the two be a marriage made in heaven? Given that the Intel/Mashery partnership is already a year old and that Mashery was barely able to grow its revenues in that time, the likelihood seems remote. But who knows for sure? And anyway, Intel has probably not bought Mashery for its $12M in revenue but for its long-term potential as a pathway to mobile.