My understanding of innovation and standardization and how it is changing what I do.

Every once in a while, I get the feeling that the universe is whispering to me. These moments often precipitate a flourish of reading, white boarding, and contemplation. The universe was whispering to me last week as I finished listening to The Innovator’s Dilemmai. As chance would have it, I also read an opinion piece on WIRED called The Next Battleground for Open vs. Closed? Your Carii, a random GSA publication with the title Innovative Workplaces: Benefits and Best Practicesiii and a late breaking post from Gunnar Hellekson’s ‘a technology job is no excuse’ blog with the title IT as Manufacturingiv.

What is innovation? What is/are its opposite/opposites? How do they oppose each other? Do they have to oppose each other? How do they serve to define each other? Finding answers to questions does not always improve your situation, but I felt that these were worthy questions to which an organized answer would provide some clarity for me. I should point out at this point that I am writing this post to clarify my thoughts. I am not writing this with any other audience in mind. However, if you get something out of it, all the better. Also, if there is an insight, clarification, or objection that you can provide, I would love for you to help me refine my thoughts on this topic.

Heading to the dictionary, I found a concise, expected, and not very useful definition of innovation: something new. I am inclined to think of its opposite as something old, while true by definition, it is not helpful to think of it this way. While old/dated technology can be frustrating, it is more often that component that sits in the corner and leads a quiet existence of getting its job done. This does not appear to be the opposite that I seek. So maybe I am not really seeking the opposite of innovation, but the thing that opposes innovation. We generally don’t seek innovation where the current solution is getting the job done with little or no consternation. More often, my torment comes in the form of a product that fits a requirement, but not the need.

Why does this happen? Part of the reason I have observed is that we use product selection as a proxy for understanding our need. Product selection is a complex and sometimes political process that often ends in the proclamation that an organization has standardized on that product. Oh, how I hate hearing that. Especially when I feel that there is a more innovative choice out there. Wait, what? Is standardization the enemy that I seek? Surely not. I rely on standards in everything I do. But perhaps there is a dark underbelly of standardization that is worth exploring, though.

While the aforementioned readings did not focus on the role that standardization plays in the innovation life cycle, I don’t think that the topic of innovation can be wholly understood with out understanding how standardization fits into the landscape. Let me try and work through how I view the interdependence of innovation and standardization. I want to understand why I think some standards are good and some are bad. If I can do that, maybe I can also describe what I think is the right approach to balancing the unending desire to innovate with the practical need to standardize.

In my world, innovation is not a monopole. It is not something that can be optimized without regard to other constraints. Innovation runs afoul of organizational standards and causes controversy. While I firmly believe. that any organization that does not innovate will eventually fade into obscurity, I also recognize that an organization that does not define its own standards will likely collapse under its own inefficiencies.

It seems to me that innovation and standardization play their parts in turn at the expense of the other. When we embrace an innovative attitude, we are usually benefited by it on the whole. This is usually at the cost of a lot of extra effort in dealing with organization representatives as we have to map the new to the old and provide a lot of documentation to fill this requirement or that requirement. On the other hand, when we stick to the organization standards, we simplify the process but usually end up producing a solution that feels old fashioned and some place to the South of optimal.

After I read Gunnar’s blog, I was inspired to separate the broad term of standardization into two categories: practical standardization and necessary standardization. I will define practical standardization as the set of policies and procedures that are adopted by an organization to maximize measurable cost elements. Examples of this are gold standard builds, approved vendor lists, etc. These sorts of things can improve the measurable operational efficiency of an organization. I will define necessary standardization as the set of definitions and processes that must be in place for different parts of an organization to work together to achieve the corporate mission. Examples of this are standard forms, interface specification and the like. These sorts of things are essential for the operation of an organization.

In my experience, what I have called practical standardization is the largest roadblock to innovation. It is not because someone did something wrong, however. It is easy enough to put yourself in the shoes of the organizational decision maker who wants to maximize operational efficiency in the present. He can do this through enterprise purchase agreements, a single corporate standard build, and various single source technologies (hardware, OS, etc.). If this is the path taken, an innovation is almost always viewed as an upfront cost with the potential of savings (not a guarantee of savings) in the future. That’s a hard sell to an increasingly cost conscience audience.

What this leads to is an organization that becomes increasingly rigid. Who has not heard uttered, “We are a {Dell, HP, IBM, Sun, Microsoft, AIX, Solaris} shop.”? If this is truly how the organization has defined itself, the role of innovation is largely relegated to the vendors. As pointed out in the Innovator’s Dilemma, companies (the vendor in this case) do not generally introduce disruptive technologies that target their own products. (This is not strictly true as the book points out several examples where companies have done just that. The point that the author makes, however, is that experience has shown that this can only be successful if the innovators are not collocated with existing corporate units.)  As a result, the disruptive technologies that might revolutionize your shop will need to come from a vendor outside your current ecosystem.  That means new relationships, processes, training, integration costs, etc.

What is the solution to this problem? There are two front runners in my opinion. They are not mutually exclusive suggestions so a little of each may go a long way.

Select vendors whose innovation strategy drives their product strategy and not the other way around. Although I had not thought of it in these terms before, this type of relationship is a defining characteristic of the relationship between open source communities and their commercial open source vendors. The vendors don’t get to influence how a community will innovate unless they are heavily invested in that community. If they are heavily invested in that community they are in a better position to understand the force that is driving the innovation. Both work to the advantage of the ultimate customer.

The second solution is to work towards standard implementations of products instead of the product as a standard implementation. There are a number of necessary proprietary solutions out there (although I believe that number shrinks each year). Instead of mandating its use across the board, define the standard implementation of the product including points of contact for those who have successfully implemented the product. This allows for entities within the organization to identify and implement competing technologies and provide a similar definition.  This approach allows the first adopters within the organization to be recognized for their contributions to the standard implementation of product ‘X’ at the same time the rest of the organization receives the benefit of their knowledge. This will introduce new organizational challenges, particularly for government entities, as new policies will be needed to allow for the leverage of experts across organizational and project boundaries. At first, this may also seem to reduce the volume purchasing potential, but it compensates for that by introducing a more competitive environment during product selection.

What can I do? Well, for my part, I believe that I have to live something that I have believed for a long time and often repeated. Open Source is not about what you did yesterday. It’s about what you are going to do tomorrow. If this is true, I can share everything that I have learned and everything that I know how to do because my value is not tied up in the past. That being the case. I will be moving my lab notes into the public domain. These notes are my step by step guides to the integration of the technologies (almost completely open source parts) assembled during the course of my effort to build an open source based converged infrastructure. They will start showing up at shortly.

i Christensen, Clayton (2011). The Innovator’s Dilemma: The Revolutionary Book That Will Change the Way You Do Business. HarperBusiness. pp. 336. ISBN 0062060244.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s