Sunday, November 29, 2015

Architecting a Digital Platform - Presentation at Gartner AADI 2015

The Gartner AADI (Application Architecture, Development & Integration) Summit kicks off tomorrow in Las Vegas. Each year, this event is an opportunity for architects at leading organizations to connect and discuss the latest trends in application and systems design. This year, the focus is on “Empowering Innovation, Leading Transformation”.  Topics covered will include API strategies, business analytics, and how to design powerful user experiences.

A key part of embracing digital is to architect a Digital Platform. This platform is what enables Digital Engagement, by underpinning new user experiences across many channels. Underpinning this layer is the Digital Foundation layer, which is enabled by APIs. Increasingly, those APIs follow a microservices framework.

Following a pace-layered approach, the architecture allows an organization to function at multiple speeds. The fast-moving UX layer consumes APIs which are in turn mapped to underlying systems.

In my talk at ADDI, at 9.30am on December 2nd, I will be talking about how to architect a digital platform.  I will peel back the layers of a typical Digital Platform, from the fast-changing UX layer, to the API layer, as well as a microservices framework. Case studies are always important in a talk like this, to show how organizations are leveraging a digital platform to enable digital transformation in the real world. I'll show how three leading organizations have deployed Digital Platforms, enabling them to innovate to meet customer expectations.

I look forward to seeing you there!

National Australia Bank (NAB) Hackathon

Hot on the heels of the UniCredit Appathon comes the NAB Hackathon, also sponsored by Axway and with APIs hosted by the Axway API Management platform. It took place this weekend, and by all accounts was a great success.
The NAB hackathon featured a REST API, with simple clear documentation which included sample API calls. As they put it in the API documentation, "The interface is a RESTful JSON based API, so you could even connect your IOT infrastructure to it (maybe your toaster needs to transfer some money to your fridge?)", and "If you have ever used the website, or any of our mobile apps, then you've already used our APIs."

Hackathons are a key part of the digital engagement being pursued by leading organizations like NAB and UniCredit. An API Management platform is a key part of a hackathon, because it enables stubbed-out APIs which act as a kind of sandbox for developers. For the API provider, the API Management platform provides API Key authentication, OAuth support, and analytics on the API usage. The analytics are particularly useful because they provide a way to gauge which APIs are most popular in the hackathon. This usage info is a valuable piece of feedback into API design. Often the most exciting aspects of APIs are when they are used in unforseen ways, and a hackathon provides a kind of petri dish for this kind of innovation.

First prize was won by nabSaver - congratulations!
And here is the group photo of the hackathon participants. I can spot at least three Axway "API First" shirts! (clue - one is in the bottom-right being sported by our very own Axel Grosse)

I look forward to lots more hackathons enabled by Axway!

Saturday, November 7, 2015

From Ideas to Innovation - UniCredit Appathon 2015

Right now the UniCredit Appathon is happening in Milan, Italy, with the Axway team involved as a sponsor. A key part of any hackathon is setting up mocked-up or simulated API endpoints in a managed environment - which is where Axway comes in:
"...developers will have access to UniCredit API infrastructure, loaded on an external playground with fake data, and API management solutions sponsored by Axway"
In this way, developers have a sandbox of mocked-up data to develop apps against APIs.

Of course, prizes and free "API First" t-shirts are also a part of any hackathon! And it's also great to see the Axway red ball up in lights with the UniCredit red ball the big kick-off today:

My colleague Luigi Ferrari has shared photos of the Appathon in action:

I had the pleasure of visiting UniCredit in Milan earlier this year, and I was very impressed with their vision for their APIs. UniCredit includes developers as a central part of this vision. Even before their APIs are out of beta, they have engaged developers using sandboxed APIs in their Appathon hackathon. The Appathon then becomes an important part of sourcing ideas for the future direction of their APIs, because the apps coming from the Appathon feed innovation into future versions of the APIs. It's a great example of continuous innovation, as the UniCredit slide below, presented at the Appathon today, shows:

Best of luck to all the participants!

Thursday, November 5, 2015

Managing API Lifecycle - Publishing, Versioning, Deprecating, Retiring

One of the most important part of API Management is to manage API lifecycle. This includes publishing APIs, versioning APIs, and then finally deprecating APIs.

Here you can see how the Axway API Manager makes it simple to right-click on an API definition and choose to upgrade it:

When you upgrade an API, you have the options of deprecating and/or retiring the previous version of the API. Of course, you can also deploy the new version of the API side-by-side with the previous version. Here are the options which you're provided with in the Axway API Manager:

SOAP APIs (Web Services) have not gone away, even though REST is clearly the future. At Axway, REST APIs sit side-by-side with SOAP APIs, and both benefit from the same API Management functionality. Here we see a SOAP API being upgraded to a later version (which uses SOAP 1.2 in this case):

Finally, here we see API deprecation in action. Axway API Manager allows you to set the date on which the API will be deprecated. Developers who have signed up to use the API are notified.

For more info on API Lifecyle Management and more, using Axway API Manager, check out the Axway API Management product info.

Tuesday, October 20, 2015

Controlling API Access based in identity and API parameters using the Axway API Gateway

The Axway API Management platform makes it simple to configure a policy so that, for example, the userId "joe" is allowed to call /api/service?id=222  but not /api/service?id=333

Let's see how this can be done.

Firstly, I have setup a path on the API Gateway for "/api/service" to a policy called "Fine Grained AuthZ"

Let's look at this "Fine Grained AuthZ" policy:

You can see that it's a relatively simple policy, where the important work is being done by a "Compare Attribute Values" filter which is checking the identity of the client and the value being passed in the API call. Because the client has been authenticated at the top of the policy, the client ID is available in the "" attribute.

Now, if you press "Next" on the "Compare Attributes" filter, you can set the info that is shown when the filter runs:

You can see that I am setting that if the user is not authorized, then I will see the following parameterized info in my traffic log:

UserID ${} & parameter ${} not Authorized

So let's test this now, using a browser:

You can see that, when I pass "222" as the parameter, and authenticate as "joe", then I am authorized.

As the API Gateway admin, this is what I see in the Traffic Monitor:

If I pass in a different parameter, then we see where the info I configured in the "Next" part of my "Compare Attributes" filter is displayed:

This enables me to see exactly why the API call was blocked.

What if you want this policy to be called for all incoming requests? You do this by right-clicking on the policy and choosing "Set as a Global Request" policy, as shown below:

This is quite a simple ACL (Access Control List) example. If you have a long list of users and attributes, you could use the Key Property Store (KPS), or make use of the embedded Apache Cassandra database to look up the authorization.