Editor's Pick (1 - 4 of 8)
Leveraging College Interns as an Innovation Partner
Utility Game-Changers: Solar, Wind, Hydro and Fintech
Level of Resources versus Urgency of Problem
The Business of Service Management
Reinventing Electric Power Value Chain
Joseph Santamaria, CIO, PSEG
Will the Smart Meter Deliver on its Promise?
John Burke, CIO, Ambit Energy
IT Governance Built to Last: The Wisconsin Enterprise Model
David Cagigal, CIO, State of Wisconsin
The Role of CIO in the Cloud-First World
Yvonne Wassenaar, CIO, New Relic, Inc
To Optimize APIs, Loosen Up
By Bill Appleton, CEO, DreamFactory Software
Businesses today are under tremendous pressure to keep producing new mobile applications. Operationally, when a mobile application is developed, there is usually a server-side team that builds the application program interface (API) and a client-side team that builds the application. Two distinct development teams and their interaction are defined by the API interface they are building.
The interaction between these two groups takes lots of time and money while they converge on an interface. In fact, Gartner estimates that 75 percent of the cost of a mobile project is related to backend integration. This black hole of time and cost can be countered by loosely coupled API architecture that minimizes the interaction between these two teams.
At the center of this problem is the common practice of developing a new API for every new project. This approach leads to backend complexity, and over time, a company can end up with infrastructure that is not portable, scalable, reliable, or secure. I believe that companies should never develop an API for any specific application. It is a road to trouble that too many projects take.
The unfortunate side effect of the starting from scratch on APIs for each new project approach is that most mobile applications end up being tightly coupled to the API services that they use.
I believe that companies should never develop an API for any specific application
In the same manner, if your server-side team is deeply engaged with your client-side team, then they are tightly coupled as well. These two teams can end up spending lots of time playing an expensive game of API ping-pong instead of actually shipping new applications.
In software engineering, a tightly coupled design means that components tend to be interdependent. Changes in a single component can have a system wide impact, with unanticipated and undesirable effects. That is why the concept of loose coupling is incredibly important. In a loosely coupled design, components are independent, and changes in one will not affect the operation of others. This approach offers optimal flexibility and reusability when components are added, replaced, or modified.
When the concept of loose coupling is applied to building APIs, they can be used and reused in a flexible manner for general-purpose application development. The advantages are enormous. For example, developers do not need to learn a new API to develop a new application. The same APIs can be reused for many different purposes. The total number of services and endpoints is consolidated, improving security. Documentation, user roles, and API services become standardized, enhancing corporate governance and compliance.
The server-side team focuses on mobilizing data sources, connecting legacy services, and administering role based security for the platform. The front-end team then builds anything they want on their platform of choice. Problems are minimized because the developers automatically receive the services that they need.
Embracing loosely coupled design is a tangible and efficient path to minimize the black hole of time and cost in development and accelerate productivity in the API economy.