For years, APIs and Services have been around in Enterprise Computing. In the good old middleware days, Service Oriented Architecture came into existence, and services were exposed using SOAP Web Service APIs. These APIs were mainly used to integrate applications to legacy systems and to one another.

With the advent of cloud, mobile, and the need for massive internal/external adoption of services, REST-based APIs have replaced SOAP Web services. REST APIs are HTTP-based, lighter, easier to understand, and integrate, and therefore, have become the de facto standard for creating enterprise APIs. Enterprise APIs can be internal APIs i.e. within or across LoB (Line of Business), or external APIs for partners and third-party developers.

In the past few years, enterprises, having learned from web-scale consumer APIs, realized that in order to create an ecosystem of applications around your API, it takes more than just creating an API and expecting consumers to use them. This is true for both internal and external APIs.

API Management

API management is the ability to document, publish, share, control, consume and monitor the consumption of APIs. All of this is done in a fashion that allows easy publishing and onboarding of developers using the APIs. So the question is:

If an enterprise is looking to publish internal and/or external APIs, is there a difference in managing them?

The majority of enterprises consume more internal APIs than external ones. API management is essential for both internal as well as external APIs as long as there is a need for,

• Providing easy means to manage the lifecycle of APIs (Create, Publish, Version, and Retire).
• Secure Access for protecting sensitive data that is being exposed.
• Differentiated Access while allowing the consumption of APIs among stakeholders.
• Easier onboarding of applications and developers that consume the APIs.
• Monitoring real-time access and usage trends of APIs and take actions as required by the business.

So how do you begin with API management? What we see is, depending on the maturity of the enterprise, the journey of API adoption can vary. Some enterprises with no APIs will start with internal APIs, get the ball rolling, work closely with internal stakeholders to fine-tune the APIs, and then roll it out for external consumption. On the other hand, mature enterprises may start directly with external adoption. Some may just roll out internal APIs depending on the business need.  Let’s take a look at differences in the requirements when it comes to publishing and consuming APIs,

External vs Internal APIs

	Internal APIs	External APIs
Creation of APIs	APIs are created based on custom business logic and could be auto-generated during the application development process.	APIs are tuned and designed as per the needs of the external partners and third-party developers.
API Publishing, Sharing, and Discovery	Done on an Enterprise Developer Infrastructure/Network that is accessible to all other applications within the Enterprise.	Done on an External API Portal that is accessible to External Partners and third-party developers.
Purpose of API Consumption	Increase internal app development productivity, integrate applications within and across LoB resulting in streaming business operations.	Increase partner business opportunities, create new business models, and in some cases, direct consumer integration.
API Discovery	Need to be discovered on the same developer platform used by other internal applications willing to consume the APIs.	Need a public-facing portal to discover the APIs, explore them, and sample them.
API Subscription	May not need a stringent subscription plan to consume the APIs.	Need diverse subscription PLANs for API consumers to subscribe to and then consume based on SLAs, Payment Plans, etc.
API Policing	Need to make sure access of APIs are metered, rate-limited, and accessible based on Enterprise LoB needs and access rights.	Need fine-grained API control around security, access, rate limits, SLAs, and access limits based on Partner usage models and subscription PLANs.
API Access	May or may not need special tokens or keys to access the APIs. Mainly depends on the sensitive nature of data being exposed.	Need API Keys and security tokens to access the APIs.
API Invocations	API Invocations are in very large numbers as they are consumed by the Internal Applications.	Dependent on business requirements for access to external stakeholders. May be a much smaller number for Enterprise LoB Use Cases.

Platforms that provide a unified approach to rolling out internal and/or external APIs can better facilitate enterprises willing to develop an ecosystem around their APIs. At WaveMaker, we aim to make the journey from internal to external API Publishing a seamless one. As mentioned in my earlier post, WaveMaker Studio, via API Designer feature, allows for publishing, sharing, and consuming APIs internal to the enterprise.  As these APIs become foolproof, and enterprises like to develop an ecosystem around it, they can use WaveMaker Gateway that allows for publishing, sharing, management, and consumption of APIs by external partners and third-party developers. WaveMaker Gateway provides full-fledged API management capabilities and is specifically designed, positioned, and priced for enterprises wanting to embrace and develop API Ecosystems around Partners and third-party developers. Click here for a demo of WaveMaker Gateway.

As soon as the wheels of modernization picked up speed, many new technologies filled up the IT space. Of them, Application Programming Interface or APIs emerged as a key element driving application modernization. APIs are a network of connections that allow systems, applications, and devices to talk to each other by sharing business functionalities; regardless of where it is located or what format they’re in.

With the API space evolving more rapidly than ever before, most executives now regard APIs as the lifeline of their enterprises.

In its report, ‘2019 State of API Integration Report’, Cloud Elements mention that 55% of businesses use APIs to generate revenue.

In fact, the Programmable Web directory accounts for over 22,000 public APIs now. Do you know what’s more surprising? These numbers are based on publicly available APIs and do not reflect any private or internal API growth at all, which outnumber the public total many times over.

So what’s the big deal about APIs?

The most important aspect of APIs is that they bring in standardization of interfaces in the development process. Developers get to work on structured and standardized APIs that are bound not to change their underlying behavior, irrespective of the technology or components used underneath. APIs also take care of hiding the complexity of underlying implementation, bringing in modularity and separation of concerns, which lets independent decoupled services be implemented and tested.

Consider this example - an app developer can write millions of lines of code spending a fortune to create applications with mapping capability. Or, he can import these capabilities from Google maps API, saving money and time and enjoying a faster time to market. At the same time, Google enjoys branding benefits as well as earns revenue from millions of developers using its public API.

 

The API Economy 

It is a term that describes the way APIs can positively affect an organization's profitability. In some organizations like Salesforce.com, APIs contribute to more than 50% of total revenue. There was a time when only software professionals knew about APIs. Today, C-level executives are aware of the financial impact that APIs can have, and companies are generating revenue by exposing APIs as business building blocks for third-party applications. This awareness is a result of the following trends highlighting the API economy:

• APIs as part of digital transformation strategies

Forrester predicts that, by 2020, companies will invest around $3 billion in API management.

This indicates the importance showered on API management. It highlights a very important fact that at the core of companies’ transformation strategy lies the user experience, and APIs play the meatier role of ensuring that these experiences are consistent among all the different channels of the company. The reason why APIs get the lion’s share of attention is that it enables quick deployment of apps in a repeatable way, leading to a faster pace of delivery. Additionally, APIs can reduce the cost of change and help enterprises achieve operational efficiencies.

• APIs’ role in creating business models

APIs have made integration so simple that it is no longer an obstacle or a burden to venture into new business models in partnership with others. The simpler integration enables to the creation of business models based on third-party APIs. By using 3rd party APIs for all subsidiary services like user management, logging, dashboard, deployment, etc., IT developers can focus on adding new value propositions to the existing application related to the core offering of the enterprise. The focus of development is purely on the implementation of business logic and not on spending time implementing the skeletal structure of the app.

• APIs accelerating new digital experiences

APIs make it easy to deliver extremely personalized experiences. Taking an API-driven approach to application development allows building products focused on each customer’s specific needs. In addition, API integrations ensure that all interactions run independently of devices or platforms from where the application is accessed. This keeps user experience consistent throughout their journey, enabling omnichannel strategies.

• APIs to manage cloud complexities

Apps developed using an API-driven development approach tend to be modular in nature, with every module representing a service (third-party or own). The main application itself seems to be a collection of these loosely coupled services or micro-apps. This app architecture is called microservices. This approach suits today’s enterprises having distributed hybrid cloud and multi-cloud IT infrastructures, but it is not without some challenges. The popular one is how to make all these loosely coupled services work together.

APIs play a big role in solving that complexity. Each of these micro-apps exposes standard APIs so that they can be consumed by other services, in other words, these micro apps talk to each other using APIs. One major benefit of this architecture is that each service can be scaled separately independent of the others. In traditional monolith app architecture, the entire app has to be scaled, though only a part of the app needs scaling.

How CIOs can ensure APIs add business value?

In many cases, jumping into the API ship without a proper strategy can be counter-productive. It may result in a mess, with redundancies, poor maintenance practices, and limited transparency.

To make the app development process simpler, these two things should be considered:

API Taxonomy -

Initially, APIs were considered intermediaries that integrated and exchanged data between multiple systems. Since mostly the IT department dealt with all things related to APIs, the category used to classify them was usually technical and non-intuitive. This made business stakeholders stay away from API design and prioritization.

But the picture is turning rosy now. Organizations are defining their API taxonomy in a way that can be easily understood by both business and technical users. Categorizing these APIs into those that directly serve the business and those that are technical enablers is the key to realizing the business value of APIs. A sound taxonomy can increase value realization by 25 to 50 percent.

Low-code platforms for API-driven Development -

It is necessary to list the right use cases for the APIs, based on your technology feasibility (back-end readiness, for example) and your business requirement before choosing a low-code platform. A good low-code platform enables both API publishing and consumption and has solid collaboration with the API Management platform as well. The following benefits can contribute a lot to business value:

Overcoming technical hurdles of APIs: Modern REST APIs, though simplified, are still quite technical in nature. There is still technology involved in understanding path versus query parameters, headers, auth headers, API key, etc. A smart low-code platform abstracts these complexities and provides you with a nice UI-based connector to work on.

Auto-generation of APIs - Some of the most common APIs that can be auto-generated can include the services from DB, external services, custom coded business logic, security services, etc. More advanced platforms can also APIfy the SQL queries and DB stored procedures allowing total control for the users.

Automatic conversion of SOAP to REST -  APIs these days are mostly REST-based. But there still remain legacy SOAP-based APIs that the modern low-code platform can automatically convert into REST API endpoint for the app. This auto conversion is especially imperative in an enterprise setup, where legacy baggage is stifling. The automatic availability of REST APIs is a crucial factor in modernizing legacy apps.

Ease of design, testing, and sharing in APIs - In a connected app world, it is imperative that your own app should have easy ways to create, design, and share APIs. Inbuilt tools that can design your APIs (for eg, configure path parameters vs query parameters) with ease, test them (through an integrated testing sandbox), and then publish (private, public access) are important features in any modern low-code platforms. There should also be easy integration to publish these APIs into the enterprise API management platform so that it's instantly available to the API consumers within an enterprise.

Get up, close and personal with APIs

With the proliferation of smart devices, we are heading towards a digital world where everything is connected through APIs. APIs have moved out of the technology bucket and have dived into the bigger picture of business strategy for enterprises. By choosing the right platform, organizations can unlock the true potential of APIs and accelerate their pathway to digital transformation.

Do not hesitate. Start from your employees.

The term, Enterprise Digital transformation, has been much maligned and misused by everyone from a consultant to a developer to a technology leader.  It has been used to describe anything from creating a website to incorporating data analytics to developing a social media strategy to just plain digitization of old paper records.   

However, a truly transformative enterprise digital experience can be achieved only when everyone in the organization feels the change.   In essence, enterprises should start their enterprise digital transformation process with their employees.

There are a lot of ways you can engage your employees, but make sure you have at least accomplished the following three :

• Emancipate your employees to kindle their innovation nerve, by sharing access to digital assets through APIs
• Engage your employees, to ideate, collaborate and share ideas
• Empower your employees, to give shape to their ideas through a low-code app development platform

Emancipate your employees with an API management platform

Enterprise digital assets can be anything from the list of all employees to a list of all items procured to a list of all vacation data to a list of all products that the organization sells.  Not all data will be relevant to everyone.  For instance, sharing payroll compensation data with employees will not be such a great idea.  

Sharing digital assets with external entities to promote additional revenue channel or engage customers and partners to create apps are now ubiquitous among enterprises.  Usually, the digital assets are API’fied and shared with the external entities to consume.  An API Management platform is usually deployed to API’fy the digital assets, monetize using plans, and configure security and data governance policies.  Create a set of API access plans for employees and share these APIs with the employees, through a dedicated employee API portal.  

Engage your employees with a collaboration platform

We are in a digital era and having a collaboration platform within an enterprise seems to be a no-brainer.  Still, there are many organizations out there with no platform to engage their employees.  There are many platforms like Slack, Yammer for your employees to collaborate and unleash their creativity.  

Engage your employees constantly, asking for their opinions on issues you are facing, announce new customer wins, conduct polls - make them feel interested and that they are wanted.  Listen to your employees, you will find some amazing ideas emerging from them.  These new ideas and innovations are going to take your organization to the future.  

Empower your employees with an innovation platform

So, you have unleashed the plethora of enterprise digital assets through the API management platform and started to engage your employees through a collaboration platform.  What next? What if one of your employees has a great idea that he wants to see materialize as an app?

Organizations should empower their employees with the fastest path from an idea to an app.  They should break the shackles of the employee and remove all hurdles - typically a dependency on technical skills and resources - to create and deploy an app from an idea.   This is what is called an Innovation-Ecosystem.

Invest in a low-code app development platform that encourages employees with no technical skills to get involved, create, and go live with an app.  Low-code app development platform typically works on a visual development approach with simple drag and drop of UI components, with a focus on end-user experience rather than technology.  A Low-code platform is the magic pill that is needed to harness the innovation potential within an enterprise.  In short, they are a new age Enterprise Innovation Platforms.   

Some of the world’s biggest business and technology disruptions started internally within an organization.  The most glaring example of that phenomenon is Amazon AWS, which was piloted and was used as dog-food internally within the organization before it revolutionized the world with its cloud services.  It’s sort of criminal if enterprises don’t harness the innovation potential of their employees, and the best way to enable the innovation ecosystem would be to emancipate, engage and empower your employees.  Try it out for this 2017.

As an Architect for WaveMaker, I have come across multiple IT environments.  They are getting more and more complex by the day, in spite of all advances with cloud computing and deployment options. IT Environments in large complex organizations are typically dispersed and have multiple silos as shown in the graphic below.

In addition, sub-groups typically have their own processes and technologies. This makes integration across organizations and the centralization of IT applications a big challenge.

This problem gets aggravated with each M&A activity. Acquisitions provide a great opportunity for innovation with the possibility of integrating assets of different organizations. But different technologies, systems, and processes hinder the realization of these opportunities.

Consolidation of IT for these organizations is a good position to be in as shown in the graphic below. But it is not trivial to achieve. More than the technology, managing resources, skills, and practices across organizations become bigger challenges.

Now, what if we can achieve integration of these different systems without actually consolidating IT systems?  What if different existing systems can co-exist while realizing the benefits of consolidation? How would you go about doing it?

Step 1: Ensure all systems are API-enabled

If you want to make your application future-proof, there is no other alternative other than to build APIs. How to make different types of applications API enabled, is a topic for another blog.

Let’s look at the organization now in the graphic below.

So what has changed?

Now, every system is open for communication. There may be different systems using different technologies, but they can all talk to each other with a common simple language. APIs.

As we have all the systems accessible, what next? How do we consolidate the information from here?

Step 2: Consolidate endpoints with API management

You must have looked at API management from the point of view of identity, authentication, rate limiting, throttling, metering, etc. But to make the best use of internal APIs, we need to transform them,  aggregate them, and cache them where needed.

Take an example of an application like Kayak. They aggregate APIs from multiple airlines.

• APIs have different formats, so it needs to be first transformed to Kayak format.
• Some APIs may not be available reliably, so it needs to be cached
• Other airlines may not even have APIs. In which case, Protocol/API wrappers need to be created over them.
• And these APIs must be aggregated to Kayak APIs. UI and other consumers should not call these APIs separately.

Similar is the requirement of a complex organization. Think of your large organization as vendors across multiple silos. Would you not like to manage all your vendors from a single place?

Current API Management products need to evolve to meet these challenges. API Management technologies, for most of their life, we're geared to public APIs that you wanted to monetize. They have also been priced by traffic usage. Recently many of these API Management vendors have started focusing on these internal enterprise APIs.

The graphic below shows how an API management platform is consolidated.

After the end of the second step, you are in a state where you have consolidated endpoints. A happy, future-proof state to be in. But this also means they need applications using these APIs. Not only the IT systems but multiple potential applications waiting to integrate these APIs to speed innovation to a different level.

Step 3: Enable rapid application delivery

With so much information available, you clearly can think of many more applications, than your IT can develop. Coding is time-consuming. The current trend is to go for ready-to-use components than to write them from scratch.

Going a step further, you don’t want to fall into figuring out the integration of these ready-to-use components either (boilerplate code). Developers with minimum technical/UI skills should also be able to deliver applications. But that simply increases the risk of poor quality applications.

This is where a low-code rapid application delivery platform can help you generate consistent beautiful-looking applications. Reusable widgets, styles, and templates are provided by the UI experts and other developers can simply use them with drag-drop features.

In summary, I have shown you a path to consolidate all your silos via APIs, manage them using an API management tool, and finally build innovative apps much more rapidly.