Change agents: Leaders in enterprise application architecture
A comprehensive collection of articles, videos and more, hand-picked by our editors
Blackhawk Network, a global provider of prepaid gift and reloadable cards, is moving from physical to digital card...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
offerings, particularly in the mobile computing space. A key part of this move is exposing the network through a set of application program interfaces (APIs) to digital distribution partners. Leading this project is API development and management expert, Mike Gionfriddo, chief technology officer (CTO) at the Pleasanton, Calif., company. Gionfriddo is the original author of the Jam API, now known as Java Management Extensions, or JMX.
"Taking Blackhawk Network's dominance in the physical card space and then moving into the virtual space was an exciting opportunity for me, due to my background in APIs," said Gionfriddo, a former Sun Microsystems Divisional CTO and Juniper Networks Distinguished Engineer. He saw it as a natural follow-up to his work on Java FX and client-side Java at Sun. "Due to my hard-core engineering experience, I know a lot about mobile devices, codecs, audio transforms, and system and network management," he said. In this interview, Gionfriddo shares his API management best practices and technology choices for the physical-to-digital services migration.
What is Blackhawk Network's foundation approach for API use?
Mike Gionfriddo: We've built our technology and API set to have a robust underlying system for physical business, and now we're tapping into that to open the digital business.
Our pattern of API usage for digital services closely mirrors what we do in the physical world. API management is about setting limits. I'm not a huge believer in creating big catalogs. Part of the dilemma with those is as soon as you create them, they're out of date. We have a couple standard ones that we use: Apache, mostly at the server tier and then, because we have some .NET, we use IAS [Internet Authentication Service]. If you pick just a few vendors that you want really want to work with, and they have a limited set of APIs, management is easier.
API management is about setting limits.
chief technology officer, Blackhawk Network
What everyday practices does Blackhawk Network's team in API management use?
Gionfriddo: We base our services off an underlying framework, so the services share some common code. Also, we have a simple checklist that developer managers have to go through. We have two classifications of APIs, internal and external; those shared inside of Blackhawk and those outside of Blackhawk. We do some self-assessment and checklists before publishing APIs.
The important job is separating out that [internal and external] policy. Enforcement usually points away from the actual code itself. We use Vordel API Server for security access control in both a physical and logical way to separate out API policy from the business logic. The Vordel server's security access control is helpful there, because control is set in one place and we know how to modify it. We don't have the app teams do that, and that provides us that separation. But it also provides us with auditability. Auditing is critical for our business, because we need to be PCI [Payment Card Industry] compliant and SSAE 16 compliant. Another need auditability fills is informing us on how we want to price for these services. This takes services development out of having to implement pricing.
What led you and Blackhawk Network to choosing an API server?
Gionfriddo: I got there in an interesting way. I was the chief architect at Sun's Middleware Division, and we were working closely with a competitor of Vordel. Also, I saw what IBM had done with DataPower, a nice architectural pattern for services. When I came to Blackhawk, a [team member] here had seen the [DataPower] patterns. So, we were on the same page in deciding to make API management layered, using approaches like rate limiting and even to route credentials potentially to two different instances. We have a lower SLA [service-level agreement] for a certain class of users, for example.
Using an API server as a control point gives us the flexibility to allow our business teams to say how they want to use digital card services, charge for them and create interesting models. An API server -- in our case, Vordel API Server -- gives us that flexibility. Again, for compliance, it gives us a nice way to have that control in a single point and not spread throughout the application tier.
Overall, I don't see any solution on the horizon that's going to manage all the APIs. Vordel API Server, however, delivers the controls we need, and integrates well with our development environment, so we can test those controls.