Information Management Agility is a simple concept, but a tricky one to execute. It requires foresight, sustained vision, and the willingness to learn from the lessons of the past. As any grade school teacher will tell you, “Those who cannot remember the past are condemned to repeat it.” 

One System to Solve it All? Hardly

One thing that I have learned over the past decade plus from working in Information Management is that a single monolithic system cannot effectively solve the Information and Content Management challenges of an organization over the long-term.

Initially the challenges revolved around finding and building a system that could adequately meet the requirements. If the system was successfully deployed, the eternally recurring problem of system lock-in occurred. This goes beyond vendor lock-in because many vendors and custom components are typically part in a full-scale solution.

Did you catch the word “adequately”? That was intentional. Adequate has typically been good enough when you consider how many system development efforts never come to fruition due to politics, changing priorities, poor technology and incapable implementers.

In rare cases, a system would be designed that would excel, but created a new issue, systems can quickly became become dated. As Microsoft, Apple and the web evolve their interfaces, the large, tightly integrated, “adequate” systems quickly begin to lose their luster and start to look old. Even when the system is actually perfectly fine, this perception can hurt a system in many ways.

Editor's Note: You can read more articles by Laurence, including: Managing Content Intelligently Using CMIS.

A Simple Example

Let me share a story to illustrate this issue. A long time ago in the 90s, there was a government agency that built a Case Management system, which we’ll call ROCMS (Really Old Case Management System), on top of a “leading” CMS. Even though only a fraction of the population performed their daily work using the ROCMS, everyone had to save all content into the underlying CMS.

As is frequent in all government organizations, there was a change in leadership. The new leaders saw this working, fairly successful system and wanted to modernize ROCMS. Wanting to make their mark on the agency, they brought in a competing Content Management vendor that claimed they could replicate the system out-of-the-box and provide a more modern system that could be updated more systematically.

They failed. ROCMS was left in place.

There was a second attempt a couple years later. This attempt was actually deployed, but shortly after deployment, users switched back to the original system. ROCMS, by this time, needed a lot of work. It was aging underneath the hood and needed serious work.

The new problem was that the people with the knowledge to work on ROCMS had moved-on over the previous years while the efforts to replace ROCMS, and not enhance it, were taking place.

Why did these efforts fail? Let’s take a look.

Lightening Rarely Strikes Twice

As the ROCMS example illustrates, replacing a functioning Information Management system can be quite a challenge. There are many hurdles to overcome:

  • The IT Project Death Spiral: Successful IT projects are not easy. Creating the same system twice can be very challenging. It isn’t enough for the replacement system to provide the same value as the existing system, but it must surpass it. That leads to over-reach and can be a formula for failure. As any IT project manager will tell you, biting off too much in a project is a recipe for failure.
  • Change is Bad: ROCMS worked and people knew how to use it. Convincing them that the new system is worth using can be quite a challenge. People typically have one of two feelings towards a system: trust or dislike. If they trust it, they will not want to change. If they dislike it, they are going to view any new system as just another new evil.
  • Remember the Past: Migration of information from the old system to the new. While new standards, such as CMIS, make accessing information from legacy systems much easier, there are many systems out there that will never support CMIS because the underlying technology is, for lack of a better word, ancient. The information needs to be accessible from day one in the new system, which means a migration. Migrations are great for service providers but are time-consuming and expensive for consumers.
  • Losing ROI: The new system is going to be bigger, more expensive and have to solve both existing and new problems. That hurts the ROI. What seemed like a no-brainer system investment becomes the next cancelled project when the effort runs into issues.

Facing these hurdles, many organizations take the “if it ain’t broke, don’t fix it” approach. The system slowly becomes more and more out-of-date until the prospect of just upgrading becomes more like a massive migration project.

If monolithic systems aren’t the answer, what is the answer?

Enter the Platform Approach

The storage and management of information should be a stable, established system that isn’t subjected to constant change. User interfaces and supporting processes should be specialized in order to be agile enough to evolve with changing requirements.

How do you have an “Enterprise” approach to both Content and Information Management and still remain agile enough to respond to the rapidly changing business environment? The answer can actually be pulled directly from buzzword bingo, “Best-of-Breed”.

Solidify the Platform

One of the issues faced when picking an existing platform vendor for their full suite of products is the looming 2-3 year development cycle. The latest release may be great and shiny, but don’t expect any major changes for years. Each release increases the platform’s complexity, making the time until the subsequent major release even further out.

When the focus is on the platform and not the user interfaces, this is release cycle is a good thing. The longer release cycle permits upgrades that are spread out across years and not in a constantly occurring cycle. This allows a focus on independent business solutions that are focused on the problems at hand.

Build Focused Apps

With a solid platform, business applications that focus on the unique needs of the organization can be deployed. Smaller, more focused applications can weather the evolution of the underlying Information Management platform and evolve on a separate path in their specialized area.

These products may be from smaller companies which are typically more responsive to the changing business environment. It isn’t just a vendor’s higher responsiveness to customers when they are a $50 million company as opposed to a $500 million company. A business specific product is much easier to architect, test and support.

This is not to say that smaller is always better, but that when run by a good management team, smaller companies can readily build a best-of-breed product. This nimbleness is why, after all of these years, that the better WCMS products are stand-alone products.

Let There Be Risks

Beware the Little Guy

Of course, there are risks. You never know who will acquire the smaller, independent companies. Consolidation is the rule in the long-term. They can be acquired by competitors and eliminated, by O&M money counters who will cease investing, and visionaries that want to roll the smaller vendor into their product line. The last can be beneficial if the plan works, but the first two can spell doom for clients.

The Importance of Open Standards

That is why Open Standards are such an important factor for the success of Agile Information Management. It isn’t just in the communication between systems, but includes the format of these new artifacts when they are stored. Changing applications can be daunting if the formats are changing as well.

Migrations and format changes always introduce the risk of information loss. The advantage of a stable platform is that all of the metadata and history can be kept intact and actual versions can be created of the information to offset the risks of the transformation. If the conversion fails, the untainted version is still intact.

Platforms Aren't Cheap, But They Are Manageable

On the other end, platforms aren’t inexpensive. They take a significant initial investment in time and money. These costs can be managed through the use of measured deployments and not deploying the final architecture on day one. The key is to pick a platform that allows you to grow after creating a stable baseline, increasing in capability and scalability upon demand.

Once you have that platform, you can add/link systems to the platform over time until you have a comprehensive collection of systems all working together, rapidly evolving to meet the changing needs of the Enterprise.

Is it just me, or did that platform sound little cloud-esque? 


Follow our continuing coverage of Information Management Agility including: