How to effectively build a hybrid SaaS API management strategy

– By Andy Thurai (@AndyThurai) and Blake Dournaee (@Dournaee). This article was originally published on Gigaom

Summary: Enterprises seeking agility are turning to the cloud while those concerned about security are holding tight to their legacy, on-premise hardware. But what if there’s a middle ground?

If you’re trying to combine both a legacy and a cloud deployment strategy without having to do everything twice a hybrid strategy might offer the best of both worlds. We discussed that in our first post API Management – Anyway you want it!.

In that post, we discussed the different API deployment models as well as the need to understand the components of API management, your target audience and your overall corporate IT strategy. There was a tremendous readership and positive comments on the article. (Thanks for that!). But, there seem to be a little confusion about one particular deployment model we discussed – the Hybrid (SaaS) model. We heard from a number of people asking for more clarity on this model. So here it is.

Meet Hybrid SaaS

A good definition of Hybrid SaaS would be “Deploy the software, as a SaaS service and/or as on-premises solution, make those instances co-exist, securely communicate between each other, and be a seamless extension of each other.”

Read more of this post

ATOS API: A zero cash payment processing environment without boundaries

When ATOS, a big corporate conglomerate (EUR 8.8 billion and 77,100 employees in 52 countries), decided that they wanted to become the dominant Digital Service Provider (DSP) for payments, they had a clear mandate on what they wanted to do. They wanted to build a payment enterprise without boundaries. [Wordline is an ATOS subsidiary setup to handle the DSP program exclusively]. One of the magic bullets out of that mandate was:

The growing trust of consumers to make payments for books, games and magazines over mobiles and tablets evolving into a total acceptance of cashless payments in traditional stores and retail outlets bringing the Zero Cash Society ever closer.

This required them to rethink the way they processed payments. They are one of the largest payments processors in the world, but they were primarily focused on only big enterprises and name brand shops using their services. Onboarding every customer took a long time, and the integration costs were high. After watching the smaller companies such as Dwolla, Square and others trying to revolutionize the world they decided it is time for the giant to wake up.

The first decision was to embrace the smaller vendors. In order to do that, they can’t be a high touch, very time consuming, takes forever to integrate and very high cost per customer on-boarding environment. They wanted to build a platform that is low touch, completely API driven, fully self-serviced, and continuously integrating yet provides secure payment processing transactions. In addition, they were also faced with moving from the swipe retail payment systems to support ePayment and mobile payments. Essentially, they wanted to build a payment platform that catered not only to today’s needs but flexible enough to expand and scale for the future needs and demands. They wanted to offer this as a service to their customers.

Read more of this post

API Days Paris – impressionnant!

Recently I had the pleasure of speaking at the API Days in Paris. It was a great event, and the crowd was surprisingly larger than I expected.

The usual suspects were presenting there including Kin Lane, Adam DuVander, Mike Amundsen, Mehdi, myself, SOA software, WSO2, 3Scale, Mulesoft, FaberNovel along with some surprises. Interestingly I saw Microsoft, HP, and Rackspace for the first time, and IBM is starting to show up in more events now as well.

In my opinion, the best speech would probably go to Rafi Haladjian of Sen.Se (The End of The Internet of Things).  Rumor has it that the slides not working was part of his act 🙂 Regardless, he improvised and spoke without any visual cue. It was funny, full of substance and included a good amount of thought leadership. He started off his conversation with a humor bit suggesting he doesn’t speak English and knows nothing about Internet of Things. Wonder how it would have turned out with slides.

Interestingly enough APISpark (Restlet) had the big stage with gold sponsorship, a prime speaking spot, and demonstrated some good ideas. We will have to wait and see how it will turn out when the next conference rolls around.

Read more of this post

API Management – Anyway you want it!

– By Andy Thurai (Twitter:@AndyThurai) and Blake Dournaee (@Dournaee). This article originally appeared on Gigaom.

Enterprises are building an API First strategy to keep up with their customer needs, and provide resources and services that go beyond the confines of enterprise. With this shift to using APIs as an extension of their enterprise IT, the key challenge still remains choosing the right deployment model.

Even with bullet-proof technology from a leading provider, your results could be disastrous if you start off with a wrong deployment model. Consider developer scale, innovation, incurring costs, complexity of API platform management, etc. On the other hand, forcing internal developers to hop out to the cloud to get API metadata when your internal API program is just starting is an exercise leading to inefficiency and inconsistencies.

Components of APIs

But before we get to deployment models, you need to understand the components of API management, your target audience and your overall corporate IT strategy. These certainly will influence your decisions.

Not all Enterprises embark on an API program for the same reasons – enterprise mobility programs, rationalizing existing systems as APIs, or find new revenue models, to name a few.  All of these factors influence your decisions.

API management has two major components: the API traffic and the API metadata. The API traffic is the actual data flow and the metadata contains the information needed to certify, protect and understand that data flow. The metadata describes the details about the collection of APIs. It consists of information such as interface details, constructs, security, documentation, code samples, error behavior, design patterns, compliance requirements, and the contract (usage limits, terms of service). This is the rough equivalent of the registry and repository from the days of service-oriented architecture, but it contains a lot more. It differs in a key way; it’s usable and human readable. Some vendors call this the API portal or API catalog.

Next you have developer segmentation, which falls into three categories – internal, partner, and public. The last category describes a zero-trust model where anyone could potentially be a developer, whereas the other two categories have varying degrees of trust. In general, internal developers are more trusted than partners or public, but this is not a hard and fast rule.

Armed with this knowledge, let’s explore popular API Management deployment models, in no particular order.

Read more of this post

Ole for APIs…

Video of my speech from API Days Madrid here.  It starts after the first minute after Guillaume finishes his Q&A.

For the first time in my life, I was in Spain (Madrid) last week. What a lovely country and people. Great food too! It amazes me how people can speak multiple languages and entertain the clueless tourists like me by switching to English so quickly :).

ole

In any case, I was there to attend the API Mediterranean event. Can you believe that? This is proof that API has gone to the nook and corner of the world! It was attended by about 100 practitioners. The representative companies included Intel, Kin Lane the API evangelist, WSO2, 3Scale, Layer 7, FaberNovel, API Cultur, Webshell.io, MailJet, and many more. The enthusiasm and eagerness from participants were undeniable. Eduardo was a great host.

Read more of this post

5 Practical Steps to Building an Enterprise Class API Program

When it comes to building API programs, everyone seems to think in terms of technology, platforms, scalability, security, execution, hackathons, etc., but people tend to forget the most important thing. What do you think it is – TTM (Time to Market)? Additional Revenue? Newer Partners? TCO (Total Cost of Ownership)? Usability? IT approval? or Something else?

If you want to know what that is and how to effectively build an Enterprise class API program, please attend this webinar that I am co-presenting with Mashery and CapitalOne. Every customer seem to have an aha! moment after our conversation.

This live webinar is at 1 pm EST on May 22 (this Wednesday). You can register here http://tiny.cc/0ywexw.

Big Data, IoT, API … Newer technologies protected by older security

Now-a-days every single CIO, CTO, or business executive that I speak to is captivated by these three new technologies: Big Data, API management and IoTs (Internet of Things). Every single organizational executive that I speak with confirms that they either have current projects that are actively using these technologies, or they are in the planning stages and are about to embark on the mission soon.

Though the underlying need and purpose served are unique to each of these technologies, they all have one thing common. They all necessitate newer security models and security tools to serve any organization well. I will explain that in a bit, but let us see what is the value added by these technologies to any organization:

IoT – is specific data collection points that employ sensors placed anywhere and everywhere. Most often times the information collected by these devices are sensitive data and contain specific identifiable targeted data. IoT allows organizations to analyze behaviors and patterns as needed but also poses an interesting problem. Gone is TB (Terabytes) of data; now we are talking about PB (petabytes) of data which continue to grow exponentially. IoTs use M2M communication, which are a newer channel and create a newer set of threat vectors.

Big Data – store massive amounts of data (some of these data are from the aforementioned IoTs) and having the necessary software and infrastructure that allow you to access them faster which promises to cost you a fraction of what it is costs today, further enabling you to capture as many data points as possible.

API – interface, enabler and inter-connector between systems by providing a uniform and portable interface (whether it is to the big data or the platform that enables big data).

While each of technologies at first glance appears to be serving different constituencies within an Enterprise, there is an undeniable interconnectedness that exists. The IoT collects data from everywhere. Hence, it is pouring tons of data that need to be not only stored somewhere, but also analyzed properly so that the dots can be connected, to ultimately form meaningful patterns that people can make use of.

Read more on ProgrammableWeb (PW) blog site

ZDnet observation about Chief API Officer

Joe McKendrick of ZDnet wrote a blog commenting on my article Chief API officer. You can read it here.

He makes a couple of valid observations which deserves some clarification.

“CMOs may also help reinvent the business as a cloud provider in its own right — even if the business is something other than technology.” – I agree. This is due to the fact that IT is already crunched for capital and struggling to come up with money to spend on new platforms.  CMO not only has more money but can just shift the spending habits from spending on other marketing and revenue generating channels to this newer channel which has more potential.

“And CEOs and CFOs may like this new direction, since the CMO’s job is all about creating new business.” – I agree. I have seen this time and again. There are customers, Aetna is a prime example, who run (or endorse) the API programs out of the CEO office. Watch out for my follow up article where I discuss this in more detail.

“Is this a good thing? Enterprise technology has become incredibly complex, and it takes very technically proficient individuals to understand and guide the business to invest wisely and avoid costly security errors. Plus, many of the consumerish services being adopted by marketing departments are relatively simple compared to the programming and administration that goes into enterprise IT systems.” – This is debatable. First of all, we are not trying to create a new trend, just trying to embrace the trend. That is IT spending being supported by other organizations that are cash rich as opposed to cash strapped IT operations. Plus, when you invest just purely on the opex model, as opposed to capex model, their expenses are relatively cheaper (on a yearly/ usage model basis, not on a TCO basis which is another big debate). Ultimately, what I am suggesting is that while embracing this trend, provide the other organizations with a more mature, robust, and secure solution that will have an oversight and governance of a mature corporate IT unit even though it is owned, operated, measured and managed by people outside corporate IT.

 

Chief API Officer

Hackathons help you explain APIs to developers. But, do you know who you should be really selling the value of your APIs to? It goes way beyond the developers and IT operational folks. Who do you think it is ……CIO, CTO, CSO or someone else? You will be surprised. Read my article on ProgrammableWeb for more details.
http://blog.programmableweb.com/2013/03/11/is-the-cmo-now-the-chief-api-officer/

Dude where is my API

Watch out for my API strategy article series soon to be published.

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.

API strategy post

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

  Read more of this post

%d bloggers like this: