Monthly Archives: October 2014

5 Key Advantages to a Lean Approach

5 Key Advantages to a Lean Approach

1. Quick Start.
2. Organically grow acceptance.
3. Focus on solving the key pain point in a key area.
4. Ability to pivot quickly.
5. Determine real gaps where effort is required and appropriate.

Quick Start

Enterprise Traditional Approach – Enterprise approach is akin to trying to boil the Atlantic Ocean, someone will get burned.
a. Big, monolithic and will die on the vine.
b. Significant budget is required.
c. Extensive planning and resource intensive.
d. Difficult to achieve buy in.
e. Large integration and high maintenance is required.

Organically Grow Acceptance

Simply put, it’s easier to get acceptance with a pilot rollout than to wait months or years to see results. Create a minimal viable product and get it in front of the user community.

Focus on Solving the Key Pain Point Area.

I cannot emphasize this enough. Words come to mind like scope creep and features creep. You must stay focused on the one or two main pain points, and then address it well. This requires a pinpoint focus. Example:
“We can’t find our data points” – focus on the solution to this, which is indexing and search. Collaboration and integration with other systems comes later.

Ability to Pivot Quickly

Within a lean approach one key advantage is the ability to pivot quickly off the feedback from the minimal viable product to better address the pain points. Let the users dictate the requirements. This is a stark contrast to trying to design a whole system in a vacuum.

Determine Real Gaps Where Effort is Required and Appropriate

This approach allows us to determine the real gaps in capabilities, or functionalities, and requirements.
It is difficult, if not impossible to know up front what the many variables that we will come across. What we think is requirements may not end up being a requirement. In other cases we’ll hone in on the areas where effort is needed, and throw away the areas of wasted efforts.

All in all this will perfectly align with a phased approach with manageable chunks of efforts. Over time you will be more successful and produce a much better product.

Solving the Problem of Finding Information Within Complex IT Environments

Solving the Key Problem

The most common pain point that I hear from other IT folks is that they find it an insurmountable manual undertaking to find the right data to do their jobs.

Most are saying:

  • I cannot find a trustworthy source of data to provide reports.
  • The data is everywhere and undocumented.
  • The data is incomplete or missing.
  • Which point of data is the golden source?
  • Is this the right version of this information?
  • I wish I could just search and find this information.

Many have tried to document their data by using spreadsheets or other formats, but this does not solve the problem. This is still a manual process.

IT workers can spend up to 40% of their time searching for the information to do their jobs. Traditional documentation methods are inefficient, incomplete, and are not up to date. It is very difficult to document vast systems and even more unlikely that documentation is kept up to date. Even in a modest environment, the sheer complexity of just a couple of databases and processes can translate to hundreds of thousands of points of data to document.

In my experience, the norm is 1 -10 million data points and in larger environments this translates to 250 million or more.

That’s a lot of undocumented data points that are not suitable for a spreadsheet. Now, let’s add the code, processes, and reports that use this data; it’s no wonder organizations are struggling with getting their arms around their data. Off course we can’t forget stored procedures, triggers, and functions on the databases themselves.

So what is the solution?

Catalog and Index it

Before we do anything, we need to take stock of what data assets we have. How can we find anything if we don’t know what’s out there? Doing so manually is not feasible. Therefore it is clear that an automated method is required here. Before you run out and try to build a tool to do this, I can tell you that you’re looking at thousands of hours of labor.

Indexing is also very important. In order to make all this documentation searchable, there needs to be a robust indexing system to allow for fast searching. Not an undertaking your typical IT shop, with all their priorities would entertain building on their own.

Search Engine

Once we catalog and index our metadata or documentation we‘ll need to expose a search engine. Preferably web based. Now we have a way to find what we are looking for, where it is and so on.

In order to accomplish cataloging, indexing, and providing a search engine, you will be looking for very specific metadata tools.

The Most Important Features you Need in the Short Term are:

  • A Metadata Repository
  • Metadata Adapters to connect to source tools that automatically index your metadata.
  • Search Engine and impact analysis via a web portal.

Some key Features for the Long Term can Include:

  • Enrichment of your documentation by creating custom fields for contributors.
  • Collaborate and assign stewards to approve or deny suggested changes with notifications.
  • Tools to organize your documentation into categories.
  • Drag and drop wizards to map the inter-relationships between the different applications.
  • Integrated business term glossary to organize it within your own taxonomy.

With the right metadata tools in place, you will solve the key problem and be well on your way.