When I was learning to bowl, my father taught me to not focus on the pins, but focus on the arrows (also called “dovetails”) that are about halfway down the bowling lane. The purpose of the dovetails are to help improve your targeting on whatever pin you are trying to hit. It helped my game immensely. For me there’s an analogy here with API Management and APIs.

I love API management and APIs since I feel they provide real value for any organization who wants to manage and measure the components exposing its capabilities and information to their customers. An important part of my conversations with organizations who are looking to enhance their offerings with an API program is always around value. That conversation usually starts with asking what sorts of things can you do with an API program?

Mobile and Web Applications

Yes, these are common ones and the most prevalent. If your business (large or small) will benefit from mobile app or web application then you should look at the API program as an enabler. Sometimes the resulting app will be a marketing tool  (such as a gamefication app) or a support tool (allowing your customers to interact with your business 24/7/365.) Sometimes it will be something that goes well with your social media campaign. Sometimes that app will be a new, direct revenue stream or in some cases the app will be your business. In any of these cases, your API program will offer the platform for your mobile app and web applications.

Internet of Things

An extension of the mobile app idea, but much more focused. Analyst projections for IoT predict that the worldwide IoT spending in the enterprise alone will be more than $800 billion of dollars in 2016 and higher in the future. Everything from your home to your car to a host of electronic devices will be connected with billions more “things” being connected every year. One of the (obviously) interesting things about the IoT is the scale. To borrow a quote from Douglas Adams, “You just won’t believe how vastly, hugely, mind-bogglingly big it is.” And for the business that will benefit from IoT implementations that an API program will support, API management solutions  will provide the gateway, security, reliability, and accessibility to the internal capabilities that these devices will rely on. API Management will offer all these in addition to helping to measure and manage all this connectivity.

Innovation and Acceleration

Have you ever sat at a table full of building blocks? If you’re like me, it’s hard not to start creating things by stacking and arranging them. That’s one of the way I think of APIs. By providing your APIs you’re giving developers a table full of blocks to create. But that analogy only covers part of the picture. API management solutions fill in gaps that allow developers to easily get access to the APIs, discover what APIs are available, and see examples of their use. It also gives a channel for feedback, tracking and measuring API usage, analyzing API efficiency, and a host of other capabilities.

Conclusion

For an API program, it is important to focus on what you want to do with your API program and what defines a successful program. Don’t overlook the dovetails. Once decided, then API management brings to bear to help manage and measure the success of your goals (and help with course corrections when necessary.) If you’d like to have Perficient join you for a conversation about how to make a strike in the new digital economy by transforming your business with APIs and other IT modernization initiatives please contact us. You can read more about our services here. .

Contacts

Ed Murphy

Sara Lieser

References

Gartner Says 6.4 Billion Connected “Things” Will Be in Use in 2016, Up 30 Percent From 2015, Gartner Press Release

Without API Management the Internet of Things is Just a Big Thing, by John Thielens

I recently read an article that I think really puts the right focus on digital initiatives which is a great response to the question “You’ve started your digital transformation journey, so now what?” The article hits several notes that are well-known to folks that have read my articles before.

• Customer experience is a primary focus.
• Your business must learn to adapt to a changing technology landscape but…
• It isn’t (all) about the tools, especially at the beginning. It’s about how you change your business to support digital initiatives. It’s about aligning your people.
• And the first thing to do is to get those people talking and figuring out your direction. As I said in a recent webinar (slides), at the beginning of navigating your digital strategy you must lead a conversation that includes business leaders, IT, and the C-suite to chart where you’re going (and how to figure out whether you’ve gotten there or not.)
• Lastly, when it comes to developing your strategy you’re goal might not involve replacing everything. Sure you might trim a bit but you’ll also build on the strengths you have.

References

“Putting ‘Digital’ In Perspective” by Jaisundar Venkat

This is another in a series of exploratory questions that someone might ask when kick-starting an API strategy for your company. Contact the author.

What are your important considerations before establishing an API strategy?

I’m not what one might call an exercise enthusiast (though I do enjoy working up a sweat) but Pilates has always interested me. Its appeal is that it does things in the right order. Pilates focuses on the “center” as the starting place to develop strength and that movement flows “outward from a strong core.”

So how does this relate to building your API strategy?

A part of the API strategy discussion will be around the purchasing of an API Management tool. In discussions I’ve been a part of, this topic comes up too early in most cases. While it’s not uncommon for someone to think the tool will solve the problem, everyone knows deep down that just buying the tool will not get you to your goal. Before API Management software can even begin to show its value, a business must look inward, determine the strengths of its “center”, and if something is lacking, prepare to fix it as part of the initiative.

Governance

It is very common (but becoming less so) for some to confuse API Management and SOA governance disciplines. There have been many articles written on this subject and it’s easy to understand where the confusion comes from: API Management has its roots in SOA governance and many aspects (like service life cycle, provisioning, security, mediation, etc.) are still there. I agree with idea that API Management is the next, natural extension of SOA. Typically SOA governance deals with services as they exist within the company and API Management deals with exposing these services to the “outside” via a gateway which protects the business from denial-of-service attacks and other security concerns. API Management also adds the developer ecosystem (portals, forums, etc.) and this is particularly important because if your service is not adopted and used by developers then your API program is dead in the water.

The elements of a great SOA governance program are part of the core strengths that you need to have if you want to succeed with your API strategy. If you have not had strong governance in your business (or if it is there but not followed) then this will be one of your biggest hurdles. At Perficient, we’ve found that companies that already have some form of governance in place were able build on  this for SOA governance and will be able to do the same for API Management as well. For those that don’t this will be the starting point and you will need a lot of “exercise” to build up this strength. Some consideration should be given to the governance model and the proper model is described in one word: Light. In an API program, your teams need flexibility and agility to respond appropriately.

Efficiency

DevOps is another common discipline that gets press these days. On the surface, the term is a joining of the development and operations organizations to streamline promotion of new features to production. The discipline has grown from the idea that the two groups are working at odds as operations seeks stability (which implies little change) and development seeks to add new features (which implies lots of change.) By combining the two groups into one, you have a group working with both areas so when an issue arises in production the right people to fix it are immediately aware of it.

Development and operations are part of the discipline, but they’re not the only ones. Business involves giving information on what new features are relevant, change management involves tracking changes, and QA involves testing and giving feedback among others. The idea is that to get your teams delivering new features and updated code in a more streamlined process you’ll have to look inward again and develop a culture of sharing and collaboration. This is a daunting task since this new mindset is very different from the “waterfall development” days that persist in so many company cultures.

The ability to go from an idea to an actual production feature as quickly and efficiently as possible is another strength supporting your API strategy.

Alignment

The last item I want to introduce in this article is alignment. In any undertaking all stakeholders should strive for a sharing and collaborative mindset. The goals are larger than any personal or departmental agenda and the best way to approach this aspect is open, honest conversation. The core API team should help lead discussions and sharing sessions to include as wide a range of opinions as possible. An API strategy is one of the most comprehensive strategies that you’ll face in your business from the executive level to operations. Consider asking questions such as

• What data and capabilities should we expose?
• Who will use the API and how do we get them engaged?
• What is it about our business that makes us unique and that we can expose via an API?
• What apps for our customers or partners can you imagine and how would they create value?

These questions and more will help to show the first steps of your API strategy and because you include a broad range of colleagues there will be some genuine investment.

To summarize, when exploring an API strategy the first important step is a plan and discussion to consider all your core strengths.

• Review the governance model that your business supports. Find gaps in service lifecycle, security, provisioning, mediation, and other important areas. Keep the model as light as possible to make your teams more flexible and agile.
• Consider the process of taking an idea from conception to rollout and in as short and efficient a cycle as possible.
• Align your stakeholders and determine standards and processes that provide the basis for understanding and collaboration across the company towards your common goals.
• Start with simple changes and establish a roadmap where you mature your API strategy/program over time.

By deliberate planning and conscious efforts as you work through your API strategy conversation you will be in a position to make a solid contribution to the digital strategy of your business. Perficient’s Health Check and Quick Start Rulebook can help in these areas and more.

References and Further Reading

“APIs and Platforms: How interfaces and access enable the networked economy” by Sangeet Paul Choudary and Manfred Bortenschlager

“Pilates”, Wikipedia entry

“APIs: A Strategy Guide” by Daniel Jacobson, Greg Brail, and Dan Woods

I read an article today by Adam Lent that took a perspective on how leadership is changing based on what has been happening with social media in the past decade. The sentence that jumped out at me was this.

The result [of the success of Facebook, YouTube, Twitter, etc.] is a growing awareness from those who think about business structures for a living, that good leadership is no longer about ‘taking charge’ or imposing a strategic vision but about creating the platforms that allow others to flourish and create.

If you’ve read any of my blog posts you know that I strongly applaud this.

As I’ve mentioned before, when most people see API management they tend to concentrate on the “API” (technical part) not the “Management” (discipline part.) The management aspect is the “new” part where we are getting software suites that can be used to easily expose APIs for consumption, monitor their use (or watch for abuse), secure them, etc. and this is usually one of the first things that I point out when starting conversations about building an API strategy. The technical part of writing the APIs is not that different from how we’ve done things in the past. When I read Mr. Lent’s article, it reminded me that the goal is not to have a bunch of APIs but to have a platform for people to create. Framing this point as a sea change for leadership in the 21st century makes a lot of sense to me.

Today’s professionals, particularly those who have developed their skills over the past decade, want these platforms to build their visions. These professionals might be your employees, but increasingly they are not. They live outside the walls of your company and one of the best ways to entice them to work with your brand is by showing them that you “get it” and can offer a way for them to (as the article states) “to flourish and create.”

If you are already on the road to building your API program or if you’re just starting the conversation, keep in mind that you’re not building just a bunch of APIs, you’re building a platform as a call to developers that you are ready to lead them into a bright and creative future.

References

“What does leadership mean in the 21st century?” by Adam Lent

This is another in a series of exploratory questions that someone might ask when kick-starting an API strategy for your company.

How do you make it easy for users to access your business assets and capabilities using APIs?

A word that is typically used when people start talking about getting access to APIs today is “frictionless”. Opening your APIs so that users (usually developers) can get access to them is an important part of your API strategy. You want people to be able to sign up, learn how to use your APIs, and be able to access them in the most efficient, enabling way possible – creating this frictionless interaction between developers and your business.

Self-Serve

In 1947 the first self-service gasoline station opened in Los Angeles. It still required attendants to be present at the pump to take money and reset the pump back to zero after a customer had finished pumping gas. The “newfangled” process had some success but frankly businessmen adopted it because it saved them money (because they could use less staff at their stations) not because it was of any real help to the customer. In 1964 came the next innovation: remote access to the pump. Now a single attendant inside the store could control the pumps making for a much more streamlined process for the customer to pump their own gasoline and not have to wait for an attendant to do it (of course now the customer had to go inside to pay the attendant.) 1973 saw the next evolutionary step of pay at the pump. Over time all these came together to make self-service an obvious choice for gasoline stations to increase sales and provide a better experience for the customer.

Today’s API management solutions use this same self-service idea as the first steps to engage its potential users.  People can sign up and get access to a company’s APIs typically through a quick and easy form and then access can be granted in a couple different ways. A company can configure their API management solution to give the user some basic type of access immediately, for example access to a subset of the APIs available and some restricted form of access like a maximum number of calls per day for free. They might have a “pay-at-the-pump” model where the user can pay for high-level access (more APIs or more calls per day.) A company can also have an approval model where the request goes into a queue so that it can be reviewed before the approval is given with the click of a button. The goal is to make the process of getting access to the API as easy as possible for the user so they can start developing.

Getting Started

It should be easy to learn how to initiate an API request and interpret the API response. If you’ve read anything at all about APIs, you already know the REST protocol (based on standard HTTP) and JSON data formats are prevalent for implementing APIs. This is true based on lots of feedback from users and industry experts who say that this is a straightforward methodology to provide access to the APIs. That said, there are certainly other protocols and data formats that can be used with SOAP and XML long being popular as well. Different situations might call for different approaches. For example SOAP might be used if you want to take advantage of the self-validation of an XML payload but overall the people have spoken and REST/JSON are definitely deemed a good choice with good reasons to support choosing it (and there is work to extend the JSON specification to provide self-validation and other enhancements which some say provide some of the positives of SOAP/XML without the perceived negatives.)

Using the APIs also includes having access to great documentation and examples. I’ve been in many projects and documenting work can be a tedious and time-consuming task. At worst, it gets pushed until there isn’t any time to do it properly (or at all) or it is done but not maintained and is quickly out of date. Up to date documentation and examples of how to use your APIs is a crucial effort for a successful API program. Most API management solutions have support for various documentation standards and tools that are emerging in this space. Swagger, RAML, WADL, and others (proprietary and industry standard) are tools available to accomplish this. API management vendors also (generally) offer developer portals to support access to this information and the ability to run APIs to provide examples of its requests and responses. Developers are a unique kind of customer and they are vocal when they are expected to use tools with inadequate documentation or missing examples. Remember: You want them to be fans, not just users.

Community and Support

Support your API users by providing them a forum where they can post successful applications of your APIs, discuss problems, and share their experiences with your API platform. Not only does this peer discussion help them, but it will also help you by providing enormously valuable feedback on what’s working and what’s not with your API (developers are famous for telling it like it is…you only have to listen!) If possible, create the opportunities for your API users to gather virtually and (even sometimes) physically through hack-a-thons, meet ups, and conventions. The external people (outside your organization) that are using your APIs are an extension of your company and the internal people (your own employees) who are using the API are the creators and innovators of your company. Supporting a sense of community is just good business.

Turning your API users into fans is a golden opportunity and making it easy for them to get access and learn how to use your APIs is essential when forming your API strategy.  Fans don’t just use what you’re offering. They celebrate it and promote it and lift it up to others which is another strong pillar to grow the strength of your API program.

To foster innovation, creativity, and excitement within a solid developer ecosystem you should

• Establish frictionless developer on-boarding for API access
• Create and maintain great public API documentation
• Nurture a collaborative developer community

And this will support a successful API program for your company.

References

“Self-Serve Evolution” by Sarah Hamaker

“Siren: A hypermedia specification for representing entities”

“GeoJSON”

This is another in a series of exploratory questions that someone might ask when kick-starting an API strategy for your company.

How do APIs foster innovative development? Why would you want to foster innovative development?

Innovation. It’s a word that is bouncing about these days, but what does it mean in the context of API management? Well, you heard the one about a million monkeys typing will produce the complete works of Shakespeare? What if it’s a million really smart humans with a focus on creating something valuable with your API? Can you imagine what they might create? Thomas Friedman made a statement in his book The World is Flat that’s stuck with me since I first read it.

Only 30 years ago, if you had a choice of being born a B student in Boston or a genius in Bangalore or Beijing, you probably would have chosen Boston, because a genius in Beijing or Bangalore could not really take advantage of his or her talent. They could not plug and play globally. Not anymore. Not when the world is flat, and anyone with smarts, access to Google and a cheap wireless laptop can join the innovation fray.

The talented developers that you engage with the right public API strategy are global and exposing an API to people “out there” has incredible potential. You really don’t know what they’ll come up with. And it might be the next killer app (at least in your business domain) that catches on fire. Using APIs to extend your IT capabilities beyond the walls of your organization is one of the benefits of developing a solid API strategy.

But it doesn’t have to be “out there” either. Many people within IT are just itching to spread their wings. Sometimes the only thing holding them back is a company’s “structure”. I remember growing up and my grandfather loved to collect stuff. There was a barn full of it and from that stuff my friends and I created spacecraft to fly, dragons to slay, and all sorts of stories to while away the summer days. Adults aren’t so different. If you give them a the right playground and tell them it’s OK to “create” you will be amazed at what they come up with.

What are you doing in your company’s culture to create an environment where people feel free to innovate?

References

“It’s a Flat World After All” by Thomas L. Friedman

Maker Culture from Wikipedia

Businesses today face many challenges to use their resources (personnel, data, and capabilities) to support their brands and connect with customers in as effective and engaging manner as possible. In many cases these challenges can be defined in two concepts: “exposure” where information and capabilities are made available to people who can use them and “consumption” where people can make use of the information and capabilities in as effortless way as possible.

API management products are industry solutions that support both of these concepts. With the proper solutions in place a business can expose data and capabilities appropriately and securely to people (both internal and external) allowing them to easily consume the APIs and build applications that use the information and processes that make your business unique.

One of the surprising things in many client conversations it is how often the same questions come up in initial discussions. Over the next few weeks, I’d like to visit some of these questions in a series of blog posts to provide basis on how we might kick start a conversation about an API strategy.

The first question I want to address is “Do you want your APIs to be public or private?” The conversation around this question involves two of the most fundamental aspects of an API, namely who are you writing the API for and what the goal for creating your API is.

Do you want your APIs to be public or private?

This question is one of the first questions that people consider and usually it is easily answered. The first point I’d like to make here is that two types of API programs are not mutually exclusive and they often go hand in hand.

In its purest form, public generally means that you want people outside your business to have access to the APIs. Usually these people will be independent developers who want to use your API to build something that they think will be valuable to consumers. Following this path can promote your brand, expand your IT capabilities beyond your IT staff, and (if you monetize your API) can offer a new revenue channel for your business. API management software is used to control secure access to your APIs and monitor and control the traffic coming in from these independent developers. There are a myriad of public APIs to consider as examples such as the one created by the movie rating site Rotten Tomatoes or National Public Radio’s API to get archived content in a convenient, standard way.

Private means that you intend to even more closely control who has access to your APIs and usually these people will be employees of your company. This path is used to organize and normalize access to business assets and provide a frictionless way for internal developers to get self-service access to different parts of your business (for example each line of business might share its own set of APIs.) Examples of private APIs are a little more difficult to reference because, well, they are private. However ESPN and Netflix are representative of a public API that was taken private after a period of time.

Both public and private API programs can foster innovation and provide a self-service mechanism allowing developers to gain access to the capabilities that the APIs provide. Additionally there are some other types of access along this spectrum such as APIs that are designed only for trusted partners to access allowing them to access and share data in a more streamlined way or if your business acquires another company exposing an API to them can help them get integrated into your business environment quickly and easily.

Remember, the answer to this question is not mutually exclusive. You can purse a private strategy, public strategy, both, or switch from one to another at any time. Some considerations should be made when choosing one or the other however. After establishing a public API program, deliberate consideration is advised when moving the APIs to be exclusively private. While there may be valid reasons for doing so, how you go about it will directly influence the user base you’ve built up and the applications that have been created on your public API. You’ll want to mitigate any negative impacts to the good will and brand promotion built up through the course of working with your external developers. On the other side of that coin, when working through building a private API program you should always keep in mind that someday it could be made public. Keeping this perspective, strategic and tactical decisions can be made so that any rework that will ultimately be required to expose the private API to external users is minimized.

References

“Welcome to the Rotten Tomatoes API” (http://developer.rottentomatoes.com)

“NPR Tech Center, API Documentation” (http://www.npr.org/api/index)

“Public API Retirement” by Chris Jason (http://espn.go.com/static/apis/devcenter/blog/read/publicretirement.html)

“Netflix Kills Off Its Public API, Takes A Few Applications Down With It” by Greg Kumparak (http://techcrunch.com/2014/11/16/netflix-api/)

The government uses a lot of technology, and the current administration established the position of Chief Technology Officer as a step to increase the use and efficiency of technology in government. Today is Tax Day in the United States and for our global readers that’s April 15, which is the deadline here in the United States when the U.S. government requires tax returns to be filed. Being tech-curious, I was doing some reading about the e-File program that the IRS put into place in the mid 1980s. I found the story to be a textbook case for the advantages of modernizing a complex business process.

The IRS e-File initiative was a response to the increasing complexity of the processing tax returns being filed on paper forms. There were many anecdotal stories around that process where errors abounded that both citizens and tax professionals can attest to and had to deal with on a daily basis. It was around 1986 that the IRS R&D department suggested that electronic filing would provide many advantages that are very common today in our modern business and technical landscapes. In the trial that was run many of the hardware and software solutions available in that period were used. Data was transmitted over modem, stored on magnetic tape, which was loaded into COBOL programs for processing. I remember all these well having dealt with them at various times in my early career. The project showed enough promise that it was pursued and eventually as one IRS Commissioner has said became one of the federal government’s most successful programs.

When the project moved past the trial period, it processed about 78,000 tax returns in a limited trial that first year (1987) and added a direct deposit for refunds to the benefits for citizens. As people and tax professionals became more interested, the popularity grew. In 1990, when the program went nationwide, 4.2 million electronic returns were handled. All the while, the technology was refined and improved.

In 2004, a new initiative started called the “Modernized e-File Program”. With the new initiative and over the next several years the technology improved and the system became easier to use for both individual citizens and tax professionals (and also added many more IRS forms to the capabilities) which resulted in exceeding 100 million e-Filed returns in 2011 and much more today.

The advantages are well known. Faster processing of returns and less errors as systems rely on automatic processing and business rules. With electronic funds transfers becoming more common, the average citizen can file taxes easier and get results quicker than ever before. True, this doesn’t help organize that “shoebox full of receipts” but by making the tax filing system easier and more efficient the tax burden seems a little less daunting when April 15th comes around.

Given recent issues with the healthcare website and other technology-related stories that come up in government, I found it somewhat refreshing to read about one initiative that seems to have gotten things right.

More Reading

http://en.wikipedia.org/wiki/Modernized_e-File

I love jazz. As a young boy moving from rural South Carolina to New Orleans in the early 80s, I had not really appreciated the genre, but in New Orleans it’s easy to fall in love with it since it has made itself part of our DNA (as an early style of the genre was born here.) The other day I start musing about API Management and began connecting some of the concepts between these two different things that I wanted to share.

Out of One, Many

Music has, of course, had been around for a long before jazz emerged and the same can be said of APIs relative to API management. APIs are not a new concept but the way they’re being used today and the management capabilities emerging from the myriad of use cases and products (both open source and proprietary) are helping to foster an incredibly creative and vibrant environment for developers. Exposing capabilities through APIs, analyzing their use, and building a community around them are all plainly understood components that are coming together to form a strong foundation for this transformative opportunity.

An Innovative Movement

Jazz emerged as an innovative form of music and many aspects of the genre carry that innovative spirit over today as musicians experiment with new techniques, styles, and ways to use their instruments. In today’s API economy the same holds true. By exposing APIs and allowing developers and partners access to different capabilities unique to your business, you’re allowing them the creative freedom to stretch boundaries and come up with new and interesting ways to use those capabilities. As Jeff Perry says in his article on jazz and innovation “By allowing freedom, balanced by rules, guidelines and values, the culture necessary for innovation may be possible for you to attain.”

Striking the Right Note

Many forms of jazz have developed since it emerged as the form is interpreted and re-interpreted by each generation of musicians. As you take the first step to develop your API strategy, from that moment  when you ask yourself “What will the API do?” and “Who is this API for?” the journey will lead you to developing your unique perspective on what you have to offer in the digital economy. By investing in the time to ask and answer the core questions you will be able to set up a solid API program and forge a strategy to take your company into the future as a digital business.

Conclusion

Jazz music is appreciated all over the world. Though it came humble beginnings, it ignited something in the hearts of the people who enjoyed it and the musicians who embraced it. Do you have a “jazz culture” relative to your API strategy? Is there something about your company or business that is unique and you want to share with people to create that innovative transformation that many companies are undertaking today? Is it something that you think could capture the hearts and minds of developers, partners, and ultimately customers? By exploring these topics and embracing the API economy you’ll be on your way to make some beautiful music.

References

“Jazz & Innovation: How the Jazz Culture Fosters Creativity” by Jeff Perry, http://www.allaboutjazz.com/jazz-and-innovation-how-the-jazz-culture-fosters-creativity-by-jeff-perry.php?page=1