Friday, January 11, 2008
Wanted: some systems architecture work, to pay artists fairly
One of the points often made by career coaches in information technology is to “think big.”
It used to be that career stability depended on have very specific hands-on “can do” and “job ready” skills. People who could code, test, actually implement and maintain (and be on call for) production systems were more valuable than middle managers. Particularly central to the computing culture of those days was the nightly and month-end batch cycle, with skills in basic languages (COBOL, ALC), dump analysis, databases, and especially JCL.
That became very much the mentality in the 1980s, until the picture got more complicated with corporate mergers and buyouts and data center mergers. In the 1990s, the picture became complicated with Y2K, particularly with older mainframe systems (like the life insurance industry’s CFO from the 1960s), the emergence of mini-computers (particularly because of defense applications, originally), and then user-defined computing, client server, and the Internet. After 2000 (and the economic pressures that followed 9/11 and the various scandals), many jobs were lost to offshoring. The market became unpredictable, with emphasis on in-depth expertise of many arcane skill sets, some of which would become obsolete.
The neo-hype was that visible career advancement was important. That’s even more apparent now with all the recent talk about “online reputation defense.” The changes are more cultural than legal, and have more to do with the way people (especially employers) get information, in new volumes before they digest its significance and relevance to what they already have.
One kind of job that you heard a lot about was “lead architect.” As work was offshored (and sometimes brought back, as the savings were not always what was expected), people were needed to oversee it. It was more like technical project leadership than management, and sometimes certified project leaders were in demand.
As I look around, I can see some more areas for obvious architectural synergy. For example, consider the issue of digital rights management, and how quickly music and movie companies are finding that their older notions of how to enforce copyrights and protect revenue sources just don’t work in practice, whatever the legal action they take and whatever their victories in court. Electronic Frontier Foundation has been promoting the idea of voluntary collective licensing. The white paper (from April 2004) is “A Better Way Forward: Voluntary Collective Licensing of Music File Sharing,” here. . All the work to develop DRM seems to have been a lot of barking up the wrong tree. But, sifting down through the details of the proposal, one thing comes through: the music and movie industries probably need to do a lot of work to make sure that the artists are paid properly, and automatically.
We see the same concept again with the WGA Writer’s Strike. Much of the conflict is about “royalties” for Internet redistribution of films and video, but one critical component would seem to be just to have the mechanisms in place to pay them promptly, and automatically, and reliably, with EFT deposits, according to predetermined mathematical formulas. From what I see written about these problems, it doesn’t seem that properly automated systems are in place to compensate the artists.
There is a model for this, with the payment of bloggers for ad revenue, with systems like AdSense. The same concept ought to be used in designing systems to pay musicians and writers for residuals. I just wonder if anyone has sat down and thought about putting the pieces together. They call this “systems architecture.” It’s hard to say who would write the systems like this: Google, or maybe companies like EDS, Perot, IBM, or CA. They would be a mix of mainframe, client server, with loads of XML feeds. But it’s easy to see how today’s bitter legal controversies about fair compensation can generate tomorrow’s jobs in IT.