The Aviation API Economy
Lessons from the SWIM Masterclass, XMAN and recent launch of the IHS Jane’s 2016 award winning Laminar Data platform in March 2016, bringing operational SWIM to a wider market.
What is the Aviation API Economy and what is the role of SWIM alongside other web standards and ways of working? When a risk averse, safety critical industry meets internet speed ideas – what are the challenges and opportunities? How can the latent value within operational data be applied to new use cases? These are significant questions that merit their own discussion; however, this white paper focuses on lessons learned from real world APIs, customer feedback, Agile vs Waterfall, SWIM vs non-SWIM, and Cloud vs Edge that were shared by Snowflake Software in a seminar at the World ATM Congress, 2017.
Firstly, we will start with a definition of the API economy applied to the aviation sector:
In order to clarify this definition for the world of aviation we need to establish some sub definitions:
- Aviation Stakeholders should encompass ANSPs, Airlines, Airports, Drone Manufacturers, Weather and Surveillance Sensor/equipment manufacturers, EFB and FMS providers, AMHS switch providers, Flight Planning App providers, Legacy Aeronautical Data and Chart suppliers and many more.
- (internal) business assets covers data sources, data products, derived data products, work product, reports, algorithms, the magic spreadsheet in finance1, processing systems and other Intellectual Property (IP).
- (Web) APIs would include HTTP(S), REST, SOAP and well supported open standards for data exchange – including but NOT limited to the SWIM Yellow Profile2
- Additional Business Value such as new insight and better decisions internally as well as new external customers, market position, and associated revenue streams
- New Asset Classes is probably the most significant aspect to this definition because open standards and sophisticated data exchange and processing systems exist in the aviation industry already. New asset classes include data and derived data products, new value added web services, analytics and apps. We are specifically not interested in the existing links and data exchanges, but the new uses of existing data and the new ideas for new products and value added services that use existing assets.
Now let us consider the Value Chain from those assets through to the actual tangible benefit or exploitation – the End User (or equally End System).
Starting with the Business Assets, this can be raw data, geospatial data, data captured by sensors owned by the aviation stakeholder – on an aircraft, a satellite, or via a network of base stations. The asset could be a sophisticated Machine Learning algorithm or Artificial Intelligence (AI) – or it could be a magic spreadsheet from the finance team. These assets can be connected, managed and exposed via open standard Web APIs through a secure platform (like Laminar Data) with managed secure access and monetisation.
A crucial next step is a community of developers, from an in-house team, an external team, a start-up, an academic team or enterprising individuals (citizen integrators) within a large organisation. Supporting, building and helping this community is key to the success (and ultimate longevity) of the API venture. If the approach is a closed one, offering only very exclusive terms without a win/win, the developers will go elsewhere.
The developers will build the apps (and value added services), with creative solutions and an optimised user experience bringing their Intellectual Property (IP) and adding value to the Data Products exposed via the APIs.
The End Users (or End Systems) use the apps (and value added services) for their problem-solving capability and decision support – whatever that may be. An important point to note here is that the owner of the business asset doesn’t necessarily know the “use case”, the “User Story” or the problem solved by the app, provided it falls within the permitted safe use of the data itself.
Data Points on the Global API Economy
A few data points on APIs and New Asset Classes from Internal Assets:
Data Point 1:
Amazon started selling books, only later did Jeff Bezos realise that their internal IT platform asset was powerful enough to sell – and he mandated that all IT assets were to be exposed as APIs3. Amazon Web Services (AWS) is now the greatest source of profits for Amazon, while providing a small fraction of the overall revenue.
New Markets and New Ideas
When Snowflake Software launched the Laminar Data Platform in 2016, in particular the Hub via the internet, we exposed SWIM standard APIs and data to a new community of developers. This means SWIM standardized formats such as XML, AIXM 5.1, IWXXM 1.0 and FIXM 3.0.1, were all made accessible via a RESTful interface. If you Google search for NOTAM data feed, you’ll find our APIs.
This was new. Using a credit card to register and access surveillance, weather and aeronautical data that had been cleaned, linked together, fused and fully geo-expanded and cross referenced is a huge step forward for the aviation API economy. However, feedback from developers was mixed.
Since 2006, previous test beds with the Open Geospatial Consortium, competitions and activities via SESAR, the FAA and EUROCONTROL had been self-selecting – everyone knew that XML, WFS and other SWIM standards were “the answer” and we simply needed to work out how to operate in a SWIM environment.
Common questions received by the Support Team were:
- SOAP? Is that still used?
- XML? You’re kidding right?
- SWIM – what’s that?!
The expectation level, set by using other web APIs such as Salesforce.com, Twitter and Facebook, was that data payloads are in JSON or GeoJSON and all APIs are REST, never SOAP.
Both the challenge and the opportunity is that the adjacent industries haven’t been involved in the multi-year test beds, extensive R&D projects and the academic research that have underpinned SWIM. On one hand, this means they do not have the accumulated knowledge and stakeholder feedback from these processes. On the other hand, it also means they come with a fresh perspective that is not constrained by the assumed ways of working within aviation. they don’t have the baggage (good and bad).
Real world feedback
Since launching Laminar Data in March 2016 (an early maritime version was available in 2013) the Snowflake team has learnt a great deal about building solutions in the API economy. As a baseline, running a 24/7 DevOps team with a 99.9% SLA to manage was essential. Beyond that: who owns the value? How do we add value? How does the API need to be protected and secured (technically and commercially)?
Agile VS Waterfall – Where does it fit in the industry?
But this different view with fresh eyes goes beyond the data and how to get it. Developers in the API Economy adopt processes for software development that are different and more capable at handling uncertainty and technical risk.
Agile methodologies are not very new, but using them in an aviation project “properly” – meaningthere isn’t a formal Software Requirements Specification (SRS) approved early on that is then only changed under a strict time consuming governance process – remains rare.
Waterfall methodologies work extremely well in certain circumstances and help one side of a contract usually more than the other when things change. Waterfall is not good at adapting to changing requirements, and it gets harder as the project continues. These days, who fully defines the user interface requirements for an app up front before a line of code has been written? No one, not even waterfall proponents – “let’s use iterations, prototypes and incorporate feedback….” Well, sir, what you are doing is one step towards an Agile delivery, you just don’t know it yet.
Both methods have their positive attributes and where technical uncertainty is low, Waterfall is a great way to optimise resources (on both sides). However, if there is uncertainty, if the customer is brave enough to admit they don’t know exactly what they want, and, crucially, if there is sufficient trust in the parties’ relationship for it to work – Agile is a better way to build.
That is, while there is value in the latter, we value the items in the former more.
The World ATM Congress theme for 2017 focused on “creating the right culture”, being open to new ideas, and possibly a fresh approach. Allowing change to happen, taking the time to incorporate some Agile values while maintaining a strong safety culture is crucial in an increasingly complex environment where you don’t know all the use cases, and you don’t know all the combinations of inputs and outputs.
The changes aren’t simply technical, if governance processes demand fully documented Requirements Review, Preliminary Design Review and their CDRLs – then that’s what must be delivered. However, what does it mean to give space for failure? As an industry, are we brave enough to admit when we don’t know the requirements and that they might change?
How does Snowflake fit in to the API Economy?
Snowflake Software is an award-winning provider of cloud and on-premise software solutions for the aviation industry. Snowflake’s vision is to accelerate innovation in the aviation industry by making the world’s aviation data accessible and easy to use. The Laminar Data Platform, recipient of the 2016 IHS Jane’s ATC Innovation Award, is the world’s first commercial platform dedicated to fusing, cleaning and organizing the world’s aviation data and making it available in real time.