In a previous post, I explained the reasons why pure SOA, despite being a powerful architectural paradigm with many benefits, could fall short. Building on that narrative, I will provide in this post guiding principles to help you create a modern integration strategy – one that enables digital transformation, supports the API economy and is suitable for the pace of change required to build an application network.
Today’s challenges are very different from yesterday’s. If you think integration is playing the same role as it did 20 years ago, none of the following guiding principles will make sense or seem relevant. Yesterday’s challenges were about connecting and integrating different back-end applications to ensure data was synchronized amongst them. Today’s challenge is all about connecting data to an ever growing audience. It is about unleashing assets that until now were sitting in the dark corners of your organization.
Application network guiding principle 1: Design-first for reusability
In my previous blog post I gave the comparison about a band playing on a stage. The problem with that band was that they did not bother to please the audience. Crazily enough, that is how we create and expose most of our APIs! A design-first approach means we first design APIs and then, only after we’ve agreed on an initial design, we build them. This order should be the norm. This might seem surprising, but there are an enormous amount of APIs that are created not using this principle. When those APIs are created in the wrong order(not design-first), the consumers usually don’t understand them. Because they don’t understand them, they don’t use the APIs. For those who worked with WSDL and the contract-first approach, it is similar, but please bear in mind that we are talking about something much more profound and broader than just technology.
Design-first is also about talking to the audience. It is about making sure we understand their terminology, and speak with them in a language that they understand. This is important to prevent people building wrong functionality based on terms, expressions and vocabulary that are not clear between consumer and provider. For example, getting customer information is very different depending on the context of who needs customer data. This is also an on-going and interactive process. It has its own lifecycle doing modeling, validation and simulation in an continuous feedback loop. That is what we call the design lifecycle.
When the design lifecycle is good enough, we go “backward” and find a way to connect, implement and deploy the API. In this approach, we must heavily rely on an API design mechanism. In this sense, there is no better option than RAML to fulfil this need. Although there are many options available out there to document APIs most of those languages address general documentation, not design, as the main objective. At MuleSoft we truly believe that API design is a very important aspect of the total API lifecycle. Anypoint Platform provides a seamless experience for API designers to use RAML (extra Swagger support coming soon!) and make it a true blueprint for API implementation.
Application network guiding principle 2: Make it self-service
You might argue that going to an à la carte restaurant is charming and personal, but when you are talking about serving food at scale, nothing beats the concept of a self-service restaurant. It has been designed to allow food consumers to get food, with little interaction or support from the food providers. You can feed more people much faster. As a food provider, you just have to make sure you have quality ingredients and have the infrastructure and facilities to serve people properly. It is a very scalable model.
This is the concept that we should apply to integration. When developers want to access certain systems, it should be easy for them to do it. There is no reason we should force developers to talk to systems owners to understand how a particular integration works. Imagine a 21-year-old developer fresh from university who is forced to understand the data model of a legacy ERP system, using an exotic protocol. It is hard. She will need help from the ERP guru to explain what that data model actually means. We can help this young developer and make her job easier and more fun. When we create truly simple and productized REST API’s on the top of the ERP, it brings big relief to both parties. Developers can move faster, and providers don’t need to stop their daily operations to enable someone else. That is a much more scalable model.
Application network guiding principle 3: Make your enterprise composable by promoting consumption via APIs
Often people think that APIs are more relevant to external consumers. The reality is very different. The hidden potential of APIs lies in internal consumption by LoB’s, departments, and sub-organizations. There is nothing wrong with external consumption, but a big majority of your API thinking should be to drive internal consumption of APIs.
Historically, internal connectivity has been either absent or has been done suboptimally. When API’s came up on the agenda, many people rapidly understood their benefits and started to apply them to external consumption. It is the first intuitive step to take – you want to look good from the outside. However, we can do much more with APIs. What about applying all this goodness to internal connectivity challenges? It is a perfect fit and the problems you are solving are very similar.
When you think about APIs this way, you can start to see your application network emerge. We build the application network with an approach called API-led Connectivity. Remember that API-led is about connecting assets to the audience and it handles the full lifecycle of their APIs. Take a look at more resources if you are interested in this approach.
The diagram below outlines this idea. There are three important aspects in it:
- We have different API types. We call them System APIs, Process APIs and Experience APIs. Each API type carries different attributes (deployment model, SDLC, etc).
- All those APIs are designed, built, and governed from one single platform — Anypoint Platform.
- Internal connectivity challenges aren’t just solved by technology – it’s a cultural and mindset shift. Elements that are usually ignored in this regard are the people and the organization aspects. That is where accessibility and ownership comes in place and a where a federated organization is used for the enablement and the creation of self-service assets. This is the operational model and it is called C4E. Its main outcome is about shifting the role, and culture, of central IT from project delivery to a more agile enabler for the business.
Application network guiding principle 4: Unlock assets with security and governance
The ability to easily provide access to data is both exciting and scary. Obviously providing access to central enterprise data is critical to speed up business initiatives but at the same time not everybody should have access to every data. It is a bit of a paradox.
From a design perspective, developers want and should have access to data and functionality exposed via APIs. From a security and governance perspective, only certain groups can get permission to edit and manage data.
This paradox is solved with the usage of runtime policies to decouple functional and nonfunctional requirements.
Functional requirements will describe what a particular API does. It is totally defined and created by the API developer and API owner. Non-functional requirements, for example, are security patterns that should be enforced when accessing that particular API. They should not be mixed. For example: You can have an API on a test environment with no policy enforced, but when this API is promoted to production environment, an authorization via LDAP policy is required to access it.
This allows developers to create and easily build functionality on the top of existing functionality in dev and test environments. Whenever APIs are deployed to production, they should enforce the appropriate security pattern via policies. The diagram below shows some of the available policies.
Conclusion
Businesses today know that the path to succeeding in a competitive market means deploying technological solutions both efficiently and effectively, which means allowing the business to self-serve technology and allowing central IT to manage it without blocking its development and deployment. An application network makes this feasible at scale.
Discover what is possible when you have an application network powered by MuleSoft.
