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.

• 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.

• 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.

What could your organization accomplish with 8folios?

Here are two simple considerations to be effective with API's:

1. Understand the need. If we build it, will they come?

• What will the API do? What capability will the API provide? Is it aligned to demonstrated need?
• What data will the API ingest or provide?
• What existing integrations (API, batch, service, or other) provide a similar capability?
• Do current or future versions of the API provide an equivalent capability such that applications or integrations can transition to the API?

Question the value of the API if it will duplicate existing integrations and there is no viable path to consolidation.

2. Provide a plan.

• Publish versions and end dates. Provide stability and consistency.
• Know who is consuming which versions. Communicate and coordinate lifecycles and change.

You will need this information:

• A Where Used blueprint - not just for the API, but to understand the larger landscape of existing integrations and opportunities.
• Awareness of data, which is ideally integrated with the Where Used blueprint.
• Comprehensive IT Roadmaps.

Are you ready for a pragmatic approach?

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:

1. 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.
2. 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.
3. 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:

• Business analysis or detailed design. What data is involved?
• Compliance. SOX 404 and documenting lineage in the USA? HIPAA in the USA? APPs in Australia? PIPEDA in Canada? GDPR in the EU?
• Diagnosing a problem. Where is data changed? Lineage?
• Security. Risk assessments. Tracking sensitive data and unencrypted risks.
• Staffing. Onboarding of new resources.
• Standards. Vocabulary.
• Transformation. Digital? Microservices? They all need data.

Is it time for your IT organization to have a pragmatic and sustainable approach to data management?

Think about the IT Roadmaps for your organization. Can you answer yes to the following?

• Our roadmaps are comprehensive, accurate, up to date, and useful.
• Every thing with a life cycle has a published roadmap, whether an application, integration (e.g. API), technology, or even a SSL certificate.
• Dependencies between things are identified on the roadmaps.
• The information is accessible.

If not, why?

Remember that the purpose of a roadmap is to declare intent, communicate, and mitigate the risk of misaligned dependencies.

People often lose sight of this and instead focus on creating a Rembrandt diagram with their favorite tool.

8folios offers an easy solution. Imagine having multiple teams perform these simple steps:

1. Identify things such as applications, data, integrations, technologies, and more.
2. Identify dependencies between things, which builds the Where Used map.
3. 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?

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?

Stop the corrosion.

Improve productivity. Plan effectively. Manage risks before they become issues. Achieve better results.

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.

Transformation = renovation. Blueprints are required for productive renovation activities.

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).

“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).

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.

Amazon AWS Global Infrastructure

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.

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.

The Amazon AWS GovCloud is FedRAMP authorized.