BIMODAL (NOT JUST AGILE) ROLES ALONG THE API PRODUCT LIFECYCLE
Why do we care about BiModal?
BiModal is a concept by Gartner that strives for the alignment of Mode 2 (experimental/Agile) roles and Mode 1 (traditional experience-based) roles. Why does it matter to you and your organization? Well, let’s take a look at the Agile Manifesto for software development:
Individuals and Interactions > Processes and Tools
Working Software > Comprehensive Documentation
Customer Collaboration > Contract Negotiation
Responding to Change > Following a Plan
The above is true; we can all agree. But we still need those things on the right side of the >’s.
The argument is that Agile doesn’t always make room for the very things that enable it. Take a past experience working in an Agile mobile app team, for example: After building a labelling system for wireframes of each mobile screen, at first no one really used the proper labels because working software > comprehensive documentation — which, to be fair, makes sense. Opening yet another spreadsheet means more manual work. But unfortunately, not using the labels caused a ton of bottlenecks later on, when copy, requirements, design, and implementation didn’t match up. So, what’s the real time suck, doing it right in the first place, or not having working software? (Shameless ignite solution: labels and requirements are baked into metadata of every design and generated directly into implementation… this is what we mean by BiModal alignment.)
Agile is Mode 2, and digital business is all about it. But for Agile to actually work, it needs automation. For that, IT needs plans, processes, and documentation (Mode 1), AKA those things above on the right.
So, you could say:
BiModal > Agile
And this is how to get there.
Why API Product Management is Your Best Bet for BiModal
Agile’s great. But it’s like cake; cake’s not really useful unless you get to eat it.
The good news is, there’s a way to do both, crank stuff out while keeping the screws bolted on. It’s called API Product Management.
Why APIs? Because all digital business (and increasingly physical — shout out to IoT) hinges on APIs. So it is critical to get your API management strategy down right, because — beyond being a monetizable end in their own right — APIs are the means to every endpoint, supporting all other components of your digital business platform. This includes your customers, devices, backend systems, development ecosystems, and intelligence (see Fig. A below). Do it right, and your APIs are giving you a view on your entire digital story, end-to-end, for every transaction, action, and ion.
Doing it right means marrying API Product Lifecycle to API Catalog of Business Capability APIs and Microservice Building Blocks. By exposing consumers to business functions, instead of your applications. So you have well-documented, domain-driven designs — think of them as capability blueprints — available to combine and wrap into API Products.
Friends, that kind of visibility and data sharing is what breaks the silos. As you mature, your BiModal heartbeat gets stronger. Your well-documented, quick-to-assemble design blueprints and your innovative API Products are building off of each other and ready for internal or external consumption. This is the Amazon story. The Netflix story, PayPal.
And so it’s no coincidence that over the past few years, the best in every field have been pouring resources into API programs and building out API channels — If APIs are the means to every end, then the API channel is the means to deliver better quality and speed to every other channel.
Why product though?
When we say every end (endpoint) at the enterprise level, that’s a tall order. The only way to handle this, especially for a large organization managing tons of domains, products, and teams, is an emphasis on product.
By managing your APIs like products, you’re able to:
- Bring individuals and interactions together WITH your processes and tools.
- Have working software AND comprehensive documentation.
- Collaborate with customers AND negotiate contracts.
- Respond to change quickly, WHILE following a plan.
- Have Agile AND Mode 1. AKA BiModal.
So let’s take a look at those BiModal roles in action.
From this point forth, we’ll cover the ignite way, but you can probably see the benefits are applicable to any API Product Management lifecycle.
BiModal Roles Along the API Product Lifecycle
As you mature, your BiModal heartbeat gets stronger. Your mode 2 is bringing new opportunities by leveraging pre-packaged business capabilities from your mode 1 design-driven artifacts and documentation. (For more on this, check this fresh-off the press report “Create Great API Designs and Documentation With Integration Across the API Life Cycle” by Forrester.)
We at digitalML have identified 8 common roles found in the majority of our enterprise customers’ API Product Lifecycles:
Key:
- PEOPLE: Within ignite, you have eight roles (not to be confused with titles!): Digital Business Executive, Digital Teams, Enterprise Architect, API Designer, Information Architect, Developer Teams, DevOps & Testing, and API Product Manager.
- PROGRAM: Four nonlinear stages: Plan / Design / Build / Run along the lifecycle. Not to be confused with a linear roadmap.
- PORTFOLIO: Five components: 1. Intelligence — your single source of truth (the ignite API Product Management Platform), 2. Customers (internal and external), 3. Ecosystems, (internal and external) 4. IT Systems, and 5. Devices. (See Gartner’s “5 components of a tech platform” graphic)
*Note that THIS IS NOT A WATERFALL LIFECYCLE. While an API Product within ignite can certainly go from Plan>Design>Build>Run, it is entirely more likely that over the span of its life, an API Product might look more like Plan>Design>Plan>Design>Build>Run>Plan>Build>Build… etc.
**Another note of mention — while in the above diagram it seems each role is only involved once along the lifecycle, in practice, many roles are involved along multiple stages of the lifecycle. The API Product Manager, for instance, might be involved along nearly every stage.
The BiModal API Product Journey
For simplicity’s sake, we’ll follow the typical journey of an API Product through the full lifecycle. When applicable, we’ll point out the moments when an API Product might jump around or revisit another stage.
This lifecycle builds on the assumption that a company is committed to reaching mature state of digital market leadership. Not sure where your organization is on a scale of digital maturity? Check back soon, as that’s a topic for a future post. Or feel free to book a call to chat with us.
PLAN
A need is discovered — Whether your Digital Teams got a great idea for a customer experience, your Digital Business Execs recently partnered to unlock a new revenue stream, or you’re moving to the cloud and making decisions on lift-and-shift, re-platform, or re-architect. From that point, any planning role might dive into the API Catalog to search, discover, and innovate. They can plug and play with existing business capability building blocks to carry out all of the functions of the service; The API Product Manager might suggest a third-party API to extend locally relevant functionality for an API Product existing across global markets.
He or she can help determine the domains involved and the product flow. This gets into Agile portfolio planning. The Enterprise Architect role will offer valuable guidance during this process to discuss what exists, works well, KPIs, and business needs, prioritizing these missing pieces by collaborating with API Product Managers to determine where to start, who to get involved, etc.
These roles will identify missing business capabilities that need to be built, which they can add to the API Wishlist. At this point, you’re getting into Agile product and team planning. Here, a Jira (or any task management system) integration can put the pieces into production immediately from ignite — no more details getting lost in emails.
Later, you’ll come back to this stage to report the expected versus actual KPIs and adjust priorities to take advantage of the next set of opportunities.
Roles Involved:
- API Product Manager — Owns and manages API Product
- Digital Team — Innovates and discovers needs among customer journey touchpoints
- Digital Business Executive — Oversees entire E2E digital story and new business initiatives
- EA — Blending point between plan and design
- DevOps — Reporting expected vs. actual KPIs
Core Processes:
Search, Discover, Educate, Communicate, Register, Innovate
Agile Portfolio Planning (Prioritize & Collaborate) Approve API, Group API Building Blocks, Organize Flow, Request Missing Capability
Agile Product and Team Planning
Reporting: Expected vs. Actual KPIs, Lower Cost and Faster Time-to-Market
DESIGN
Here your Enterprise Architect will help push the plan into design. He or she might work with the API Designer to create new API Product blueprints, or missing Business Capability APIs designed from Domain-Based Information Models the Information Architect has created. They might customize an API Product design to capture validated details from future API Development Teams (producers and consumers), such as Summary Info, Classification, Model Objects, Actions, Security, Review (See: 5-step API).
This design might go on to live in the global canonical cabinet, or maybe not. Either way, it will have discoverability for future Development Teams, who will return to the design stage to extend existing APIs from a canonical design artifact — but not to worry, changes or additions won’t affect that global information model unless the new iteration shows a great business value, in which case the canonical can be updated for existing iterations (you can view all running iterations of the artifact within ignite), and even pushed out directly into runtime.
Audit-Ready Governance
When the boxes are all checked, ignite’s Completeness Guide will show the missing pieces and suggest other Accelerators that might help to guide roles to get the API Product to completion, ensuring audit-ready governance.
Roles Involved:
- EA — helps match the design to the expression of the requirements, fills in the design constitutes
- Info Architect — ensures information models are being used consistently and effectively
- API Designer — often solutions architects and analysts, see a design through from design to build
- Development Teams — producers and consumers — as you get this right, you start opening up the possibility for on-demand prototyping digital teams
Core Processes:
Create New
Extend Existing
Contribute to Catalog
BUILD
At this stage, development teams might consume the proxy autogenerated from the API Design as is, or producers might perhaps extend it by making changes for a specific iteration or endpoint. They will review and simply click a button to generate a runtime-ready from design artifact (with documentation) to code template.
1 API Product, 99+ Endpoints
Because one API Product often needs to be built for various endpoints (1 for mobile, 1 for a Facebook integration, 1 to interact with a SOA service, 20 for different regions and applications, etc.), there is enormous value in this ability to generate hundreds (or, in the some industries, thousands) of implementations from that design. This ensures one API Product blueprint is globally accessible to all, to be discovered, reused, or extended for various uses without affecting the global information model. The result: well-documented, future-proof, any-to-any API Products.
Roles Involved:
- Development Teams
Core Processes:
From Design Artifact (with Documentation) to Code Template
Any-to-Any Service Contracts
Continuous Delivery & Integration
RUN
Two main components of runtime exist: access and execution. Access means dynamic configuration and settings in the proxy; basically, API traffic control. Execution means managed code and robust processes to ensure quality. ignite runtime allows DevOps & Testing to keep access and execution logically separate but managed and synchronised by one process.
Both components of runtime, access and execution, need to be managed and kept in synch to scale from 10’s of APIs to 1000’s + through automation in the following areas:
- Execution of artifact generation
- Configuration of Access settings from each API design
- Governance and lineage
- Future flexibility built in though decoupling implementation and design
- Changeable platforms
- Movement to new technology e.g. to microservices
- Updating processes
- Adaptability to new regulations
- Integrating disparate systems due to changing circumstances (e.g. M&A)
- Application migration
If you’re serious about operating at scale, your Development Teams are treating Run as an extension of Plan, Design, and Build, and not the other way around.
Role-Specific Interfaces for Greater Alignment
Role-specific interfaces are a must for BiModal teams to collaborate. DevOps will obviously have a more detailed dashboard of runtime, showing expected versus actual KPIs, throttling rates, API owners and consumers, which environments your API Products are being run. Wth ignite, they can also have various levels of access to a more technical workbench, should adjustments need to be made.
On the other hand, your Digital Teams, or API Product Managers might prefer simplified views that trim out the parts they won’t need, and allow them to take relevant runtime reporting back to Plan for new iterations.
Your Digital Business Executives might want a high-level view of your entire end-to-end digital story for clear roadmap initiatives reported in real-time.
Again, you can see how the Bimodal approach to API Products ensures a high rate of success as your lifecycle feeds its own alignment. As your API Catalog coverage grows, you have more pre-packaged capabilities and resources for Digital Teams to plan with. For API Designers to Design with, for Development Teams to bundle together and launch. Products launch quicker, with better reporting, for better planning, for better and better designs — and so it goes.
Roles Involved:
- Development Teams
- DevOps & Testing
- API Product Managers
- Digital Teams
Core Processes:
API Access & Management– Services need to be accessible to others (often via a proxy or gateway)
API Execution — Service code has to execute somewhere (yours or others’) & Reporting — consumer/provider, lineage, change management, iteration, optimization
Key Takeaways
The better the catalog, the better the opportunity for innovation & collaboration… soon Plan happens at a global scale.
- As you digitize more domains, more of your catalog gains coverage, and you create a platform of faster and better-aligned execution.
- Global business — the more LOBs that contribute, the more valuable your API catalog to global teams, for better alignment and brand consistency, in a feedback loop of collaboration and success.
- This catalog becomes your heartbeat and bidirectional roadmap.
Design drives build.
- Good upstream design unlocks an automated build that will align BiModal roles from the start.
- This enables everyone to do their job better — developers are grouping components rather than chasing down requirements. API Designers see their actual designs implemented, rather than putting in comprehensive documentation for nothing. EAs are seeing alignment from a canonical basis by applying domain-driven design to flexible modular architecture.
Build stage is a click.
- A design-first API catalog opens on-demand bundling for innovation and prototypes.
To scale, you’re treating Run as an extension of Plan, Design, and Build, and not the other way around.
- With only a handful of APIs, most early implementations focus on Run with manual coding and configuration to try and provide design and governance — but this is hard to scale. Change management is manual and unwieldy, and it’s hard to get the real value of cloud migration, as it only supports the “lift-and-shift approach” not “re-platform” or “re-purpose”.
- End-to-end speed is a critical success factor. The plan and design don’t really happen if you focus on the runtime only, so often the result is lots of point-to-point APIs, technical debt, and missed opportunities.
Run feeds back to Plan for cleaner data & reporting.
- Because APIs support EVERYTHING digital, you now have your full digital story, end-to-end & any-to-any. The better for proving ROI.
- Quick, clean reporting so you know what to fix or pull early.
- Accelerators = baked-in best practices.
Automation & silo-breaking visibility = speed with quality.
- Highly visible building blocks stay mapped to the model — meaning no manual work or hours spent on rebuilding existing services or regathering requirements.
- Business details live in Metadata — giving IT more awareness of the business reasons behind every decision.
- Speed (mode 2) with quality (mode 1) = BiModal.
Role-based interfaces align BiModal global teams over one source of truth.
- Each role uses a unique simplified interface that gives them more access to the business AND IT details needed, but with the complicated extraneous hidden underneath for clearer planning.
- Interested in learning more about our customized interfaces for each role? Let’s talk.
