Personas in API Management environment
Here I’m going to explain about some common personas used in the API management environment which is very essential to create a technically stable and economically viable API product.
What is a Persona in API Management context?
When it comes to API management environment, there are different user roles involving in different stages of the API Life-cycle; for example, there are API Designers who are responsible for the design of the API and there are technical writers who are responsible for writing the API documentation. These user roles are called as personas. It is very important to work these user roles collaboratively as a one team to develop a successful API product.
However, titles for these API positions are not very standardize across companies. For example, An API program manager in one company may be called as the API owner in another company or the API architect at company “B” is called the product architect at company “Z”. For that reason, the titles I am using here may not correspond to the titles in some companies. But i am pretty sure that these roles exist in every API management environment because the skills needed are common for every API Programs.
In a healthy API environment, we can divide the roles of the API team members into two categories.
- Business roles
- Technical roles
Lets look at these user roles in detail.
1. Business roles
The people who take on these roles are primarily focused on the business side of the APIs. They often have the responsibility of speaking in the customer’s voice, aligning the product with clear strategic goals (e.g, promoting new products, improving sell-through,etc.), and matching APIs with company wide Objectives and Key Results (OKR). Sometimes the people fulfilling these roles will come from the business or product parts of the company. Below mentioned are some major business roles.
API Product Manager
The product manager (PM)-sometimes called the product owner-is the main point of contact for the API. API product managers are responsible for making sure the API has clear OKRs and KPIs and that the other members of the team are in place to support the needed API pillars.The PM is also responsible for monitoring the API and shepherding it successfully through the full API life cycle. PMs are also responsible for ensuring the expected developer experience (design, on boarding, and ongoing relationship) meets the needs of the API consumers. The PM’s role is to make sure all the moving parts come together as expected
API Designer
The API designer is responsible for all aspects of the design. This includes making sure the physical interface is functional, usable, and offers a positive experience for developers. The designer also needs to make sure the API helps the team to achieve the identified business OKR . In some cases, the designer will work with the technical roles to make sure the design helps the team meet the technical KPIs, too. Often the designer is the first line of contact for API consumers and may be responsible for taking on the “voice of the consumer” when helping the team make decisions about the look and feel of the API. Finally, the designer may be called upon to make sure the overall design matches established company-wide style guidelines.
API Technical Writer
The API tech writer is responsible for writing the API documentation for all stakeholders connected with the API product. This includes not just the API consumers (e.g., the developers using the end product) but also the internal team members as well as other stakeholders from the business community (e.g., the CIO, CTO, etc.). Most tech writers will come from a technical background and have some programming experience, but this is not always the case, nor is it always required. It is important for tech writers to be effective communicators as well as effective researchers and interviewers, since they often need to under-stand the point of view of both the API providers and the API consumers. For this reason, tech writers often work closely with the API designer and product manager to make sure the documentation is accurate, up to date, and in keeping with the company’s design and style guidelines.
API Evangelist
The API evangelist is responsible for promoting and supporting the API practice and culture within the company. This is especially true in large organizations where internal users do not have easy access to the original API team that created the product. Evangelists make sure all internal developers using the API understand it and can accomplish their goals with it. Evangelists are also responsible for listening to API consumers and passing their feedback on to the rest of the product team. In some cases, evangelists may be responsible for creating samples, demos, training materials, and other support activities in order to maximize the developer experience for those using the product.
Developer Relations
The developer relations role, sometimes called the developer advocate or Dev role, is usually focused on exterious of the API (i.e., outside the company that created it). Like the API evangelists, DevRel staff are responsible for creating samples, demos, training materials, and other assets to help promote the use of the product. And like evangelists, DevRels are often the ones responsible for listening to API consumers and helping turn their feedback into fixes or features that the API team can deal with. However, unlike internal evangelists, DevRels are also often tasked with “selling” the API product to a wider audience, and as such may participate in customer onsite, pre-sales activities, and ongoing product support for key customers. Additional duties can include writing blog posts or articles on how to use the product, as well as other brand-awareness activities in order to help the team reach their stated business goals.
2. Technical Roles
The second set of roles we defined are what we call technical roles. These roles are focused on the technical details of actually implementing the API’s design, testing and deploying it, and maintaining it in a healthy, usable state throughout its active life. Typically these roles are responsible for speaking in the voice of the IT department, including advocating for safe, scalable, and secure implementations that can be properly maintained over time. Often, the technical staff are responsible for achieving important KPIS as well as helping the business staff reach their OKRs.
Lead API Engineer
The lead API engineer is the key point of contact for all the work related to the development, testing, monitoring, and deployment of the API product. This role is the technical equivalent of the product manager business role. Just as the PM is responsible for the what of the API-the design and business goals-the API lead engineer is responsible for the how of the API — the technical details of what it takes to build, deploy, and maintain the API. The lead engineer is the one with
the responsibility to coordinate the other technical members of the team.
API Architect
The API architect is responsible for the architectural design details for the API product itself as well as making sure that the API can easily interact with required system resources. It is the responsibility of the API architect to advocate for the overall software and system architecture of the entire organization. This includes supporting the security considerations, stability and reliability metrics, protocol and format selections, and other so-called nonfunctional elements that have been established for the company’s software systems.
Front-end developer
The front-end API developer (FE) is responsible for making sure the API offers a Quality consumer experience. That means helping to implement the company’s API registry, consumer portal, and any other activities related to the front-end or consumer end of the API, Similar to the designer role on the business side, the FE has the job of advocating for API consumers, but from the technical point of view.
Back-end developer
The back-end developer (BE) is responsible for the details of implementing the actual interface of the API, connecting it to any other services it needs to complete its work, and generally faithfully executing on the vision of the PM and API designer’s description of what the API should do and how it should do it. It is the responsibility of the BE to make sure the API is reliable, stable, and consistent once it is placed into production.
Test / QA Engineer
The API test/QA (quality assurance) engineer is responsible for everything related to validating the API design and testing its functionality, safety, and stability. Typically the test/QA role is charged with writing (or helping the FE/BE write) the actual tests and making sure they run effectively and efficiently. Often this testing goes beyond simple bench tests and behavior testing and includes making sure that there are tests for interoperability, scalability, security, and capacity. Making Typically this involves the use of testing frameworks and tooling selected by the test/QA community within the company
DevOps Engineer
The DevOps role is responsible for every aspect of the building and deployment of the API. This includes monitoring the API’s performance to make sure it is in line with the stated technical KPIS and is properly contributing to the business-level OKRS. This usually build scripts (or teaching others how to do this) Managing the release schedule, archiving the build artifacts, and supporting any rollbacks of broken releases, if needed. The DevOps role is also responsible for maintaining a dashboard showing real-time monitoring data as well as storing and, when needed, mining off-line API logs to aid in the review, diagnosis, and repair of any problems identified while the API is in production. Depending on the company’s production hosting options, DevOps staff will need to support several environments, including desktop, build, test, staging, and production. This may include both on-premise and cloud systems.
According to the user roles and tasks that have been identified, below are the briefing of activities of each role in API life cycle.
1. API Create stage
2. API Publish stage
3. API Maintenance stage
4. API Retire stage
I have almost defined the most common personas used in API management environment. But remember, although the roles are the same, those job titles can be different from organization to organization. If you want more information about the personas in different API Management environment, follow the references below.
- https://apifriends.com/api-management/api-management-project/
- API Management, An Architect’s Guide to Developing and Managing APIs for Your Organization by De Brajesh.
If you wish to express anything about this blog, your valuable comments are warmly welcome.!
