LinkedIn
Twitter
Introduction
So you have executive buy in, you've purchased an API Management solution and you have business users wanting to deliver new services. What's next? How do you kick off your API Program? How to you ensure that the program achieves and maintains the velocity demanded in todays Digital Economy?
This is a common question we in the Apigee Customer Success group get from customers and this article outlines some of the concepts we use to get them going on the right path.
Blueprint
A Blueprint is the engagement we most commonly use with customers to start this journey. As outlined by @Alex White in his article Everyone does a blueprint! Its just a matter of time... many of the concepts we use in a Blueprint will be familiar and will be on your To Do list. The key here is to get these concepts clear at the start of the API Program to provide a solid foundation to build on.
A Blueprint is typically a 3 week engagement with the first week spend onsite with the customer. There is also some preparation before this first week where we'll build and idea of where the customer is today by going through a set of preparation questions that allows us to focus on the areas that will be most impactful for the customer.
These questions are grouped into 5 sections
- People
- Vision and Success
- Process and Dependencies
- Methodology and Tooling
- Requirements and Design
Kick Off
The kick off meeting on the first day sets the tone for the Blueprint. It is led by a Digital Engagement Lead from the Apigee Customer Success team but the overall API Program vision is introduced by the Customer API Program Sponsor or Product Owner. The primary aim of the kick off is to gather the entire team and ensure alignment between all parties on the Blueprint's objectives. The kickoff meeting is delivered on-site with the entire API Program team, as face to face communication is a key success factor early-on. The session is supported by a presentation which outlines all the activities that take place during this 3 week long process.
Design, Speed and Quality
These are the 3 key topics that define the aims of the Blueprint.
Design
In the kick off presentation the API Program Sponsor introduced the long-term vision and immediate needs of the API Platform, this will also have been discussed during the review of the preparation questions prior to week 1. One of the key deliverables from the Blueprint’s is to design a solution that fits this overall vision and short-term commitment.
This will consist of
- High Level Solution Architecture
- API specifications
- Requirements in the form of User Stories
All of the above combine Apigee’s experience helping a wide variety of companies achieve success and the customers knowledge of the reality of what resources, timescales and business needs they have today.
Speed
Multi-speed IT and Time-to-Market are key aspects covered early in the Kickoff presentation. APIs belong to the realm of Systems of Engagements, they are consumed at an ever-increasing rate via apps. New apps are created all the time by growing app developer communities and API programs need to be supported via high-speed delivery mechanisms. As part of the Blueprint we review Apigee’s Accelerator Methodology which enables companies to get their API programs out to app developers and other API consumers as early as possible.
The Blueprint aims to deliver user stories for 3 Sprints with the stories in Sprint one being defined as 'Ready'. The aim at the end of Sprint one is to have code ready for Integration Testing with the view to getting the program live within 4 - 6 weeks. Moreover, the Blueprint also aims to prepare and plan for 6 Sprints i.e. 3 months of implementation, which sets the API Team in a high delivery cadence for the whole duration of the API Program.
Key deliverables that support this are
- Backlog management plan
- Building a backlog is not enough, how will it be managed and maintained?
- Iterative development approach
- All API Programs can benefit from the principals behind adopting a more iterative development approach.
- We talk to customers from right across the spectrum from highly structured, waterfall centric organisations to those that have fully adopted the agile philosophy.
- See also Agile Assurance: Advice for starting the Agile journey
- Continuous integration plan
- Agile, Test Driven Development is at the heart of the Apigee Accelerator Methodology and Continuous Integration is key to making that a practical reality.
Quality
Regular checkpoints are built-in the Blueprint schedule for efficient and quick feedback between members of the API Program team, to ensure alignment in all aspects.
Key deliverables that go on to support this in the API Program are
- Test Strategy
- Ideally based around Test Driven Development
- Deployment Strategy
- Monitoring Strategy
- Source Code Control Strategy
Blueprint Schedule
A detailed schedule for week 1 is proposed in advance to the team and while many activities and checkpoints are mandatory, the schedule has some flexibility and can focus on specific areas while reducing focus elsewhere.
The type of implementation and products in scope inevitably affect the scheduled activities as well as the required participants. The activities of week 1 are key and should be scheduled and confirmed as early as possible, especially while the team works closely together, face to face, during that time.
The overall schedule can be thought of as
- Week 0 - Prepare
- Week 1 - Discover
- Week 2 - Formulate
- Week 3 - Refine
The following diagram breaks this down further for weeks 1 - 3.
Roles
While the Kickoff is lead by an Digital Engagement Lead who manages the Blueprint, there are a number of other key participants.
- API Program Owner / Executive Sponsor
- Product Owner for APIs being prioritised
- Technical / Solution Architect for the API Platform
- API Development team responsible for building the proxies
Other roles involved and key questions for them to answer typically include:
- QA/Test Lead
- Is Test Driven Development already embedded?
- Solution Architects for target systems
- Are the proxies to be delivered a simple facade of the target systems or is there a need for extensive orchestration across multiple target systems?
- Security Architects
- How will the APIs be secured and how does this fit into wider security governance?
- Partner Liaison / Developer Evangelist
- Who will be responsible for communicating with API Consumers?
- Marketing/Branding Manager
- If a Developer Portal is being built how will this be branded?
Communication
Since most deliverables are the fruit of collaborative efforts, the kick off meeting introduces the processes and tools to be used during the Blueprint. Early adoption of these tools is critical to ensure progress on the Blueprint's shared assets and documentation.
We advocate the use of wiki based tools for documentation e.g. Confluence, integrated backlog management tools e.g. JIRA and instant messaging tools that allow both team and 1:1 communication e.g. Slack.
The use of these tools becomes even more important in weeks 2 and 3 which are typically delivered remotely.
Flexibility
The Blueprint kick off session is also the time to answer any questions the team might have at this point, and should leave enough room for those conversations to take place. Early alignment on the Blueprint's objectives is a critical success factor, and that is main goal of the kick off meeting.
There is nearly always some kind of curve ball thrown in week 1 be it related to technology, process or requirements and it's important to have the flexibility to adapt to incorporate these changes without allowing them to throw the overall Blueprint off track.
Close Out
The Blueprint is closed out in an Executive Presentation which captures the key details and outputs which merit stakeholder alignment to move forward. The other purpose is to facilitate Blueprint closure, designed as a gate that leads into subsequent Sprint phases.
The summary includes a review of key items identified and completed during the Blueprint, including
- Objectives vs. achievements
- Deliverables completed
- Key decisions and recommendations
- Highlighted risks and mitigation plan
- Final retrospective and remarks
Next Steps
A Blueprint provides a strong foundation to kick off an API Program but don't stop there. Starting development, pushing out APIs, learning from feedback and engaging API Consumers are the next steps. Don't waste this kind of exercise by filing it in a drawer, start building APIs!
