You’re Virtually There… But Who’s Listening?
How to Evangelize Your API Program to Internal Stakeholders
Okay, you’ve written today’s most popular mobile game. Or maybe your services make your company’s online catalog work. Or your team publishes multimedia APIs used by thousands of developers on the web.
You don’t want your end users – or your customer’s users – saying “Huh???” when your service throws a bizarre exception – or doesn’t respond at all. On the flip side, you can’t afford to wait for third parties to release their APIs before you using them in your code.
So you’ve seen the light and decided to virtualize your service APIs.
As a software or testing manager, deciding you need a virtualization tool isn’t a tough decision. After all, virtualization allows you to test your apps with APIs that may be months away from being code-complete.
But many of your teams haven’t even heard of API virtualization, or they’re skeptical of its value.
How do you select the right tool and convince the rest of your organization to embrace it? How can you make sure they’re listening?
The tool: Know what you’re looking for
First, how will you pick the right virtualization tool? There are several vendors out there with widely different features.
Here are some features you’ll want to consider when comparing them:
- Web protocols – SOAP, REST, JDBC, other?
- Payloads: XML, REST, other?
- Scalability: Support for performance and load testing?
- Simulations: Support for latency simulation for 3rd party APIs?
- Lightweight: API virtualization versus server virtualization?
- Ease-of-use: Installation, setup, configuration and support?
- Training requirements: Can existing resources standup and modify an API?
- Evaluation copy of full-featured product?
- Quality and responsive support and assistance?
Make yourself a checklist, and weight those that are absolute requirements over just nice-to-haves. Now go check them out!
Start small: Setting yourself up for success
You narrowed the vendor options to a select few, evaluated and compared them, maybe even created a prototype or two. And you’ve made your choice.
First and foremost: There’s no better way to sabotage adoption of a new technology than by trying to boil the ocean with a box of matches. Don’t bite off more than you can chew or overinflate the whole team’s expectations.
In other words, start small.
Select the right pilot project
In the pilot, your goals should be to familiarize yourself with the tool, prove it works, and project how much time and effort it will save you in the future.
So don’t pick a new API that’s in development, or one with a zillion interfaces, or one that calls multiple third-party APIs. Pick one small, stable API that seldom changes.
You’ll be tempted to pick a major “pain point,” to prove that your API program can solve everything. Don’t do it! The complexity of the problem will overshadow your initial goals – familiarize, prove, project. And if it fails, due to complexity, its high visibility can doom your program’s future.
Pick the right team
You don’t always get to handpick your team. But to ensure the pilot succeeds – and your API program gets adopted – you need a small innovative app team. Select team members who are positive and imaginative, people who want new ideas to work.
Second, find a project champion. A dev manager or scrum master, who already believes in the technology and how it can benefit, is ideal. Their enthusiasm can help drive the team forward – and later can help socialize the technology across all of DevOps.
You probably know colleagues that fit the bill. Ask for them – you need their positive attitude to succeed.
Define what success means
You’ve identified the ideal API to virtualize for the pilot, and you’ve secured the team and a champion.
Next, it’s important to set specific and realistic goals for the outcome. A lot can happen during a pilot, so defining success for your project is crucial. Be specific, and don’t hesitate to state exclusions – tangent issues that can kill a pilot.
Remember, don’t try to boil the ocean. If you set the bar too high the first time, your team will roll their eyes. And if they don’t buy it from the outset, you’re in trouble.
Now, lay out your project plan or your first sprint, and go meet those goals.
Socialize what you’re doing – modestly
Don’t hide your progress along the way. You don’t have to detailed emails everyday to the whole department. But should let them know you’re doing something big – and they will benefit from it!
Tackling the skeptic
Okay, you’ve made it. You’ve reduced testing time, squelched serial development, or whatever other specific goals you set. Congratulations to your team!
Now you need the rest of DevOps to swallow it. But unless you’re a tiny shop and just know everyone’s on board, you're going to face some skeptics.
Some people are naturally open to new technology and new processes – you probably picked those for your pilot team. Others are entrenched with “the way we’ve always done things.” After all, change is hard.
So how can you counter that inertia and open their eyes?
Paint the broader picture
You sent out general updates during the pilot. It’s time to give them the bigger picture. Tell them…
- The reason, the method, and the results
- The checklist for tool selection
- What went well, and what you could do better
Focus on the positive, but don’t hide the negative – they won’t believe you if you say everything was perfect.
Use your champion wisely
You didn’t work alone in this pilot, so you shouldn’t be the only one socializing its success.
Remember, you selected your champion partially because they command respect across the teams. Use them now!
- Quote their positive remarks in your emails and slide decks.
- Encourage the champion – and the project team in general – to plug the success in status meetings and one-on-ones.
- Use any situation where you can pique the teams’ interest.
Let the numbers talk
If possible, use concrete numbers. They talk!
- Staff hours or days saved
- Time to market shortened
- Pay-as-you-go 3rd party API costs reduced
For the pilot, these may be small or non-existent. But for future rounds, calculate any savings or improvement you can.
Be prepared for questions
Unless your team is completely asleep, you should have hooked at least some of them. Be prepared for questions. Questions show interest, and answers garner more interest.
Soon almost everyone will be on board.
Broadcast success – everywhere, to every one
Others in the company like to hear good news, too – especially if it improves the bottom line. Share yours.
When you’re ready to go outside DevOps, tone down the tech talk a bit and spread the word:
Go social. Post messages or articles on SharePoint, Yammer, Jive or whatever enterprise social network you use.
Brown-bag it. Tell other development teams about the benefits you’re seeing with API virtualization. Maybe it can help them, too.
Be a speaker. Volunteer to give a short talk or slide presentation at other departments’ team meetings.
Get published. Write an article for the company e-newsletter. Remember your audience – focus on the broader benefits or API virtualization to groups besides your own.
And always be ready to answer “What’s next?”
Virtually everyone’s listening now
People like to hear about success – especially if they will benefit from it. But they’re skeptical when it comes to change, especially if they perceive a cost to it. Even in high-tech companies, developers resist doing things differently – at first. Regardless of all the benefits it can bring, API virtualization is a big change for software teams.
To overcome the status quo, you have to make them listen, by properly evangelizing your API program.
- Carefully choose your toolset vendor using the feature checklist.
- Start small! For the pilot, pick a stable API, an innovative team, and a respected champion.
- Narrowly define what constitutes “success” to keep expectations realistic.
- Socialize it across all DevOps. Talk up the benefits across all the teams… and you’ll have a chorus of volunteers for Round 2.
Finally, don’t forget the rest of the company. Sure, API virtualization benefits DevOps, but you may need to show a sponsor how the savings outweigh the costs. And remind them how your customers win, too. After all, that’s who pays the bills.
Now that everyone’s listening, your API program will have all the support it needs.
SmartBear’s ServiceV tool, part of the Ready! API Platform, lets you visualize, validate, and virtualize all the APIs you consume and provide – then perform automated functional, load and security testing on them. Try it for free and experience the boost in efficiency your DevOps team has been missing.
About the Author: Les Worley is a freelance B2B copywriter with almost 30 years of experience in commercial software development, IT and project management. He specializes in strategic B2B content for technology companies. You can reach him at Les@LesWorley.com or via his website at www.LesWorley.com