From ESBs to API Portals, an Evolutionary Journey Part 2

In this article series we would like to build a case that API portals, with the Intel® API Manager and Intel® Expressway Service Gateway, powered by Mashery are representative examples, are the contemporary manifestations of the SOA movement that transformed IT in the early 2000s from IT as a cost center to an equal partner in a company’s  execution of a business strategy and revenue generation.  In the introductory article in Part 1 we discussed some of the business dynamics that led to cloud computing and the service  paradigm.  Let’s now take a closer look  at the SOA transformation in the big enterprise.

If we look at the Google  Webtrends graph for the term “SOA”, we can use the search popularity as an  indicator of the industry we can see that the interest in SOA peaked at around  2007, just as the interest on cloud computing started rising.  There was a brief burst of interest on this term at the end of 2012 which can be attributed at people looking for precedents in SOA as the industry moves to cloud services.

Figure 1. Google Webtrends graph for “SOA.”

Figure 2. Google Webtrends graph for “Cloud Computing.

The search rate for the term “cloud computing” actually peaked in 2011, but perhaps unlike SOA, the trend is not an indication of waning interest, but that the focus of interest has shifted to more specific aspects. See for instance the graphs for “Amazon AWS” and “OpenStack”.

Figure 3. Google Webtrends graph for “Amazon AWS.”

Figure 4. Google Webtrends graph for “OpenStack.”

SOA brought a discipline of  modularity that has been well known in the software engineering community for more than 30 years, but had been little applied in corporate-wide IT  projects.  The desired goal for SOA was  to attain a structural cost reduction in the delivery of IT services through  re-use and standardization.  These savings needed to be weighed against significant upfront costs for architecture and planning as well as from the reengineering effort for interoperability and security.  The expectation was a per  instance lower cost from reuse in spite of the required initial investment.

Traditionally, corporate applications have been deployed in stovepipes, as illustrated in Figure 5 below, one application per server or server tier hosting a complete solution stack.  Ironically, this trend was facilitated by the availability of low-cost Intel-based high volume servers starting fifteen years ago.  Under this system physical servers need to be procured, a process that takes anywhere from two weeks to six months depending on organizational policies and asset approvals in effect.  When the servers become available, they need to be configured and provisioned with an operating system, database software, middleware and the application. Multiple pipes are actually needed to support a running business.  For instance, Intel IT requires as many as 15 staging stovepipes to phase in an upgrade for the Enterprise Resource Planning (ERP) SAP application.  The large number of machines needed to support most any corporate application over its life cycle led to the condition affectionately called “server sprawl.”  In data centers housing thousands if not tens of thousands of servers it is not difficult to lose track of these assets, especially after project and staff turnover from repeated reorganizations and M&As.  This created another affectionate term: “zombies.”  These are forgotten servers from projects past, still powered up, and even running an application, but serving no business purpose.

Figure 5. Traditional Application Stovepipes vs. SOA.

With SOA, monolithic applications are broken into reusable, fungible services as shown on the left side of Figure 6 below.  Much in the same way server sprawl used to exist in data centers, so it was with software, with multiple copies deployed, burdening IT organizations with possibly unnecessary licensing costs, or even worse, with shelfware, that is, licenses paid for software never used.  As an example, in a stovepiped environment each application that requires the employee roster of a company, namely user accounts, phone directory, expense reporting, payroll would each require a full copy of the employee information database.  In addition to the expense of the extra copies, the logistics of keeping each copy synchronized would be complex.

What if instead the need to replicate the employee roster somehow it was possible to build a single copy where every application needing this information can “plug in” into this copy and use it a needed.  There are some complications: the appropriate access and security mechanisms need to be in place.  Locking mechanisms for updates need to be implemented to ensure integrity and consistency of the data.  However the expense of habilitating the database for concurrent access is still significantly less than the expense of maintaining several copies.

If we access this new single-copy employee database through Web Services technology, using either SOAP or REST, we have just created a “service”, the “employee roster service”.  If every application layer in a stack is
re-engineered as a service with possibly multiple users, the stacks in Figure 5 morph into a network as shown in the left part of Figure 6. The notion of service is recursive where most applications become composites of several services and services themselves are composites of services.  Any service can be n “application” if it exposes a user interface (UI) or a service proper if it exposes an API.  In fact a service can be both, exposing multiple UIs and APIs depending on the intended audience or target application: it is possible to have one API for corporate access and yet another one available to third party developers of mobile applications.

Applications structured to operate under this new service paradigm are said to follow a service oriented architecture, commonly known as SOA.  The transition to SOA created new sets of dynamics whose effects are still triggering change today.  For one thing, services are loosely coupled, meaning that as long as the terms of the service contract between the service consumer and the service provider does not change, one service instance can be easily replaced. This feature simplifies the logistics of deploying applications enormously: a service can be easily replaced to improve quality, or ganged together with a similar service to increase performance or throughput.  Essentially applications can be assembled from services as part of operational procedures.  This concept is called “late binding” of application components.

Historically binding requirements have been loosened up over time.  In earlier times most applications components had to be bound together at compile time.  This was really early binding.  Over time it became possible to combine precompiled modules using a linker tool and precompiled libraries.  With dynamically linked libraries it became possible to bind together binary objects at run time.  However this operation had to be done within a given operating system, and allowed only within strict version or release limits.

We can expect even more dynamic applications in the near future.  For instance, it is not hard to imagine self-configuring applications assembled on the fly and real time on demand using a predefined template.  In theory these applications could recreate themselves in any geographic region using locally sourced service components.

There are also business considerations driving the transformation dynamics of application components. Business organizations are subject to both headcount and budgetary constraints for capital expenses.  Under these restrictions it may be easier for an organization to convert labor and capital costs into monthly operational expenses by running their services on third party machines hiring Infrastructure as a Service (IaaS) cloud services, or take one step further and contract out the complete database package to implement the employee roster directly from a Software as a Service (SaaS) provider.  All kinds of variations are possible: the software service may be hosted on infrastructure from yet another party, contracted by either the SaaS provider or the end user organization.

The effect of the execution of this strategy is the externalization of some of the services as shown in the right hand side of Figure 6.  We call this type of evolution inside-out SOA where initially in-sourced service components get increasingly outsourced.

Figure 6. The transition from internal SOA to inside-out SOA.

As with any new approach, SOA transformation required an upfront investment, including the cost of reengineering the applications and breaking them up into service components, and in ensuring that new applications themselves or new capabilities were service ready or service capable.  The latter usually meant attaching an API to an application to make the application usable as a component for a higher-level application.

Implementation teams found the extra work under the SOA discipline disruptive and distracting.  Project participants resented the fact that while this extra work is for the “greater good” of the organization, it was not directly aligned with the goals of the project.  This is part of the cultural and behavioral aspects that a SOA program needs to deal with, which can be more difficult to orchestrate than the SOA technology itself. Most enterprises that took a long term approach and persisted in these efforts eventually reached a breakeven point where the extra implementation cost of a given project was balanced by the savings by reusing past projects.

This early experience also had another beneficial side effect that would pave the way to the adoption of cloud computing a few years later: the development of a data-driven, management by numbers ethic demanding quantifiable QoS and a priori service contracts also known as SLAs or service level agreements.

While the inside-out transformation just described had a significant impact in the architecture of enterprise IT, the demand for third party service components had an even greater economic impact on the IT industry as a whole, leading to the creation of new supply chains and with these supply chains, new business models.

Large companies, such as Netflix, Best Buy, Expedia, Dun & Bradstreet and The New York Times found that the inside-out transformative process was actually a two-way street.  These early adopters found that making applications
“composable” went beyond saving money; it actually helped them make money through the enablement of new revenue streams: the data and intellectual property that benefited internal corporate departments was also useful to external parties if not more.  For instance an entrepreneur providing a travel service to a corporate customer did not have to start from ground zero and making the large investment to establish a travel reservation system.  It was a lot simpler to link up to an established service such as Expedia.  In fact, for this upstart did not have to be bound by a single service: at this level it makes more economic sense to leverage a portfolio of services, in which case the value added of this service upstart is in finding the best choices from the portfolio.  This is a common pattern in product search services whose function is to find the lowest price across multiple stores, or in the case of a travel service, the lowest priced airfare.

The facilitation of the flow of information was another change agent for the industry.  There was no place to hide.  A very visible example is effect of these dynamics on the airline industry, and how it changed irrevocably, bringing up new efficiencies but also significant disruption.  The change empowered consumers, and some occupations such as travel agents and car salespeople were severely impacted.

Another trend that underlies the IT industry transformation around services is the “democratization” of the services themselves: The cost efficiencies gained not only lowered the cost of business for some expensive applications accessible only to large corporations with deep pockets; it made these applications affordable to smaller businesses, the market segment known as SMBs or Small and Medium Businesses.  The economic impact of this trend has been enormous, although hard to measure as it is still in process.  A third wave has already started, which is the industry’s ability to reduce the quantum for the delivery of IT services to make it affordable to individual consumers. This includes social media, as well as more traditional services such as email and storage services such as Dropbox. We will take a look at SMBs in Part 3.

From ESBs to API Portals, an Evolutionary Journey, Part 1

A number of analysts are beginning to suggest 2013 will likely signal the awakening of a long night in the IT industry that started with the beginning of the third millennium with the Internet crash. And just as recovery was around the corner, the financial crisis of 2008 dried the IT well once more. Both crises can be characterized as crises of demand. Just past 2000, the Y2K pipeline ran dry. Some argue that the problem was overstated, whereas others argue that the problem was solved just in time. In either case this event triggered a significant pullback in IT spending.

Faced with an existential threat after Y2K, the IT industry did not sit still. The main outcome from these lean years has been a significant increase in efficiency where the role of IT in companies with most advanced practices shifted from being a cost center to an active participant in the execution of corporate business strategy. Capabilities evolved from no accountability on resource utilization to efficient use of capital to nimble participant in a broad range of organizations and initiatives.  The second crisis reaffirmed the continuing need to do more in the face of shrinking budgets and very likely provided the impetus for the widespread adoption of cloud technology.

The state of the art today is epitomized by cloud computing under the service paradigm. From a historical perspective the current state of development for services is in its third iteration.

The early attempts came in various forms from different angles and as many vendors. The most prominent examples of this era came from application server and connectivity ISVs (independent software vendors) and from operating system vendors: Microsoft, IBM, TIBCO and various Unix vendors of that era. The main characteristic of this era that went roughly from 1995 to 2005 was single-vendor frameworks with vendors attempting to build ecosystems around their particular framework. This approach did not take off, partly because concerns in IT organizations about vendor lock-in and because the licensing costs for these solutions were quite high.

The second era was the era of SOA that lasted roughly from 2000 to 2010. The focus was to re-architect legacy IT applications from silo implementations to collections of service components working together. Most of the service components were internally sourced, resulting perhaps from the breaking former monoliths, and combined with a few non-core third party services. Vendors evolved their offerings so they would work well in this new environment. The technology transformation costs were still significant as well as the demand on practitioners’ skills.  Transformation projects required a serious corporate commitment in terms of deferrals to accommodate process reenginering, licensing fees and consulting costs. As a result, the benefits of SOA were available only to large companies. Small and medium businesses (SMBs) and individual consumers were left out of the equation.

Cloud technology drives the current incarnation for IT services following the crisis of 2008. Clouds notwithstanding, if we look at the physical infrastructure for data centers, it is not radically different from what it was five years ago, and there are plenty of data centers five years ago or older still in operation. However, the way these assets are organized and deployed is changing. Much in the same way credit or other people’s money drives advanced economies, with the cloud other people’s systems are driving the new IT economy.

Scaling a business often involves OPM (other people’s money), through partnerships or issuing of stock through IPOs (initial public offerings). These relationships are carried out within a legal framework that took hundreds of years to develop.

In the real world, scaling a computing system follows a similar approach, in the form of resource outsourcing, such as using other people’s systems or OPS. The use of OPS has a strong economic incentive: it does not make sense to spend millions of dollars in a large system for occasional use only.

Large scale projects, for instance a marketing campaign that requires significant amounts of computing power are peaky in the usage of infrastructure assets, usually start with small trial or development runs, with large runs far and few between. A large system that lies idle during development would be a waste of capital.

Infrastructure sharing across a pool of users increases the duty cycle of infrastructure assets through the sharing of these assets with multiple users.  Cloud service providers define the sandbox whereby a number of corporate or individual users have access to this infrastructure. Cloud computing increases the efficiency of capital use through resource pooling delivered through a service model.

The first step in the infrastructure transformation came in the form of server consolidation and virtualization technology. After consolidation became a mainstream IT practice, the trend has been toward the support of more dynamic behaviors. IaaS allows the sharing of physical assets not just within the corporate walls, but across multiple corporate customers. A cloud service provider takes a data center, namely $200 million asset and rents individual servers or virtual machines running inside them by the hour, much in the same way a jet leasing companies takes a $200 million asset, namely an airliner and leases it to an air carrier which otherwise would not be able to come up with the upfront capital expense. The air carrier turns around and sells seats to individual passengers, which is essentially renting a seat for the duration of one flight.

In other words, the evolution we are observing in the delivery of IT services is no different than the evolution that took place in other, more mature industries. The processes that we are observing with cloud computing and associated service delivery model is no different than the evolution of the transportation industry, to give one example.

As we will see in the next few articles, the changes brought by the cloud are actually less about technology and more about the democratization of the technology: the quantum for delivery used to be so large that only the largest companies could afford IT. Over the past few years IT became accessible to small and medium businesses and even individual consumers and developers: businesses can purchase email accounts by the mailbox with a monthly fee, and deployment models allow individual consumers to sign up for email accounts at no out of pocket cost. We will look at the evolution of the service model from a corporate privilege to mass availability. From a practical, execution perspective, products like the Intel® Expressway Service Gateway and Intel® API Manager were developed to support the life cycle of cloud enabled applications, and I’ll be pointing to aspects of these products to provide specific examples of the concepts discussed.

In the next article we’ll discuss the “big guns” services represented by the SOA movement in the first decade of the millennium.

Touchless Security for Hadoop – combining API Security and Hadoop

It sounds like a parlor trick, but one of the benefits of API centric de-facto standards  such as REST and JSON is they allow relatively seamless communication between software systems.

This makes it possible to combine technologies to instantly bring out new capabilities. In particular I want to talk about how an API Gateway can improve the security posture of a Hadoop installation without having to actually modify Hadoop itself. Sounds too good to be true? Read on.

Hadoop and RESTful APIs

Hadoop is mostly a behind the firewall affair, and APIs are generally used for exposing data or capabilities for other systems, users or mobile devices. In the case of Hadoop there are three main RESTful APIs to talk about. This list isn’t exhaustive but it covers the main APIs.

  1. WebHDFS – Offers complete control over files and directories in HDFS
  2. HBase REST API – Offers access to insert, create, delete, single/multiple cell values
  3. HCatalog REST API – Provides job control for Map/Reduce, Pig and Hive as well as to access and manipulate HCatalog DDL data

These APIs are very useful because anyone with an HTTP client can potentially manipulate data in Hadoop. This, of course, is like using a knife all-blade – it’s very easy to cut yourself. To take an example, WebHDFS allows RESTful calls for directory listings, creating new directories and files, as well as file deletion. Worse,  the default security model requires nothing more than inserting “root” into the HTTP call.

To its credit, most distributions of Hadoop also offer Kerberos SPNEGO authentication, but additional work is needed to support other types of authentication and authorization schemes, and not all REST calls that expose sensitive data (such as a list of files) are secured. Here are some of the other challenges:

  • Fragmented Enforcement – Some REST calls leak information and require no credentials
  • Developer Centric Interfaces – Full Java stack traces are passed back to callers, leaking system details
  • Resource Protection – The Namenode is a single point of failure and excessive WebHDFS activity may threaten the cluster
  • Consistent Security Policy – All APIs in Hadoop must be independently configured, managed and audited over time

This list is just a start, and to be fair, Hadoop is still evolving. We expect things to get better over time, but for Enterprises to unlock value from their “Big Data” projects now, they can’t afford to wait until security is perfect.

One model used in other domains is an API Gateway or proxy that sits between the Hadoop cluster and the client. Using this model, the cluster only trusts calls from the gateway and all potential API callers are forced to use the gateway. Further, the gateway capabilities are rich enough and expressive enough to perform the full depth and breadth of security for REST calls from authentication to message level security, tokenization, throttling, denial of service protection, attack protection and data translation. Even better, this provides a safe and effective way to expose Hadoop to mobile devices without worrying about performance, scalability and security.  Here is the conceptual picture:

Intel(R) Expressway API Manager and Intel Distribution of Apache Hadoop

In the previous diagram we are showing the Intel(R) Expressway API Manager acting as a proxy for WebHDFS, HBase and HCatalog APIs exposed from Intel’s Hadoop distribution. API Manager exposes RESTful APIs and also provides an out of the box subscription to Mashery to help evangelize APIs among a community of developers.

All of the policy enforcement is done at the HTTP layer by the gateway and the security administrator is free to rewrite the API to be more user friendly to the caller and the gateway will take care of mapping and rewriting the REST call to the format supported by Hadoop. In short, this model lets you provide instant Enterprise security for a good chunk of Hadoop capabilities without having to add a plug-in, additional code or a special distribution of Hadoop. So… just what can you do without touching Hadoop? To take WebHDFS as an example the following is possible with some configuration on the gateway itself:

  1. A gateway can lock-down the standard WebHDFS REST API and allow access only for specific users based on an Enterprise identity that may be stored in LDAP, Active Directory, Oracle, Siteminder, IBM or Relational Databases.
  2. A gateway provides additional authentication methods such as X.509 certificates with CRL and OCSP checking, OAuth token handling, API keys support, WS-Security and SSL termination & acceleration for WebHDFS API calls. The gateway can expose secure versions of the WebDHFS API for external access
  3. A gateway can improve on the security model used by WebHDFS which carries identities in HTTP query parameters, which are more susceptible to credential leakage compared to a security model based on HTTP headers. The gateway can expose a variant of the WebHDFS API that expects credentials in the HTTP header and seamlessly maps this to the WebHDFS internal format
  4. The gateway workflow engine can maps a single function REST call into multiple WebHDFS calls. For example, the WebHDFS REST API requires two separate HTTP calls for file creation and file upload. The gateway can expose a single API for this that handles the sequential execution and error handling, exposing a single function to the user
  5. The gateway can strip and redact Java exception traces carried in the WebHDFS REST API responses ( for instance, JSON responses may carry org.apache.hadoop.security.AccessControlException.* which can spill details beneficial to an attacker
  6. The gateway can throttle and rate shape WebHDFS REST requests which can protect the Hadoop cluster from resource consumption from excessive HDFS writes, open file handles and excessive  create, read, update and delete operations which might impact a running job.

This list is just the start, API manager can also perform selective encryption and data protection (such as PCI tokenization or PII format preserving encryption) on data as it is inserted or deleted from the Hadoop cluster, all by sitting in-between the caller and the cluster. So the parlor trick here is really moving the problem from trying to secure hadoop from the inside out to moving and centralizing security to the enforcement point. If you are looking for a way to expose “Big Data” outside the cluster, an the API Gateway model may be worth some investigation!

Blake

Webinar: Mobile Optimized Healthcare API Programs

Registration is now open for our next webinar on Tuesday, March 5 at 10AM Pacific, 1PM Eastern – “Mobile Optimized Healthcare API Programs:  New Revenue from Legacy Data”

Mobile apps, partner & developer API programs, and healthcare data are converging to create new revenue opportunities for Healthcare providers via API developer community portals.  We’ve assembled a panel of experts from the industry to present case studies from Aetna and the Blue Cross and Blue Shield Association that illustrate best practices for building a successful API program.

While the case studies come from Healthcare, companies any industry can apply many of the ideas from this webinar to jumpstart their own API community initiatives.  The discussion will cover topics including:

  • Gateway security patterns to safely repackage legacy data and services as APIs
  • How to construct, share, and promote APIs to developers using API workshops and branded portals
  • How to build a mobile-optimized back end that securely exposes enterprise assets via standard internet protocols (e.g. OAuth & JSON)

Our speakers will include security expert Gunnar Peterson, Mashery’s Chuck Freedman, Intel’s Blake Dournaee, and a special guest speaker from Aetna.  In addition, all attendees will receive a Mobile API Architecture White Paper.  We hope you’ll join us!

Mobile Middleware for the Enterprise (part 1)

Introduction

With the trends of consumerization and bring-your-own-device (BYOD) acceptance, enterprises are increasingly seeking to securely integrate tablets and smartphones into their environments.  Meanwhile, external customers and partners desire mobile apps that provide on-demand, self-service alternatives to traditional consumer web portals.  Mobile middleware can ease this integration, providing a consistent framework and set of interfaces for a wide range of applications and data sources.  This is the first in a series of posts intended to help the enterprise IT buyer to better understand the benefits of mobile middleware, as well as to make an informed decision when choosing among the many products in this space.

Use case 1:  Employee productivity

Mobile devices bring the potential for ubiquitous access to corporate resources, providing employees with an “always-on” connection to the enterprise.  Email, calendar, and contacts are no longer sufficient for many enterprises – Line-of-Business applications with secure access to corporate data will further improve worker productivity.

While the first stage of mobile access was delivered using off-the-shelf software packages, the next wave will include much more custom code.  According to a November 2011 Forrester study, over 50% of enterprises rely on custom applications developed either in house or by externally-contracted developers.  These applications will require access to a mix of back-end services, from existing SOAP applications to newly-developed RESTful APIs, as well as cloud-hosted services such as salesforce.com.

app-sourcing

An established enterprise may already have an ESB for internal services, or they may be using loosely-coupled, point-to-point connections between apps and services.  Either way,the ESB likely was not designed with wide-scale or external connectivity in mind.  Mobile middleware can help to bridge this gap, providing a RESTful interface to legacy services and data sources.  It can also provide enterprise mobile application developers with a catalog of available APIs and documentation on how to consume them, speeding development and increasing consistency across applications.

Use case 2:  External access

Many enterprises have offered their customers a self-service web engagement portal for some time.  Whether it is used for commerce, basic account management, or other purposes, this portal ultimately connects back into enterprise services.  With mobile browsers taking an increasing share of page views, portals that deliver substandard user experience are being reimplemented as native enterprise mobile applications.

Mobile vs. desktop browser share, 2011-2012
Source: StatCounter

While the scope of services to be accessed by external users is typically much narrower than in the employee productivity use case, the scale and security considerations are much greater.  Also, digital natives expect integration with external identity providers, social networking, and other external cloud services.  As with internal-facing applications, mobile middleware can act as a glue layer for these customer apps, providing integration with external services while securing access to internal data.

The Case for Mobile Middleware

Regardless of which use case is the primary motivator for adopting a mobilization strategy, it’s clear that legacy web and data services are not readily consumable by mobile devices.  An enterprise, then, has two options:  remediate each service independently, or adopt a mobile middleware layer that can bridge the gaps to mobile access.  Development cost savings from the mobile middleware approach will depend on the number of services to be addressed and level of integration effort required.  However, by abstracting away these integration functions, enterprises can be assured that security policies are being uniformly implemented, enforced, and updated — no easy task if custom code is added to a large number of applications.

A mobile middleware strategy can address the issues shared by both of these use cases:  providing security and broad integration capabilities while delivering the performance necessary for a responsive user experience.

Other Resources

Over the next few weeks I will explore how mobile middleware can help an enterprise to integrate its own REST and SOAP services with 3rd-party APIs.  I’ll also describe some of the security and performance considerations that go along with different approaches.  Finally I will look at the options for application development that can benefit from the a consistent, RESTful back end.

In the meantime, here are some links to other material that should be useful when building a strategy for enterprise mobile applications:

API strategy & practice conference in NYC – Are you going?

Alright, I am sure you have heard this again and again but it’s worth saying it one more time. The first ever API strategy & practice conference is going be in NYC on Feb 21, 22 (http://www.apistrategyconference.com/). If you are just finding this out, it might be way too late for you to get in (But I will tweet anything interesting happening from inside 🙂 ).  There are 72 companies that are confirmed to participate and sending their API whiz kids, gurus, learners, teachers, procrastinators there to make a difference. Intel is proud to be a Gold sponsor to this event.

Yes, Intel. Not only does Intel do software, but they do it really well too. We have an outstanding API Manager that we released recently which will be showcased there. If you happen to attend this, please stop by my 2 speaking sessions/ panels.

Day 1: 2:20-3:30 – Track 3: API Security and Scalability

As APIs gain adoption they become ever more critical gateways to a company’s core business – ensuring access is secure and scalable are mission critical for your business. Presentations include:

  1. Paul Madsen (@PingIdentity) of  Ping Identity
  2. Mark O’Neil (@TheMarkONeill) of Vordel
  3. Travis Reeder (@treeder) of Iron.io
  4. Andy Thurai (@AndyThurai) of Intel
  5. Discussion panel on the challenges and solutions for API Security and Scalability

Day 2: 11.00-12.10 – Track 1: Mobile

APIs and Mobile are symbiotic – each driving the other with a good API strategy arguably key to a good Mobile Strategy. Presentations include:

  1. Andy Thurai (@AndyThurai) of Intel
  2. Max Katz (@maxkatz) of Tiggzi
  3. Marc Weil (@marcweil) of Cloudmine
  4. Miko Matasumura (@mikojava) of Kii
  5. Discussion Panel on the evolution of API / App Ecosystems and platforms

3Scale and Kin Lane did an amazing job of putting this together again (first time was cancelled thanks to hurricane Sandy). Hope to see you all there. Don’t forget to stop by our booth. You will get a chance to see me :), and win some goodies if you stop by and make your presence known, but more importantly you will get to learn about Intel API Manager.

Looking forward to seeing you all there.

-Andy Thurai (Twitter: @AndyThurai)

Are you building your APIs the right way?

I keep telling my customers, it is not about what you think is important but it is about what your customers (internal, external or partners) see as important when it comes to building APIs and mobile apps, or APIs for mobile apps. This article from Intel explains the facets of WHO, WHAT and HOW very nicely. We instituted a new practice called Intel API Manager which does all of the above and more. It includes a strategy session to identify the audience (WHO) that can benefit from this, WHAT are the channels that can drive additional revenue, and HOW we can help you achieve that.

http://software.intel.com/en-us/blogs/2013/01/28/taking-your-app-to-market-the-who-what-and-how-of-your-mobile-app-marketing

And, yes Intel does software!  – and very well too!

-Andy Thurai (Twitter: @AndyThurai)