Businesses that have been around since before the age of digital transformation are struggling more than ever. They’re finding it harder to keep up with this era. They are becoming dinosaurs who will surely face extinction if they fail to adapt fast. In part, because they often fail to meet customer expectations. They are chained to technological or cultural legacy systems that weigh them down in their efforts to launch new products and experiences. To compete they must go back to the drawing board and adopt a new vision for IT: The application Network.
The application network is a simple concept that can deliver profound results. It is an infrastructure for information exchange in its purest form. It can be as simple as two nodes that enable two applications to share information, or it could expand across the entire enterprise as well as its external ecosystems.
The idea is to create an infrastructure that lends itself to information exchange. In other words, it makes it easy for someone in the organization to create something useful—like an application, use of data, or an API—and then expose the value in it to the network for others to use. The goal is to provide a framework that promotes agility, flexibility, and speed that businesses need to meet today’s demands. If we want it to achieve that goal, the application network must abide by the following key guiding principles:
APIs must be designed with the audience in mind. It’s about making sure the right language and terminology are used. It’s about making sure we get as much information from the end user to satisfy their needs and encourage reuse. There is no better tool than RAML to accomplish this goal as it is a great tool for API documentation and more importantly, API design.
I think of this concept as a buffet. Designed to allow consumers to get food with little interaction or support from the food providers. People can be fed much faster and efficiently. A restaurant only needs to ensure the quality of the food is great and the facilities are kept clean and the atmosphere nice.
The same concept should be applied in an application network. People need to be allowed and powered to self-serve, grab pieces of information and bits of functionality to achieve their goals. IT should only be concerned with data security, governance, and network maintenance.
It’s a common misconception to think that APIs are only relevant to external consumers but the hidden potential lies in internal consumption in the business. An application network needs to be designed with internal consumption as one of the main goals because it promotes reusability.
When APIs are designed this way, you can start to see a true application network start to emerge. This approach is called “API-led Connectivity”. It applies the principle that APIs are about connecting assets to an audience—whether it’s an internal audience like LOBs, specific departments, or external partners like clients and vendors.
Designing an application network that provides access to central enterprise data is crucial to speed up business initiatives, but that doesn’t mean that everyone should have access to every piece data. IT should have governance over all the business data.
To solve this paradox, functional and nonfunctional requirements need to be decoupled. Functional requirements describe what a particular API does. It should be defined and created by the API developer with contributions from the API owner. Non-functional requirements are typically security patterns that should be enforced when accessing that particular API in a production environment. This gives developers the freedom to create and build on existing functionality without compromising security and governance.
For example, security clearance should be granted using the MuleSoft Anypoint LDAP connector (Lightweight Directory Access Protocol) that enables users to access and maintain LDAP based systems and perform operations over an IP network.
Building an Application Network using API-led connectivity and following the guidelines mentioned above is the key to success in a highly competitive market shaped by digital transformation. This means creating APIs with reusability and internal consumption in mind. Allowing the business to self-serve technology and data, which means allowing IT to manage security and governance without being an obstacle in the development and deployment of new products and services.
Here at NEWTOMS, we focus on helping clients build or enhance their Application networks following these guidelines. We can make it possible by implementing API-Led Connectivity powered by MuleSoft
Uncover the possibilities and create opportunities for your business by having these solutions powered by MuleSoft and implemented by NEWTOMS.
Winston J Rivero Jr. graduated in two careers: Finance & Marketing from Georgia State University in 2012 – He's currently the Director of Business Development in North America and leads the Content Marketing Strategy for NEWTOMS