Innovation v. Sustainability
As a community of librarians and technologists, we like to talk about innovation. A lot: We like it; we support it; we do it; we reward it; we expect it; we value it; and we need it.
The obvious and crucial question to my mind is how an organization might support innovation without sacrificing sustainability, or alternatively value sustainability without hampering innovation.
This harks back to an earlier discussion at MPOW about using native XML databases as a storage back-end for XML web services - technologically, it's a trivial decision, but how many different databases are we supposed to support? The same question can be asked for programming languages, metadata schemas, operating systems, repositories, file formats, and so forth.
Here are my assumptions:
- Innovation requires flexibility and agnosticism so that developers and sysadmins can nimbly explore options without artificial limitations;
- Such flexibility and agnosticism are relatively easy to attain in development shops, but are untenable in production shops where sustainability is of the utmost concern (and a corollary: that needing to support an indefinite number of technologies and standards at any given time is not sustainable);
- Without harmony between production shops and development shops, seeing projects through their complete lifecycle becomes difficult, at best, and impossible at worst. If the development shop wants to use innovative language X for its Project Of The Month and the production shop only supports languages A, B, and C, does the dev shop need to refactor or does the prod shop need to loosen its support requirements? Alternatively, does the dev shop get fed up with the prod shop's policies and simply start housing their own production applications, despite the fact that they lack the resources to effectively manage them (per best practices)?
How then does an organization position itself both to support innovation and to ensure sustainability? Change of personnel? Policies? Procedures? Organization structure? Or is it more of a cultural shift?
It's one thing to talk innovation, but a whole 'nother to actually do it. And a third 'nother to do it in a manner that's sustainable, not to mention in accord with all the other organizational values.
Trackbacks
Use this link to trackback from your own site.
Feed
I know this post is around 6 months old, but I've recently been privy to this exact debate at work. I tend to come down on the side of sustainability over innovation.
Often times it's simply too difficult or expensive to guarantee a secure and stable production environment when there are too many variables and new technologies floating around. It's extremely difficult for sysadmins to even support the "approved" tools. For example, if developers are using MySQL and PHP and need to use the latest versions for a given "innovation", they need to go back, test, and update all their old apps on that server to ensure they don't break when the upgrade is installed.
My personal opinion is that developers must try at all costs to develop for the existing production environment. The best option is to first try to accomplish the goal using the current tools and policies that are in place. Minimizing dependencies on third-party software and a variety of programming languages is a good step. Constraints are not always bad, and can be seen as creative challenges for innovation as well.
However, I agree with you that sometimes there is no other option but to install X or upgrade Y. Communication between developers and system administrators throughout the process should identify risks, dependencies, and maintenance schedules, as well as a comprehensive argument as to why the change is necessary and why other options are unacceptable. It's the developer's job to convince everyone else, especially the biggest skeptics, that the change is worth it.
Also, I believe the problem has to do with money to some degree. We all say we want innovation, but R&D takes time and money and needs to be sanctioned by the organization on a project by project basis (unless they want to spew cash at the rate of The Pentagon). If an organization has the cash to supply development, testing, and production servers for all projects, there wouldn't have as much of a problem. The developers can do whatever they want to their development server. The testing server mimics the production server EXACTLY, so that the migration is well documented and any problems can be identified before it's made public.
I don't want to come down on either side. That's my issue. It's a difficult balance to strike.
I constantly struggled with this when I was the sysadmin at the SCC; I was responsible for making sure our developers could innovate and be creative, and also for keeping our servers updated, secure, and responsive. On one hand, to be frank, I wanted my job to be easier rather than more difficult — the more software, and the more versions of software, you have to maintain, the more complicated the task becomes.
But on the other hand, I realized that drawing arbitrary lines in the sand might stifle innovation which was crucial to the SCC. If we weren't allowed to be as flexible as we were, I sincerely doubt the digital library development at Rutgers would as far along as it is now. We really benefited from the support our directors gave us; they understood well that development shops need to be creative, that we need to innovate or stagnate, and that without agility, we would have been dead in the water.
If I were head of a library technology unit, I would find it difficult to make pronouncements on this issue. Rather, my inclination would be to handle new technologies on a case-by-case basis. Do we have the staff to handle technology X? Does X seem to be gaining traction in the library world and beyond? Are there significant resources on X (documentation, online communities, books, conferences, etc.)? As you say, resources are hard to come by, and hard choices need to be made. I'm just reluctant to say I support innovation over sustainability, or vice versa.
I think you hit the nail on the head. If there is any interest in any new technology, it should be discussed up front on a project-by-project basis so that others (especially other programmers) have a chance to comment, suggest alternatives, or poke holes in the argument. I don't think developers or managers working in a team environment should be authorized to arbitrarily decide to adopt technologies for organizational projects in the name of "innovation" if they don't pass a roundtable review and critique before any code is written.
By focusing on sustainability, I'm not saying that innovation is dead in the water. What I'm saying is that innovators need to be particularly focused on sustainability as an issue and take personal responsibility for it in their work and documentation. Innovation is rarely about the technology, though managers and administrators often tie it to all sorts of industry buzzwords. Innovation is about ideas, new ways of doing things, which need to be communicated and accepted by the community before the technical work can happen. It usually starts by identifying a problem or weakness in a given system, which almost never inherently tied to a single solution. Perhaps if we had an example, we could get into the details…