Sign In

From chaos to order: A case study on API Management

The problem:
The company expanded its products and services by acquiring another company in 2015. New API's or integrations were quickly built between the mutual portfolios of applications, and duplicated capabilities or applications were consolidated where it was easy.

Then the effort became challenging.

API's were not always used as envisioned due to misaligned upgrade plans, or a lack of capability or data provided by the API's. Awareness and communication were problematic across the consolidated IT team.

Customers were impacted when a non-versioned API was changed, but a consuming application of that API was not updated to align with the change.

They were on the fringe of "spaghetti services" (a tangled mess of various integrations).

A path forward:
In late 2016 the company realized they needed a cohesive vision and approach. They identified three states of transition.

Current. Where they are today.

Ideal. Consolidation of IT capabilities, upgrading applications where beneficial, and maximizing API utilization to avoid duplicity.

Improved. Incremental changes in 2017 and 2018, striving for Ideal in 2019.

They defined Ideal API Management as:

Understand their landscape. Be able to look for opportunities for new API's, or enhancements to existing API's to facilitate consolidation.

Avoid further duplicity. When an API goes live then it generally should replace one or more existing integrations.

N-1 versions of an API. Not N-0 since that was already problematic. Not N-2 or N-3 due to the risk and cost of simultaneously maintaining three or four versions of an API.

No outages or customer impacts due to API transitions. An API and its consumers will communicate lifecycles and mutually plan future transitions.

How 8folios is part of their path to an Ideal state:

A Where Used blueprint - not just for the API's, but to understand the larger landscape of existing applications and integrations. This makes it easier to see opportunities.

Awareness of data, which is integrated with the Where Used blueprint. This includes understanding data lineage and data sensitivity.

Coordinated IT Roadmaps. The lifecycle of each API version is published. Similarly, the lifecycle of each consuming application or integration is published. It is easy to see the disconnects regarding transitions, and force conversations across the IT teams.

Data Management

Data Management. Data Governance. Master Data Management (MDM). There have been many names over the years.

A Data Management program starts with great fanfare and sometimes grandiose statements. A group of people focus on discovery and documenting data in the organization.

Then the program usually stagnates. A small team is expected to maintain the blueprints. Changes may not be communicated to that team. Worse, the organization may not have access to the information such that there is limited value from the program.

Why?

Think about a workable approach that provides ongoing value across the organization.

First, confirm the desired outcomes (ie., begin with the end in mind). Examples:

Identification of logical entities and attributes, including a common vocabulary across the organization.

Classification of sensitive data such as PCI, PHI, or PII.

Identification of where data resides (at rest).

Identification of where data is used (in transit).

Identification of the lifecycle of data (lineage).

Identification of whether data is encrypted at rest or in transit.

Cross-team maintenance of this information.

Cross-team access to this information.

Second, implement a sustainable approach:

Identification of logical entities and attributes. Start with data that has the highest value to the business. Identify perhaps five to 10 entities (e.g. Customer, Financial Transaction, Order, Product) and the key attributes.

Allow others to associate these entities and attributes to applications, integrations (e.g. API's), or repositories. This includes identifying the use of sensitive data.

Review, enhance, and grow the information. Add more things to build out the Where Used of the organization.

In Step #1 don't boil the ocean by attempting to blueprint hundreds or thousands of physical entities. It's a common mistake and provides limited value. If needed, have the organization selectively blueprint physical entities after important logical entities are blueprinted, reviewed, and in use.

Step #2 has significant value since it allows people to directly contribute their knowledge. This includes ongoing changes in the IT landscape.

Finally, celebrate how the information will be used everyday across the organization:

Identify things such as applications, data, integrations, technologies, and more.

Identify dependencies between things, which builds the Where Used map.

Add the planned Retirement Date for each thing with a life cycle.

Congratulations, the organization would have created a solid draft of numerous IT Roadmaps!

Then the priceless work begins. This is where the organization uses 8folios' distinctive analytics to mine the information. This is where the organization easily identifies misaligned dependencies based on stated life cycles, and begins to discuss the feasibility of those transitions with impacted teams. This is where IT begins to see around corners and avoid the "oops" that impact the organization or customers.

You may still use the captured information in 8folios to create custom diagrams. ...but we think you'll soon realize IT Roadmap diagrams are a colossal time suck and analogous to ancient, static cartography.

Are you ready for a better approach to IT Roadmaps?

Knowledge Management

The building you work in has blueprints that document the electrical conduits, water lines, and even the sewer lines. Facilities will maintain this information so they don’t randomly tear open walls or ceilings later.

What about your IT organization? Are they “tearing open walls” looking for lost knowledge?

What was missed? How many surprises occurred this week due to a lack of awareness? Was revenue impacted? Were customers impacted?

Transformation

It has been said that data is the oxygen of transformation.
At 8folios we think data is the blood of transformation.

Data is what is created and used to support your customers and the business model.
Data is what flows through your organization and its IT platforms.

So if your organization is going to transform then it needs visibility to the lineage of its data:

Where is data created?

Where is data changed?

Where is data referenced or used?

Where is data stored?

Data lineage also includes where data intersects with the IT solutions.
These IT solutions may be applications, API's or integrations, databases, or external solutions.

We think of this collection of multi-dimensional information as Information-to-Platform blueprints.
These blueprints are not that different from the blueprints for a large building, which depict the whereabouts of things such as electrical conduits, water pipes, and sewage pipes.

What is the status of your organization's Information-to-Platform blueprints?
Do blueprints exist? Are the blueprints reasonably accurate?
Is your IT team able to use these blueprints to actively participate in transformation activities with your senior business partners?

Or will your IT team be up at the board saying, "It might flow like this..."?

Think about that for a moment.
You wouldn't expect people to renovate (ie., transform) a building without reasonably accurate blueprints.

One more thing...
Transformation won't be one and done.
Your Information-to-Platform blueprints need to be dynamic, maintainable by many people on the IT team, and accessible to many people in the organization (even your business partners).

Where Used

“All the real problems of today are multidimensional… There is no way to fully understand them - thus no way to effectively begin solving them - without at some point literally drawing them out.”
- Dan Roam, The Back of the Napkin

You can’t see it, but your IT landscape is an interconnected bundle of dependencies. Things need other things.

Moreover, there are multiple portfolios in IT and hence multiple dimensions. Examples include applications, data, integrations, servers, and technologies.

Think of a commonly-used API, application, data entity, or technology:

What does ______ need?

What needs ______?

Now think of three additional things. Then 10. Then 100.

The complexity would quickly become apparent if you were to draw out multiple things and dependencies.

What if IT had a tool to define dependencies between things and across the portfolios?

What if things and dependencies were easy to maintain, share, and search?

What if IT could easily traverse and visualize things and dependencies, and navigate through the interconnected portfolios?

What if there were distinctive analytical tools to use with this information?

Imagine how this Where Used capability would improve productivity and the delivery of IT services:

Mitigate knowledge loss.

Awareness of dependencies when making a change.

Awareness of misaligned expectations or upcoming transitions.

Input for business analysis or detailed design.

Input for project, test, or release planning.

Input for asset or vendor management.

Input for budget requests.

Input for security or risk assessments.

Production or disaster-recovery support.

8folios has this Where Used capability (even for data entities or data attributes).

Deployment Options

Which geographic region?
8folios is deployed in multiple Amazon AWS regions, and
we can quickly deploy to
other Amazon AWS regions such as Australia, Brazil,
Canada, Germany, India,
Ireland, Japan, Singapore, South Korea, UK,
or the USA (California or Ohio).

Your organization may select a region
that is closest to the majority of the users.
This improves performance since it generally
reduces network latency.
Your organization's data will reside
only in the selected Amazon AWS region.

Shared or private?
Unless specified, your organization's account
resides in a multi-tenant environment.
For paid subscriptions we offer a private
environment for an additional fee.

A private environment may be configured
without a publicly-accessible domain name,
and perhaps to only be accessible
from your organization's network or VPN.
In this scenario your organization might even define
an internal DNS entry for 8folios
(e.g. 8folios.myorg.com).

Amazon AWS GovCloud?
We offer private environments in the GovCloud
for eligible organizations.
There are no free accounts or multi-tenant environments in the GovCloud.