On the IT Problem of Grexit: A Reply

I’d like to start by thanking Louis Proyect for commenting on at least part of my new e-book Austerity, Greece’s Debt Crisis and the Theft of Democracy namely the chapter entitled “The Information Technology Problem.” His opening paragraph begins by including an aside calling Professor William Mitchell’s ideas about these problems “unrealistic.”

Professor Mitchell’s ideas on the amount of work involved in Grexit, may or may not be unrealistic, but I think it was unnecessary to say that at the beginning of the post, without also stating why Louis Proyect thinks so, or at least providing a link to one or more of his earlier posts at Naked Capitalism where he explains his reasons for thinking that.

He then follows with a characterization of my Knowledge Management (KM) background which is more or less correct, except that he mentions my publication record of 150 articles, while also commenting that the field has somehow managed to elude Columbia University where he worked until his retirement in 2012.

Well, there are a good many more articles, posts, and publications than the 150, more like five times as many. But that’s not really important, is it? What may be important is what I had to say about the IT problem.

Also, I don’t know why it is significant to say that Columbia University ignored the KM field, since prestigious old line universities often ignore fields that originate in consulting environments. But, regardless of what Columbia did or did not do, surely what I say about the IT problem in Grexit is what is significant here; not whether Columbia University ever adopted KM as a field of teaching and research, or whether I previously worked in KM before deciding since 2009, to pursue writing professionally in my first love fields of politics and economics.

Proyect next says, correctly, that I try, in my book, to reconcile his views and Bill Mitchell’s, and he speculates that” given Bill’s irascible reaction” to Proyect’s earlier post that my chapter probably irritated “the economist emeritus” much more than it does himself. Well, I don’t think Professor Mitchell is a Professor Emeritus just yet, unless I missed something. I think he’s a full professor, still very active in teaching, research, and writing.

I agree that his tone in commenting on Proyect’s earlier posts was right out there. But Louis Proyect’s own tone won’t win any awards for diplomacy, either. I suggest that to have a more successful debate, it may be in order to stick to what people say about the IT problems in Grexit and possible solutions to them going forward, and minimize claims of greater or lesser authority to buttress one’s views.

Let the views stand by themselves. If someone’s greater authority or superior experience is relevant to the argument, then it will show itself in the substance of the argument for or against a particular solution. And, if it doesn’t, then the authority is not relevant anyway.

Louis then refers to my pointing out Bill Mitchell’s second post of July 24, and the points made there by a friend of Bill’s working in the area “of delivering innovative card payment services to banks and corporations throughout the Eurozone” in support of Bill’s views on the severity of the IT problems.

The friend confided to him that since “the Euro was integrated ‘on-top’ of the existing legacy IT payment systems”, ‘switching’ the Drachma back on would not be such a major task.” He added: the Grexit should be accomplished by stealth. He would leave everything in place as it is for now. Then establish, in secret, a public bank (like the German KfW), procure the banking software out-of-the-box, sign a contract with a major card-scheme to use its network for transactions and hook the bank up with the official Bank of Greece, the nation’s central bank.

I wonder if this plagiarized or at least conveyed the madcap spirit of Varoufakis’s “Plan B”. If they ever made a movie about such a scheme, I’d cast Steve Carell in the leading role (only because Peter Sellers is dead.)

My reaction to the advice from Bill’s friend, was that perhaps he was right, but perhaps not, and that the exposition of the idea was too brief for me to evaluate, and needed a thorough vetting. I think the comments about “plagiarism” and “madcap schemes” were just pejorative labeling by Proyect, rather than arguments to be taken seriously.

I also did not comment on the specifics of the “Plan B” Varoufakis has talked about in my chapter, except to say a few words about Jamie Galbraith’s remarks on it during the panel discussion which is the main subject of my e-book. I also never implied that I agreed with either Bill or his friend about these specifics. But my own suggestions about what perhaps should be considered as solutions worth studying, are about touching the current mainframe application only peripherally, and not getting into re-engineering the system supporting transactions until after the introduction of an electronic currency whose value would be driven by taxes and other government functions for which payments in new Drachma, or Greek euros would be required. Louis Proyect next says:

In terms of the Euro being integrated on top of the legacy systems, I have no way of assessing this. As someone who has taken part in at least a dozen feasibility studies over the years, I have learned that it is best to be cautious. Apparently the higher up you are in the IT food chain, the easier it is to throw caution to the wind.

I was cautious in my book, however, only suggesting some alternative ideas to be studied and evaluated. To evaluate whether Professor Mitchell is sufficiently cautious given the gravity of the situation, please read his posts linked to above. My view is that even though he is strongly in favor of Grexit, he does have a clear recognition that the areas in which a new electronic currency would be required initially, would be limited, and would not impinge on many of the problem areas mentioned by Proyect or other posters at NC.

Louis Proyect then mentions that in the late 1990s he advised IT management at Columbia to decline purchasing a Facilities Management System from American Management Systems (AMS). And then he points to AMS’s notorious failures in large scale projects for the Defense Department and Mississippi, which caused the failure of that company in the wake of a huge jury award to the State of $474.5 million in actual and punitive damages. And he says: “You can bet that if Greece ever needed consulting help to get them back into the drachma, there would be latter-day versions of AMS knocking at its doors.”

OK. There may well be new AMSes, or Goldman Sachses knocking on Greece’s door, but what does this have to do with what I say, or what Bill Mitchell posted?

Furthermore, with all due respect to Mitchell and his friend who “delivers innovative card payment services to banks and corporations throughout the Eurozone”, there is more to IT in Greece than banking and credit card processing. Greece has hospitals, universities, wholesale and retail companies selling furniture, yogurt, olive oil, tourist accommodations, and Zeus knows what else. Many of these companies do not have in-house staffs. Getting them up and running on a drachma will not be a piece of cake—trust me on that.

Right, but Bill never says that the issues are simply banking and credit card processing! And in the solutions I proposed for consideration, I specified no requirement for these large institutions to immediately convert to new Drachma, as I explicitly point out in the book. Unless they’re paying the Government for something, they would not need new Drachma at the beginning, but could keep on using euros.

For Firestone to bridge the gap between Mitchell and myself, he invokes his own particular areas of expertise that supposedly get us closer to “it’s not rocket science”. Naturally this require some critical commentary.

I don’t think I asserted my “authority” strongly at all. I gave some background of mine, referred to my book on portals and KM to show that I’m familiar with IT issues, and then outlined an idea with references to three software companies that could perhaps help to implement the alternatives I proposed for discussion with off the shelf software very quickly. I didn’t assert that one or more of these alternatives would be successful.

My book only says that since there are big disagreements about the amount of work an immediate mainframe legacy application change sufficient to introduce a new currency would entail, it would be wise to investigate other solutions involving an immediate band-aid temporary solution, followed by a longer-term re-engineering project for the mainframe legacy application. That seems reasonable to me, why doesn’t it seem reasonable to Louis Proyect and others at NC?

Is it really the case that the only viable IT-enabled approach to Grexit is to take up to 3 years to develop a new mainframe application? Maybe so, but since that condemns Greece to much more suffering at the hands of the troika, it seems to me only prudent that people ought to be considering alternative approaches to the IT problem.

In a section titled “Web-oriented Architecture Approach to a Drachma-based Transaction System”, he advises “web-enabling a legacy system”, something that might take a “few days, if that long”.

I never advised that. I advise considering the possibility of such a solution and investigating it, and I said that if the approach was evaluated favorably and tried in the context of Grexit, it could take only a few days at most to implement it. I think advising thinking about an alternative approach is very different from “advising it”; isn’t it?

Well, gosh, why hadn’t he brought that to Varoufakis’s attention? That would have saved him from the trouble of lining up his pal at Columbia University to program a stealth-based “Plan B”. Firestone even offers up the names of some products that could be off-the-shelf solutions such as the one marketed by the slyly named http://www.kapowtech.com/ Kapow Software.

Sorry, but to tell the truth, I hadn’t even thought much about the IT problems involved in Grexit, until the debate between Louis Proyect, Yves, and Bill started in July. At that point, I started thinking about the problem, while I focused on completing my Declarations of Dependence e-book on the trade deals.

But, I didn’t think of the ideas I suggest in the book Proyect is commenting on, until after I went to Senator Sanders’s panel discussion on July 30, and decided to quickly write an e-book about it in order to get the anti-austerity perspective out there. Then I revisited the NC and billyblog posts again, and only then did I realize that I might or might not, know something that might be useful to the discussion.

As for Kapow’s name. It’s a software company. They use names they think are “innovative.” Why is that relevant except to try to marginalize my idea without actually confronting it in argument? Could it be that Louis Proyect doesn’t know anything about the areas of “wrapping” mainframe applications and web service-enabling them?

And, I’m not trying to hold myself out as an expert in the above area, either. What I know is that these things have been done by very large companies and government agencies with legacy systems, are done today, and will be done tomorrow. Mash-ups are also used routinely in web applications today. The most well-known of which is the Google maps application.

While this software no doubt works as advertised in terms of integrating different systems under a web-based front end, it has little to do with the complexities of batch processing—the meat and potatoes of all banking applications for which there is no user interface.

That’s quite true; but it is also irrelevant, because I didn’t suggest that Kapow could do anything about these complexities, only that it could help to produce a “mashup” integrative application; one of whose components would be an unchanged mainframe legacy application accepting euro inputs and producing euro outputs as it always had. Incidentally, Kapow would not be the tool that would be used to actually wrap the mainframe legacy application for the web.

That would be done by tools produced by either of the other two companies mentioned in my book. The sequence is that one of them is used for “wrapping” and web-enabling if necessary, and then Kapow or some other application is used for web service-enabling the mainframe application within the web services architecture to create the necessary mash-up application.

Next, Louis Proyect makes the one comment directly addressing the substance of one of the proposed alternatives in my book:

Kapow might be of some use to a bank officer evaluating a loan application from a nervous customer sitting opposite him or her, but it is totally irrelevant to a stream of programs run at 3am in the morning that pump out customer statements. A customer statement like the kind that you receive from your friendly banker at the end of the month with a listing of your debits and credits followed by an account total. It is exactly programs such as these that will require onerous and time-consuming attention—nothing that Kapow can address.

Do the programs take requests in euro-denominated inputs? Do they output results in euro-denominated outputs? If so, then I think, they can be “wrapped” for the web, and then web service-enabled and integrated by Kapow or another tool like it. Remember in the approach I propose investigating, not a line of mainframe application code would be changed.

Changes would be introduced only before and after mainframe processing occurs. Maybe this is not feasible, I don’t say it is. I don’t say it’s not. I only say that it is potentially very costly not to consider it, and to just pooh-pooh it out of hand, when it is clear that Louis Proyect didn’t consider alternatives like these in his earlier posts, and also, may know little about this sort of approach.

Finally, returning to Firestone’s Knowledge Management, he starts off by wisely acknowledging that “people avoided mainframe applications wherever they could, because the chances of failure were so high”. He includes himself in that group. That being said, he regards the Kapow approach as an interim solution and concludes that a “better solution” would be to develop a new system written for the mainframe from scratch “using modern programming tools and techniques”—no doubt drawn from the Knowledge Management toolbox.

The approach I’m suggesting isn’t “a Knowledge Management” approach. It’s an IT approach often used these days and for some years now. I first became aware of it in 2006. It was not entirely new then and has had nearly 10 years more to develop since. Nor is Kapow, or an application like it, necessarily part of a “KM toolbox,” though it has been used in KM projects, as well as other projects of various kinds.

Let me assure Louis Proyect, that I am not looking for further consulting work in KM, though I may do some training in introductory KM again, I suppose. Nor am I salivating over the latest tools current in KM. Actually, my approach to KM was always much more conceptual than most, as you can see from my portal book, and from other references here, here, here, and here (sorry this last one is behind a pay wall), for example.

The tools I named are not specifically KM tools. They are tools for handling specific problems in IT, such as how to make a mainframe application accessible through the internet, and to web service-enable a mainframe application so it can be integrated into a web-oriented architecture. The solutions to those problems can be used by many fields related to IT, and are not, in any way, the special property of KM.

As for my approach, it is not “the Kapow approach”. Kapow is just one tool available to implement part of it. Louis Proyect quoted the proper name for the approach above, and that is what it should be called.

All I can say is that ever since the mid 1970s, I have heard about one new technique or another that would finally make developing large-scale systems more averse to failure. They were put forward either as management, systems analysis, database or programming technologies in trade journals such as Datamation or Computerworld: . . .

And he then goes on to list a number of techniques made available since the 1970s touted as making IT projects less prone to failure. I think he’s missed a few of the more recent techniques in use today in the area of agile software techniques and the use of development frameworks, but I understand his point. I will say two things in reply.

First, the future isn’t always like the past and the techniques being used today may perhaps be more failure averse than those of the past. And, if not, then perhaps some new development is a few years away that may succeed where others have failed. One thing is certain, the risks of IT development are too high. So, people will keep looking for methodologies and techniques that reduce that risk. And after they develop them, they will market their products with plenty of hyperbole.

And second, I’m not sure what this issue has to do with my post or Bill’s. Neither of us were talking about techniques that would reduce the risk of failure in re-engineering Greece’s mainframe-based legacy system. Bill Mitchell was talking about what he views as relatively minor revisions to present systems, followed by phasing in a revised comprehensive system over time, and I was talking about an approach which contemplated hardly touching the mainframe legacy application at all in the initial phase of a gradual currency replacement process followed by re-engineering the legacy application over time as well.

Neither of us was proposing using new techniques to avoid failure in re-engineering that application to return to the Drachma. Both of us were proposing that phased approaches be considered. So, I don’t think this point of Louis Proyect’s about using new techniques to reduce the chances of failure applies to our proposals, or is relevant to the possibilities we’ve proposed.

In the course of presenting his list of techniques, Proyect makes this seemingly important point:

But in the final analysis, it is the problem of nailing down user requirements that will always bite you in the ass. Given the economic chaos in Greece, this will be a thousand times worse than the normal chaotic situation.

This would be very important if either Bill or I were contemplating immediately changing the requirements for the mainframe legacy application. But, I believe we are not, leaving such changes for the down the road project of re-engineering the legacy system. Wrapping the mainframe application to create a mashup allowing front ends to use Drachma doesn’t change the use cases of the system. Nor do the kinds of changes Bill proposes.

So, requirements analysis is not an immediate issue for us, because it’s already been done. Proyect is here projecting a problem one would have in the context of a complete re-engineering of the legacy system taking up to 3 years.

Finally, Louis Proyect quotes Tom Davenport’s recent piece on KM in the Wall Street Journal. I won’t say much about that, except that I agree with Tom Davenport that KM is gasping in some places.

I also think that KM has been declining in popularity since the dot com bubble burst 15 or so years ago. I seem to remember a KM World Conference in 2000 where Tom Davenport gave a talk about the decline of KM and the importance of focusing on “attention management,” IIRC.

KM was driven during the bubble years by a lot of VC capital going to software ventures that were using KM-related justifications for their IT applications. When that money went away, KM began to decline, especially here in the US, where consulting money was flowing from the VCs to the software companies and then to the consultants, sometimes through speakers at professional conferences, some of whom could command $20,000 for a short appearance.

I believe KM is more active and well-entrenched in Europe, the UK, India, and Australia where more academic institutions, proportionately, got involved with it, a more scholarly approach was taken to it, more good conceptualization work has been done, and less identification of KM as a set of processes with particular IT tools and techniques involved occurred. In a sound bite: KM isn’t about IT, it’s about enhancing knowledge processing to improve its quality and the quality of knowledge outcomes in collectives and individuals.

IT is involved in KM, of course, as it is in most sub-disciplines of management these days. But, from a KM point of view, IT tools and projects are used along with other techniques and methods by KM initiatives to accomplish improvements in problem seeking, recognition, and formulation, knowledge production, and knowledge integration in collectives. But the IT tools and techniques are not instances of KM themselves. Nor are they particularly closely associated with it, such that one or another set of IT tools may be generally associated with KM projects or initiatives.

Louis Proyect quotes Tom Davenport as asking whether KM will come back. I think the answer is to be found in the idea that KM was nothing really new in the first place, but just a name that some consultants gave to various processes constituting a pattern that people hadn’t given a name to before. Those processes are to be found in every field that teaches methodology for practicing in that field, and that also practices methodology in that field. I was doing KM in the 1960s, I just called it teaching social science methodology to y students.

KM is to be found in Quality Management under that name, and also in the field of “Collective Intelligence” under that name (compare to here), a discipline in which a lot of research has been going on in Europe and at MIT. So, I think the answer is that KM is already back using different vocabularies, and formulations which pretty much mean the same thing, as you’ll see if you follow my links.

Anyway, to end this piece now, I commented on Louis Proyect’s final paragraphs on KM here, because he included them and they were of interest to me. But I hope all my readers will recognize that his excursion into KM, and my comments on it, have very little, if anything, to do with the issue of the IT problems involved in Grexit, and whether they can be solved by considering alternative proposals that don’t involve re-engineering the mainframe legacy application before Grexit.

So, why was KM brought up as an important issue in Proyect’s post? And why was so much of the post devoted to distractions not directly confronting the ideas I put forward in my book or the points in Bill Mitchell’s posts? These are the questions readers ought to ask themselves when evaluating Louis Proyect’s latest critique.

*Update: Since I wrote this an exchange occurred in the comments on this post on the NC site between Ben Johannson and Clive that is also of great interest. I’ll be commenting on that dialogue in a future post.