Go Digital or Die Trying
A Field Guide to Surviving the New Evolution.
The relentless change around core telecommunications businesses—including the non stop innovation around non-traditional business models such as Internet of Things, identity management, mPayments, and evolving communications technologies—will present both new challenges and growth opportunities for telecommunications companies.
What role will API’s play to expose the extensive range of network and IT assets e.g. IoT, identity management, location, number provisioning, SMS, subscriber data management to deliver these Value Added Services?
API Design is an art. The key to successful API Design are simplicity and consistency. When designing APIs, architects and developers must have design guidelines and make some important pragmatic decisions upfront. These decisions if not made upfront can make the changes to the API expensive. This session will walk you through some key elements to keep in mind when designing Restful APIs. These are some of the lessons I have personally learnt when designing APIs for real world applications.
Air NZ has been undergoing a digital transformation since the end of 2015, and one the strands has focussed on how APIs are relevant to Air NZ, and what to do about it. Mark will discuss (warts and all) Air NZ’s journey along its API strategy, including building the strategy, creating the RFP for an API Management Platform, building the business case, delivering the implementation, creating the initial APIs, and plans for the future.
Axel Grosse will discuss the challenges of deploying a mission critical API Management solution. He will illustrate his presentation with examples of Axway APAC customers, describing how they are organized to technically implement and deploy their APIs for internal and external consumption.
Machine learning is quickly becoming a common place method to handle the grey area of user requests and interaction. From messaging chat apps to even the most basic of online ordering its quickly become a way to gauge user input and attempt to not only respond with a best match response but also add the user interaction to the base pair program. In this talk we are going to look at ways that we can use machine learning to a new level and attempt to handle malformed API requests in a new way and attempt to decipher unmatchable requests in a way that will try and not only respond with a best fit response but capture the user errors for future responses.
The platform concept has garnered a great deal of attention from a number of different persepctives - both technical and business. This talk will discuss the intersection between technology platforms and business platforms and how APIs unify and bind the two concepts. In doing so, I will encourage you to think about your current business as a platform.
APIs are a new and incredibly powerful mechanism to rapidly deliver value to customers leveraging DevOps approaches and sophisticated tools. This works brilliantly in a “green-fields” development environment where you are not held back by existing technology solutions. This talk will focus on how to approach the cases where you don’t have this luxury and you need to integrate back into a legacy SOA environment. We will cover what are the most appropriate techniques and patterns for bridging the gap between and API centric approach and a legacy SOA environment based on our recent experience with a large government client.
With the emergence of cloud, mobile, social media, and IoT, Enterprise IT has never been the same. Not only are technologies such as cloud computing pushing the boundaries of the enterprise, they are also shifting the roles and perspectives of everyone in the organisation.
The financial trading world has had a long history of distributed APIs and protocols. This talk will crack open the lid on a few of these APIs and look at what properties they have allow for them to be used on systems that have sub 100 microsecond mean latency or generate in excess of 10 million messages a second. It will compare them to more contemporary HTTP/REST/JSON/XML-like solution to look at how they differ and how some of the ideas can be adapted to improve the performance and monitorablility of your own APIs.
Web APIs are relatively simple to implement, which has led to many ill-conceived APIs out in the world. Creating APIs that make developers jump for joy is a goal we should all have, and this proposal outlines a process for API development which will result in a better considered product.
New Zealand Post has been building a rich landscape of APIs over the past few years. Last year we identified the on-boarding of developers, partners and customers into our API Platform as a key pain point that needed some improvement. Up until that time, we were handling requests for access, customer data, and workflows in a very manual and inefficient manner.
Rick and Gareth have helped develop a number of Hypermedia APIs over the past 12 months for a range of companies. A number of interesting hypermedia API architectural patterns emerged along the way. This talk will distill and share these useful patterns.
APIs, or at least those that claim to follow RESTFulness, are based on an architectural style, not a standard. So, what role would aesthetics play in designing APIs? Can APIs be standardised? Can selecting a cloud service be a matter of API taste? Are there API Michelangelos and Picassos in the API world? In this talk we look at API design as a Style, considering the qualities that might make an API beautiful. And we look at some of those 1960’s Carparks of the API world.
The talk will cover the experience of implementing a Hypermedia API from a back-end and front-end perspective. Christiano and James will discuss their journey from the initial proposal to deploying to production. They will share the problems they faced and some helpful insights that they learned along the way.
Each speaker will present one of the two most popular API specification languages RAML and Swagger. We compare and contrast then do a round up of the other specifications languages and present some conclusions.
When building an API strategy, creating a capability or even just beginning an API journey one of the questions that we are often asked is “what is the point?”. This talk will focus on the process of getting to that point - the apiculate. How to define and promote a strategy and the key components and considerations involved. Based on a successful workshop it includes some helpful industry references and technology agnostic advice.
Ian has spent the past 16 years connecting things. His experience spans a mix of technical and people management roles in strategy, product R&D, project delivery, operations, and consulting – across a broad range of countries and industries. Amongst other things, he’s designed and written a mass of software, authored a few patents, and spoken at conferences in the US, Europe, and Australasia. Having moved to New Zealand 6 years ago, he’s had the pleasure of working for some of New Zealand’s biggest brands. As CTO at IntegrationWorks he is responsible for developing emerging technologies and practices into products and services, scaling talent and teams, and direct client delivery.
At Pushpay - having an API is critical to our long term go to market strategy. We push changes to production half-a-dozen times a day or more. We do this with an expanding engineering team in an industry that demands rigour and risk aversion. Join me as I talk about how we ship a feature all the way from a thought in someone’s head to running on the production servers. Sometimes, on the same day! This session will cover the tools and systems that make this possible, but more importantly the organisational culture that is the bedrock on which those systems are implemented.
Functions as a service (FaaS) is an emerging pattern to build APIs at scale. You can use various FaaS implementations such as AWS Lambda, Azure Functions, and Google Cloud Functions to build APIs ecosystem for your organisation. Stored procedures can be considered as a variation of FaaS. Developing APIs against these stored procedures is generally considered as anti-pattern. But what if you have substantial investment in stored procedures (8-12 years) and most of your business logic is embedded in stored procedures. In this talk we discuss how you can leverage existing stored procedures to create a fast-track API transformation program on top of your legacy systems. Then we discuss how you can break the spell on stored procedures by migrating business logic into a service tier - one StoreProc at a time. We will also cover Isentia’s API transformation journey, some key learnings and unavoidable mistakes.
A journey through the highs and lows of implementing a fast, scalable and complex RESTful JSON API on AWS - what worked, what didn’t and why - covering architecture, infrastructure and some unusual technologies and patterns. Since Martin Fowler’s seminal work on Microservices, this has become almost the de facto architectural style for designing and implementing nearly any application. The approach is however not without its pitfalls and we have seen a deluge of supporting technologies - some of which are fantastic while others have proven themselves to be less useful in practice. Let us take you through an account of how we built Ticketure, a complex scalable API on AWS for Area360.
Everybody is doing REST – at least everybody claims they are. But mostly web APIs are built without Hypermedia, what would allow the client to follow related resources and autonomously navigate through the API without prior implicit logic of the application. For developing enterprise application in the Java ecosystem, JAX-RS offers an easy integration of web services. This sessions shows the concept and benefits of a Hypermedia driven REST API using Siren as a Hypermedia-enabled content type and how to implement this using JavaEE 7 with JAX-RS.
Documentation is a painful yet necessary artifact of any software system. In a large microservices environment like Spotify’s, where the number of services and teams grows quickly, automation and standardization of documentation is crucial.
The Web is undergoing a fundamental change from strings and keywords to structured data and things. More than 25% of all websites already contain structured information. Initiatives such as Schema.org allow search engines to extract and understand such data, integrate it, and create knowledge graphs to improve their services.
This keynote will give you a different perspective on Web APIs and introduce you to Linked Data, JSON-LD, and Hydra. It will show you how to build Hypermedia APIs on steroids and prepare you for the next evolution of the Web.
The online world is an opportunity for us to do things differently than ever before, but we’re only now starting to see real changes in our behaviour – in how we share information, communicate, and organise and govern ourselves. Lillian will share her thoughts on the implications of this change through her experience heading up Figure.NZ, an organisation focused on creating a data democracy. She’ll talk about how it has led the team to think more about the wider context they’re operating in, how it affects what the organisation does and where it fits, and why this means the redesign of the Figure.NZ API has become a critical part for achieving their mission.
GraphQL and predecessors like Parse’s query engine brought along a paradigm shift in the way we think about data transfer between the front- and back-end of applications. We are no longer restricted by predefined data and response structures and communicating our data requirements implicitly. Instead, by declaring the graph-form of our data model, we are able to request data in it’s object form in a JSON-like syntax that shares structure between response and request. GraphQL, along with Relay, makes the development an application, multiple applications, and multiple versions of those, a breeze. No longer do we have to maintain v1, v3 and v100 or our APIs to make sure all legacy versions are supported. For those of us that are used to relational databases and RESTful APIs GraphQL can seem daunting and quite a leap from the model we are used to. The good news is that if you use any kind of ORM or defined any form of model to your data, you’re already halfway thorough to the graph! Looking at an example REST API, we’ll go through the steps of converting both the server and the client to GraphQL - understanding along the way what are the similarities and differences in application design, both on the front-end and the back-end.
MegaTrends affecting Financial Services and the Open Banking Agenda. Andrew will present how Open Data and APIs will deliver disruptive change across the banking landscape, and how incumbents and challenger banks are positioning to thrive in this radically different environment. Featuring insights into propositions from BBVA, Fidor and Mondo bank, and how UK and EU regulators are driving banks to provide open access to key services.
Auckland museum is undertaking a bold digital initiative in Future Museum, a strategic 20 year plan that will enable transformational change across the organisation and will reposition (Auckland Museum)[www.aucklandmuseum.com/collections] as a digital museum of the future. The foundational step toward Future Museum was the upgrade of the Museum’s online collections. Unbeknown to most only 10% of the Museum Collection is on display, the rest is kept safe hidden away in storerooms. Opening up collections digitally and providing an API to the raw data we are enabling a new audience and unprecedented access to a world renowned collection of cultural, scientific and archival artefacts. We have implemented both a REST API and a Linked Open Data endpoint that opens access to almost one million records. Our aim was simple, to open up everything to let everyone discover, access and use the public collections catalogue online. This is a complete shift in the traditions of the business and, the path to realise this goal has been an adventure in culture change of traditional museum ideology and methodology. I will present our journey into the depths of Linked data and reflect on both the technical and social development we have undergone to embrace this technology and to prepare ourselves for the future. See also Introducing Auckland Museum’s Collections Online 1 and Introducing Auckland Museum’s Collections Online 2