Transcending the Current Data Management Paradigm

The future of data management is the elimination of duplicate data.

What exactly does this mean?

Every agency uses various systems internally, all of which store client data.

It’s regularly the case that some client data stored in one system needs to be available in another system, and there may or may not be a clean way to bring this data over in an automated fashion. Even if the data can be brought over initially, what happens if the source data changes? Will the data stored in the second system automatically update, or will a human have to remember to update this data? What if you’re not dealing with two systems, but many?

Unfortunately, the larger the agency, the more systems you probably use, you probably store more client data, and any change to the storage architecture becomes increasingly painful. Also, if your data isn’t automatically updated in systems which have initially consumed your data from another system, larger problems arise such as vast data discrepancies.

Currently, the best solution to this problem is to store all of your data in one system, and connect via API to the rest. When considering all of the long term problems that can arise, along with enormous cost in the form of time involvement to migrate or manage data in multiple systems, I’m sure you can already see the value in this. Of course, the true value of the API is whether or not the consuming systems will receive updates to data when changes are made within the source system. Even if this costs you a pretty penny up front, it’s worth it.

By creating an agile data management system within your organization, you’ll be able to make changes gracefully in the future, and you’ll save your employees a ton of time and tedious work. You might even avoid a few customer service disasters that could occur if you consider the dangers of data discrepancies.

Example: You store customer information that is specific to billing within your invoicing and payment system. Customer data related to deliverables are stored in a CRM. Project milestones, tasks, and notes are stored in a Project Management system. Finally, customer support is handled in a help desk or ticket system.

While this may sound like a lot, it’s really pretty standard, and the scary part is, for many companies this can be a lot worse. There may be certain internal groups tracking particular projects or initiatives within documents that only certain individuals have access to, or there may be a number of additional systems that are more directly related to the deliverables your company produces.

The flip side of this coin is the old adage about putting all of your eggs in one basket. While today this is definitely still a valid argument, I believe the day will soon come that this concern is finally laid to rest, if you’re willing to pony up a bit of a premium cost. Depending on your internal budget, this is more or less already available. The introduction of cloud storage and data redundancy demands this day come to fruition.

Chances are, this all sounds good, but your company just isn’t ready for this change, or doesn’t have the ability to make this change for one reason or another.

Consider improvements you can identify and take action on now, such as those which are easy to see the value of, or very easy to implement. Also, search for data that is heavily duplicated. Chances are, you won’t have the ability to have information in one system automatically update when changed in the source system now, so also search for data that rarely changes.

Search for developers experienced with the API for your most popular system which you could see acting as the main data source. Also, stay on the lookout for services such as Zapier which is taking huge strides in this direction.

Applying this solution to WordPress is the true nature of this idea.

We’ve all seen the WordPress plugins which add a ticket system, or a CRM, or a project management system to WordPress. The problem is that the level of support for these plugins is no comparison to competing applications outside of WordPress, at least for the time being.

The company who realizes the value of this solution, who can create and support the framework to run a culmination of these services within WordPress, and do so in a way that can truly rival awesome products like Zendesk, Teamwork, etc. will be wildly successful and their product will transcend the current data management paradigm.

Plugin Advancements

Features as Plugins Model

The features as plugins model allows the code for a given feature to be kept in it’s own ecosystem.

This mindset is great, however, at the point that a “feature as a plugin” is moved into WordPress Core, it instantly loses many of the benefits of the feature being a plugin.

From a development standpoint, progressing the features of a plugin should move faster than progressing the features in the WordPress Core code.

Also, end users may lose the ability to turn off the feature if an option isn’t added to enable or disable it. Furthermore, simply by having a plugin hanging around in the case that it’s unneeded isn’t very useful either.

If the idea is to create features as plugins, and then merge those plugins into WordPress Core, perhaps we need a second classification of plugins, which are all of the WordPress Core features, which we can install, uninstall, enable, or disable.

In this manner, the features could remain plugins, which is helpful for development. This would also provide a great set of options for optimizing installations by removing unnecessary components.

There would also be a need for identifying dependencies, as to which WordPress Core plugins/features are required for non-WordPress Core plugins to function properly. Also, displaying this information to the user so that they can install the necessary WordPress Core plugins based on these dependencies would be essential.