When considering a platform for building and managing abstracted APIs and services, tied to business functions, there are three important questions that the platform should help you answer:
- What have I got?
- How should I organize it?
- How do I expand and evolve it, while keeping it organized?
What have I got?
Cataloging and recording what you already have is vital to enabling movement from where you are to where you need to get to: this isn’t a greenfield development, it’s a successful business wanting to improve.
Importing your existing content is essential for understanding what you already have. The ease and flexibility of this importation into the platform is a key factor: it needs to be simple to do from a variety of sources – including home-grown solutions.
- Are standard API descriptions supported? – WSDL, Swagger, WADL, RAML, etc…
- Can existing catalogues be imported? – WSRR, CSV, Excel
- Can runtime systems be interrogated? – Kubernetes, Proxies & Gateways
It is important to avoid having a catalog and a runtime out of sync – that doesn’t mean that every detail of where a service is running needs to be in a catalog, but knowing what, how much and where is useful.
Moving from simple cataloging to managing the lifecycle of services requires that the platform is able to drive any runtime – either on-premises or in-cloud – to ensure lifecycle decisions flow automatically and seamlessly though your business.
How should I organize it?
Having a list of abstracted digital business functions and services is useful, but it’s how you group them and display them which turns a simple list into something where people can immediately find what they need. Sometimes, that information is general e.g. if it is a SOAP service or is currently in test. Other times, it’s specific to your business e.g. the organizational unit responsible, your specific business processes, or your specific classifications or glossary terms.
A platform needs to provide:
- Multiple classifications from multiple taxonomies
- Extensible custom metadata, which can be displayed clearly and flexibly
- Searching and reporting on any metadata, including custom
- The ability for different users to see thing differently – a business unit owner will require a different view from developers – but the platform should cater for both
How do I expand and evolve it and keep it organized?
So, once you have a neatly organised catalog of services supporting abstracted digital business functions – what next? You need to see which teams and departments are using what, how long it takes for ideas to become deployed as live APIs, and what is working to support business initiatives?
- Does your platform provide the lineage between business and deployed code?
- Can you see how many services support a set of APIs, which subsequently supports a business function?
- Does a platform allow you to see how governance is being covered and also highlight exceptions which require attention?
Having this information available ensures your catalog is always live, and, as the whole lifecycle is managed, it becomes the go-to place for information about your services and business functions. Being regularly used is critical to keeping it organized – no one wants to maintain something that’s rarely used – and if information is used throughout the business, owners have a vested interest in making sure it’s accurate and appropriate!
That centrality and importance also encourages everyone to use it, which in turn ensures the catalog expands and evolves with new and updated content.
So, if all this resonates, then where do you start?
What features would I want from a platform?
Clearly, to run this at scale across a large enterprise, a platform is going to be needed. What set of capabilities should you be looking for in that platform? These capabilities can be grouped into four main features:
- Holistic Service Catalog
- Full Lifecycle API Management
- Pluggable Integrations with your existing Architecture and Platforms
- Useful Tools and Content
Holistic Service Catalog
Any holistic service catalog must allow for all your current and future services to be represented – both in technical language and in business language – and as you move towards your desired state, everything needs to be versioned to ensure everyone can see the journey.
You will need to have the actual details of what is running where (endpoint management) to avoid having to interrogate many runtime systems and show how things are connected.
It must be easy to organize assets in different ways, so people have a simple way of grouping and describing services. A catalog should allow people to explore and navigate with a variety of visualisations and flows through connected services.
Full Lifecycle Management
To be a real full lifecycle management platform, the catalog assets need to be not simply a static record. When changes need to be made to the design, they should flow through implementation and into the runtime – ideally with as much automation as practical.
But to avoid drowning in the details, and for maximum speed, services should be easy to find, combine and deploy – so you can quickly try out ideas and promote them to real services (once proven).
This speed and ease could cause chaos. To prevent this, changes need to be planned and recorded. In addition, at all stages of the lifecycle the platform should be ensuring the consideration of regulation and governance, to avoid that all-too-common “governance roadblock” when things have been overlooked early on and cause problems and rework later. Going beyond consideration alone, having a platform enforce and apply security policies automatically (not just because you’ve remembered to add them) limits your risk even while rapidly “experimenting.”
Pluggable Integrations with Your Existing Architecture and Platforms
You also need to ensure that everything is connected, as the power is in everything flowing from the planning and design into the building and runtime – keeping things in sync and minimizing the effort required.
You’ll most likely require deep and seamless integration with task management systems to ensure that familiar tools are used; minimizing organizational friction. The same applies to development, build and deployment tools.
Ideally, any platform should have pluggable and flexible integrations, not only because everyone uses tools slightly differently, but to ensure new technologies can be easily harnessed… the value is in your abstracted layer of digitized business functions – not any one implementation.
Useful Tools and Content
Finally, a platform should allow you to use your own processes and language – making it intuitive for your people to pick up and use. People shouldn’t need to have lengthy training sessions before they can become productive.
It should also have great examples (such as foundation packs) to practically show how and why organizing assets makes sense, as well as it being easy to import and sort through your current assets.
To learn how the ignite platform from digitalML supports the requirements discussed in this article, visit the ignite platform page.