A trend in software development for many years now is spend less money and time in coding and testing and more upfront to define clearly what the product or service to be created actually does. If one was looking at a typical workflow of design and development steps, this would be shifting left in the workflow.
Some background in travel: Back in the 70s when I started in travel retail programming I had already been working for an airline for a few years. Most of the people I was working with also started outside the IT department. Some were gate agents or worked on the ramp, in hospitality many worked at properties. This was due to the fact there were not a lot of IT people out there to hire. Travel companies did a lot of hiring from within and had education departments to provide the IT skills. The result was 10 years down the road there were a lot of very experienced developers that also knew the business of the airline, hotel, car rental, rail and other companies pretty well. A fair amount of the product people were the same. Someone who started as a res centre agent was now defining the reservation capabilities needed to meet changing business demand.
Having this kind of shared experience between product teams and developers meant that product definition documents didn’t need to be too detailed. In fact most were fairly vague. But it worked as a product person could tell me what they wanted to see on the availability screen and I knew what they meant. I knew how everything on that screen already got there and so I knew what I had to do to add new data requests.
However, this happy arrangement didn’t last for long. As companies grew and now there were graduates to hire with IT skills from colleges, it began to fall apart. More so than the product teams, increasingly the developers didn’t understand the business. Vague product definition documents (use cases) were still the norm but developers had no idea what they meant. Years later, as development starting moving to outsourcing and offshore, this disconnect got much worse.
The result was a lot of design and redesign as acceptance testing was rejected by product teams as not what they asked for. Animosity between product and development grew and still seems fairly bad today in most companies. In developer speak we call this a context switch problem. Product owners and developers don’t speak the same language.
Product teams feel they are describing what they want clearly and developers find that does not actually tell them what they need to do. Developers, as they now do not know the business, don’t have the context to understand where the data needs to come from, what the relationships between data elements are, and many often unwritten use cases and roles that have to be followed (like when a plane crash happens, what data gets locked down). At many travel providers this ongoing issue has caused efforts to revamp the development life cycle and among several goals, attack the context switch issue. Most would have heard of moving to agile or even scaled agile (SAFe) which include efforts to shift left and use various means to touch base with product teams early and often. The goal being to find any disconnects with product earlier when they are easier and cheaper to fix.
These approaches found their way to API development with patterns like API first. Create a mock (wireframe) of what you think product wants via a set of lightweight APIs, probably with static data, to show the product team. Then iterate and build out from there. However this still is a pattern of repeatedly showing product teams some mock ups until they agree. It’s a workaround of the context switch issue, instead of asking are there ways for product teams to describe what they want that is easier for developers to work with.
There are practices and products for use case development that achieve this but it does mean a learning curve for many product teams. I know this as I led architecture teams as part of a move to SAFe and still struggled to get product teams change how they did use cases. There is another approach under development. As I mentioned in my last post, there is a new specification from OpenAPI called Arazzo. The spec defines how to describe how a series of APIs work together including the data. This will facilitate (AI based) tools that automate the workflow including code generation. What OpenTravel provides already are object (data) models that define the data with context (semantics) that is used to create the API description documents. For a single API, it’s a next step to add Arazzo.
Description documents are another, possibly large, step to the left for APIs. It’s easy to envision AI based tools that, with access to the object (data) models from OpenTravel, can know what data is available and what the semantics are. Tools that can work with a more conversational approach for product teams but producing the API description documents. I want to emphasise that point, product owners describe what they want largely as they do today. Those description document are in turn used for further automation to generate APIs and code for some mock tests.
Envision a process where product teams, with a little developer help, can iterate quickly by gradually updating their descriptions and immediately seeing what the result is. What’s being built now is the specification foundations for this between OpenAPI and OpenTravel. Tool providers are involved in the specification work while investing and updating their products to get to market as quick as they can.
Maybe we can get back to the 70s when product people and developers got along. Peace and love!