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

%d bloggers like this: