As I approach 2016, I'm stepping back, and looking at the big picture of what it is that do, and using what I learn to help guide what I will accomplish in 2016. I tend to not subscribe to the concept of predictions, and instead focus on what change I personally would like make within the API space, and this strategy is key to me achieving this vision.
First, let's start with what do I do? I track on the world of APIs, with eye towards how we can better execute on the tech, business, and politics of APIs, based upon a better understanding of approaches established by existing API providers, and the features being offered by service providers who target the space.
In 2010, I started tracking on API management, and in 2015 this has expanded to almost 35 areas:
- Aggregation
- Branding
- Client
- Containers
- Definitions
- Deployment
- Design
- Discovery
- DNS
- Embeddable
- Evangelism
- Hypermedia
- IDE
- Licensing
- Management
- Monetization
- Monitoring
- Partners
- Patents
- Performance
- Plans
- Privacy
- Ratings
- Real Time
- Reciprocity
- Regulation
- SDK
- Security
- Spreadsheets
- Terms of Service
- Virtualization
- Voice
- Webhooks
Originally I saw these research projects as just various lines along the API life cycle or journey, but increasingly I'm also seeing these as just the "first" stack of API resources that I study. Meaning, in 2016 these aspects of the API journey are themselves increasingly API driven--API deployment, management, monitoring, and many other areas are being automated via APIs.
Over the last five years, I've conducted my research by studying the approach of successful API providers like Amazon, SalesForce, Google, Twitter, and the longer tale of lesser known government, university, and utility APIs available today. Along the way, these APIs have started organizing themselves into logical groups for me, some based upon the industry they operate in, while others are more about specific business or developmental goals.
I call these groupings "stacks"--they also go by other names like hubs, industries, categories, but one important aspect of stacks for me, is the ability to mix and match to meet various objectives, as if the APIs were legos. Some of these objectives are more individual or consumer-focused, with others being more commercial or industrial, giving me as much flexibility as I can in assembling meaningful stacks of useful API driven resources for any possibility.
With my core API life cycle and journey research coming into focus so nicely in 2015, I am also working to do the same with other API stacks in 2016--here are the main areas I'm focusing on out of the gate:
- social
- messaging
- users
- storage
- compute
- documents
- commerce
- payments
- photos
- videos
- music
- audio
- voice
- search
- content
- language
- news
- travel
- mapping
- places
- businesses
- links
- events
- weather
- movies
- advertising
- accounting
- shipping
- government (city)
- government (state)
- government (fed)
- home
- auto
- wearables
- energy
- space
- healthcare
- environment
- education
- libraries
- university (faculty)
- university (student)
- sharing economy
The how and why I craft each stack varies. Many of these stacks I consider to be the essential aspects of the modern Internet experience, like compute and storage, or photos and videos, while others are more business sector focused like energy, healthcare, and education.
As I dive into a stack, the chances of it expanding and evolving increases significantly. You can see this with my email, SMS, and MMS research, or with my financial news and news research. While I try to capture any individual area, the chances it will spawn entirely new research areas, or share affinity with other existing areas are pretty great.
Ok, so what actually happens in all this "research", "monitoring", and what not? The value from the exhaust...I move things forward using several working models:
Analyst Model - Generation of short form (blog posts), a project area (on Github Pages), and industry guides (HTML & PDF) in each area of research. You can see this in action for the 35 lines (stacks) for the API lifecycle, and the handful of topical stacks I've done in messaging, news, etc.
- Companies - What companies are involved?
- Individuals - When relevant, what individuals are involved?
- APIs - What APIs exist in an area, complete with OADF + API Blueprint + Postman + APIs.json.
- Building Blocks - Common elements derived from features, and API resources.
- Tooling - What open source tooling is available beyond services.
- Opportunities - Where are the gaps in what is being done vs. what is needed?
While the majority of my research is publicly available, and openly licensed, in some sectors I will keep guides, and building blocks private, essentially available behind a paywall. All my partners are welcome to co-brand any of my public guides, and I am actively looking for sponsors of specific areas of research when it comes to doing initial research, to cobranding content and putting behind lead gen.
Strategy Model - Individual and industry level guides for others to follow, when planning and crafting their own strategies.
- Building Blocks - Individual building block examples for companies, such as rate limits for AWS EC2, or SendGrid email.
- Operational Bluprints - Blueprints for API operations, example would be cloud computing, SMS provider, video provider.
- APIs (Definitions) - OADF, and APIs.json collections that provide a machine readable blueprint for use in strategies.
- Journeys - Walk though of series of analysis and building blocks, in specific areas, with specific outcomes.
Like the exhaust from my analyst model, some of my strategy work will be publicly available, and openly licensed, but this is the area where i will keep a little more information behind a paywall, requiring some action, or money to access my hard work and expertise.
APIs in Infrastructure Stack - Design, development, and management of focused API that deliver value somewhere along the API life cycle.
- Retail - Design, development, and management of APIs that deliver on specific stops along the API life cycle, made available as self-service resource.
- Wholesale - Design, development, and management of APIs that deliver on specific stops along the API life cycle, made available as on-premise resource.
- Journey - APIs in support of strategy journeys, allowing users to build strategy, and revisit and evolve strategy, using custom designed APIs.
This is a new area for me in 2016, but will allow me to better serve gaps that I identify in the overall API life cycle. I will not be launching APIs to compete with regular API providers in the space, and keeping my work focused on APIs that deliver API infrastructure resources.
Tooling for Infrastructure Stack - Design, develop, and operate JavaScript tooling, that runs as micro-apps on Github pages, running locally and / or using API infrastructure I've deployed.
- Single Page Apps - Develop, operate, and evolve simple JavaScript apps that support the API life cycle, using my Github Pages model for deployment.
- Monetization - I will be playing with different models of access ranging from open, free, to paid, and advertising support options.
Development of these types of applications for revenue, like API design, deployment, and management will be new for my operations, and an area where I will also focus on applications that support the API life cycle. Like APIs, all apps will do one thing, and do it well, with a very modular approach to operations.
The analyst portion of my operations is 100% based upon my own work, and is something I will not be scaling, relying on my own process, APIs, and tooling to scale. However when it comes to publishing of guides, strategy blueprints, and API and tooling deployment, I will be aligning myself with specific partners across the space. These partners will bring proven value to specific areas of the API life cycle I am working to bring to life in my research, analysis, and content, API, and tool creation.
As always, the more I do, the more I learn, and the more this plan will evolve--this post is just meant to be a guide that will help me get started in 2016.
