Grexit: Exchanges on the IT Problem Continue

I’ve already been over Louis Proyect’s critical analysis of the chapter on the IT software problem in my new e-book. But in the comments on Proyect’s post a significant dialogue occurred between two commenters at NC: Ben Johannson and Clive. Here I analyze and comment on that exchange.

Ben Johannson’s initial comment to Proyect:

I’m reading here that Mitchell and Firestone are wrong because Bain and Google don’t do knowledge management. The rest is defensive polemics.

Apparently the higher up you are in the IT food chain, the easier it is to throw caution to the wind.

Ad hominem accusing Firestone of recklessness. I’m assuming it’s ad hominem, of course, as the other logical explanation is professional jealousy and resentment.

there is more to IT in Greece than banking and credit card processing.

strawman fallacy, as I see no evidence either Firestone or Mitchell suggested otherwise.

His tone reminded me of the one I take on issues such as when the Russian Revolution went off the rails but let’s leave that aside and move on to the substantive IT issues.

Appeal to emotion. Given you lack the mental superpower to pull another’s tone from their writing your attempt to make Firestone look silly is dismissed.

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.

How do you know they aren’t?

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”.

Your unconcealed hostility to anyone disagreeing with you makes the overall argument less than convincing.

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”. Well, gosh, why hadn’t he brought that to Varoufakis’s attention?

You mock the idea yet provide no refutation of it. Temper, sir.

And then we get the attack on Firestone’s competence and his failure to be in the popular kid’s profession, so of course he’s stupid.

Of course, I agree with Ben in his reply to Proyect!

Clive then replies to Ben:

Ben, besides the well-known fallacies — which you rely on in your critique of Louis’s evaluation of Joe’s premise (that Greece’s euro exit contains significant IT work and that need for IT development will constrain what Greece is able to achieve in the short and medium term) — one trap which is also all-too-easy to fall into (and I have to watch myself because I can end up doing it as easily as anyone) is to pick on specific wording or phrasing. Every writer outside of the narrowest academic authors has to trade readability and grammatical shorthand against long, dry, technical description of the point they are making.

JMF: ?????? Clive seems to be saying that I don’t share the view that Grexit “. . . contains significant IT work and that need for IT development will constrain what Greece is able to achieve in the short and medium term.” But plainly I do agree with that view. Is Clive sure he’s read my actual suggestion in the book chapter.

If he has, then how about a quote supporting the interpretation of it he states? If, as he claims, I am not in agreement on this point, then why does he think I suggested the two alternative possibilities for putting a band-aid on the IT problem for the short-term?

Clive continues:

You chastise Louis for saying: “Apparently the higher up you are in the IT food chain, the easier it is to throw caution to the wind.” But this is merely expressing a well-known and generally accepted phenomena which leads to project failure. It’s referred more fancily as “optimism bias”. Many authoritative pieces of research have been done on this subject (e.g. From the paper on pg. 6:


5 The tendency to be overly optimistic leads public bodies to underestimate the delivery challenges of what are often complex projects. They may have financial and timing constraints, have multiple stakeholders, be interlinked or relate to other major projects, and be dependent on organisational or citizen behavioural changes.

6 (the Uk’s National Audit Office) back catalogue shows that, in planning projects, government does not always take time to understand the complexity and, as a result, over-estimates its ability to deal with the challenges. Too often, government commits to a ‘solution’ without fully understanding the context and exploring alternative options to determine which solution matches the real need.

Being the civil service, the report is written in a guarded style and so the catch-all term “government” is used, the “government” being referred to lacks agency in that section. But if you read the whole report, the “government” is actually ministerial direction as shown later in the report where the blame for a failed project is laid fair and square with “The Department for Communities and Local Government” i.e. the minister, who “tried to centrally impose a national control system”. It is senior level decision makers who are the worst exhibitors of optimism bias.

JMF: That’s all very well, and I certainly agree, but unless Clive can quote what I said in my book and show that I’m overly optimistic, then what does this all mean? It’s just a fancy labeling exercise with no proof saying “Joe’s overly optimistic.”

Clive again:

As for “there is more to IT in Greece than banking and credit card processing”, this is a true statement. Happy to be corrected if I’m wrong, but I don’t think that factually correct statements are straw manning.

JMF: This last is in reply to the statement of Ben’s that Clive had “strawmanned” Bill Mitchell and I in a previous reply. Well, here’s Wikipedia:

A straw man is a common form of argument and is an informal fallacy based on giving the impression of refuting an opponent’s argument, while actually refuting an argument which was not advanced by that opponent.

So, yes, Ben is right and Louis was “strawmanning” both Bill Mitchell and I, since neither of us ever claimed what Clive had previously quoted, or anything even close to that.

Clive once again to Ben:

You don’t like Louis’s writing style and allegory. That’s fine, but as I said at the top, it isn’t valid to criticise a writer’s style as a substitute for criticising the substance of their arguments. Louis pointed out that there was no evidence provided by Firestone to underpin some of the assertions which Firestone made. Louis was correct – Firestone came up with some valid wish-lists but did not evidence how they would be fulfilled. Condemning Louis for highlighting the evidential omissions in Firestone’s arguments isn’t a valid criticism which can be levelled at Louis. Put more simply, you can’t harangue Louis for pointing out the flaws in Firestone’s piece.

JMF: I proposed some alternatives to think about. That’s all. I also said I didn’t know if they would work, but suggested considering them. So, I didn’t make an argument asserting that the WOA approach would work and should not therefore be called upon to fulfill “evidential gaps” but only to engage in further discussion with others who will consider other alternatives with an open mind. I don’t know what “assertions” I have made that Clive finds unsubstantiated by evidence, but I miss either Louis or Clive quoting these in their arguments. So, if anyone is guilty of making assertions unsubstantiated by evidence, it is they. Where are their quotes, why are they relieved of the responsibility to present them, while I am charged with responsibility to produce evidence for assertions I have not made?

One thing I do know is that “solutions” to the IT problem of Grexit that take up to three years to implement are not acceptable solutions to the IT problem, since Greece may have to Grexit in the short run without very much of a grace period. And, if they do not have to Grexit and stay in the Eurozone for a long a period of time, then they will be an even more economically devastated country than they are now for a very long time.

Louis Proyect, Clive, Yves, and many commentators may be correct in assuming that Grexit isn’t a feasible solution, so that Greece will have just have to suffer until the rest of Europe comes to its senses. But this is not a solution which works for Greece, its people, or for any who sympathize with it or them. It is not even a solution which works for Germany. It only works for those interested in looting Greek public assets.

It may be that TINA is true here. But, I hope Clive will forgive me if I choose to pursue suggesting some possibilities which perhaps may overturn TINA, and which may be worth thinking through. The real question here, is why Clive and many others on the Naked Capitalism site aren’t joining me in trying to think of alternatives allowing Greece to Grexit very quickly, rather than just accepting TINA?

I don’t think suggesting alternatives is excessive optimism, which, again, is all I did. I hope these alternatives receive very exacting criticism, since the high cost of using a bad alternative is so high. But thus far, I don’t believe that my two suggestions about alternatives to TINA except mainframe application re-engineering, have received exacting criticism. How could they have received it when neither Clive nor Louis nor any of the commenters on Louis Proyect’s post at NC have even quoted my suggestions accurately and in detail? I don’t even see evidence that Clive has read the two alternatives I included in my chapter.

So, I ask for specific objections to specific proposals showing why they can’t work, not quotations about “excessive optimism” from government reports, or claims that I supposedly provided no evidence for my suggestions, when I never said that they were more than alternatives to think about, and presumably find evidence pro or con or both. What evidence do I need to get people to discuss the suggestions without dismissing them with general considerations which may or may not apply?

Clive continues:

There is a similar theme to your disliking Louis’s choice of words in making the case that converting legacy systems to web-enabled services is very difficult. This subject has already been covered extensively in the Naked Capitalism archives so you could look there for supportive evidence of Louis’s premise but really, it is not hard to find a significant body of well-respected, independent confirmation of Louis’s point.

JMF: Neither this “supportive evidence” nor the links to it were provided in Louis’s post. So, the fact is that he did nothing to cite cases that support his premise. Also, the points at issue are not points that Louis made about the difficulty of re-engineering mainframe transactional applications. There is no disagreement about assertions related to that point. The disagreement is over the possibility that my suggestions about alternative approaches are worth thinking about. And, if I am not mistaken there are no posts in NC archives that address the specific suggestions I raised or others like them. And, if Clive thinks there are then he must provide the citations involved.

Why citations are important, is because anyone can say that “supportive evidence” exists. But whether or not what they point to is really supportive evidence can only be determined by other evaluators if the “evidence” is cited and those evaluators can judge for themselves whether they apply to the arguments or claims they are supposed to be refuting. For example let’s take a look at the work Clive cites right after the above passage as “supporting evidence” for Louis’s assertions. Clive’s statement about this follows.


One of the most comprehensive, again from the UK National Audit Office (who has had, erm, some experience of flushing vast sums of money and many decades of time down the drain doing post-mortems on IT train wrecks) who did a whole paper devoted to how big an ask it is to drag legacy systems into a web-enabled model and highlights several problems which are easily understood when well explained, such as:

Business transformation, including the drive for digital transformation is proving challenging for departments when it involves legacy ICT. Many legacy systems require data to be processed as a sequence of batches that is incompatible with a fully real-time digital service. In the pension system, for example, online applications have to be manually re-entered into the main system by a (Department of Work and Pensions) operator, as the website and the main legacy ICT system are not integrated. The approach of adding functionality through the addition of interfaces to the core legacy ICT is likely to be insufficient to achieve full digital transformation.

And as soon as you get into trying to “slap” a web front end onto an unchanged legacy system (the likelihood of this being required increases if you are attempting to web-enable legacy systems in very short timescales) then you actually defeat the object of your attempts to transform the legacy system into something a bit more modern because it increases the risk manual workarounds have to be put in place to glue everything together. Manual workarounds are the death-knell of the sorts of real-time processing which web enablement needs (emphasis mine):

JMF: Well, this sounds good, but it certainly doesn’t reflect my WOA proposal which is not limited to “slapping” a web front-end onto a legacy system. The WOA alternative includes “wrapping” the mainframe application so that it has an API exposing its functionality to a web-based network. Then it envisions integrating that component with another through web service-enabling it, and exposing it to other applications in the WOA.

The function is solely to convert Drachma inputs into euro inputs and euro outputs into Drachma outputs, into a “mashup” application that can process Drachma-denominated inputs in electronic currency into Drachma outputs in that currency with the mainframe euro-denominated application in the middle doing the processing, all so that the mainframe application doesn’t have to be re-engineered immediately to be usable in an immediate Grexit. The web front-end is then created for the “mash-up” application alone, and it is that composite application that supports using the new electronic currency during Grexit. This approach does not prevent manual processing of Drachma inputs and Drachma outputs through the web interface, if that’s necessary.

Clive (continuing his reply to Ben with his next quote, which by the way comes from p. 21 of the cited report):

We examine the impact of adopting a ‘no change’ approach to legacy ICT. Our findings are drawn from our case study of the Office of Fair Trading’s (OFT) consumer credit licensing service. A full report on this service is available at http://www.nao. … business processes are typically adjusted to meet new requirements and may include additional manual processes. Introducing change in this way potentially offers the lowest capital cost and the lowest risk that service performance will deteriorate as a result of change. However, while it may allow an organisation to change its services to some degree, it is unlikely to reduce costs or improve performance. It is also unlikely that transformational change, such as introducing phone or web-based channels, could be delivered.This strategy therefore leaves the organisation exposed to the full risks of legacy ICT.

So, with a modicum of industry knowledge and subject matter expertise, I’ve been fairly easily able to find good quality, neutral, documented evidence to support Louis’s points. If you, as you undoubtedly do, take issue with what Louis has been saying, then I invite you to back up your counterarguments. Otherwise, you’re merely falling into the sort of blaming the rhetoric lazy logic you’re accusing Louis of.

JMF: Unfortunately this quote doesn’t support Louis’s points because it does nor refer to the approach of “wrapping” mainframe legacy applications. However, there is a quote from p. 25 of the same report quoted from by Clive that supports at least part of my suggestion without contradicting the rest:

3.1 In this part we examine the impact of adding functionality to a service through the addition of interfaces to other systems and applications, leaving core legacy ICT largely intact. The Department for Work and Pensions’ (DWP) pension service and HM Revenue & Customs’ (HMRC) VAT collection service were selected as case studies for this ‘enhance and maintain’ strategy. Both departments use software and system ‘wrappers’ around legacy ICT to deliver additional functionality. Our full analysis is available at

3.2 The government has referred to this approach to ‘enhance and maintain’ as applying ‘wrappers’. This is government’s preferred option for dealing with legacy ICT. This approach can be used to make transformational change, for example, introducing online channels. This results in a more complex technology estate, which tends to increase the full cost of service and skill requirements. Introducing change in this way requires some capital investment, and is generally slow to implement and exposes the organisation to a risk that service performance will deteriorate if new technology does not work as planned. As legacy ICT remains, this strategy still leaves the organisation exposed to its inherent risks and in the longer term can be unsustainable as the complexity and cost of maintaining the ‘wrappers’ increases.

JMF: I agree with this statement. Please note that it says that “wrapping” can be used to make transformational change including online channels which is a central point behind my suggestion. Also, please note that the qualifying statements that follow this one say that 1) capital investment is necessary, 2) it’s generally slow to do the wrapping 3) there’s risk that performance will deteriorate, 4) it exposes the organization to risks inherent in the legacy application, and 5) it can be unsustainable in the long run for the reasons given. But the question is how do these problems impact my suggestion about using the WOA approach?

Well, 1) so some capital investment is necessary, so what? 2) If one uses an approach of coding one’s wrapper, then indeed it may be slow. But what if, if you use a development tool such as the two I linked to (then by all accounts the process isn’t slow at all). 3) Since the WOA solution envisions re-engineering the mainframe application over time as the Grexit is going on, then any performance deterioration over time can be avoided by using the re-engineered mainframe application. This makes clear that the WOA approach is not an alternative to the mainframe re-engineering approach; it’s just an alternative to the mainframe re-engineering alone approach. Instead, there’s an “and” here, not one or the other. That is WOA first, and, in parallel, mainframe re-engineering.

So, 4) since the mainframe application is getting re-engineered, then the risks inherent in the wrapping will be mitigated by the full-blown re-engineering effort as time goes on. Again, I’m not suggesting using WOA to avoid mainframe re-engineering, I’m suggesting it as a temporary expedient to allow Grexit to go on. Of course, the new mainframe application, when it is completed, would also be wrapped for WOA.

And (5) right, of course, the temporary expedient is unsustainable. But it is not intended to be sustainable. It is intended to allow the transition to Drachma, while the new mainframe application is being re-engineered and integrated into the WOA for the long term. Indeed, even mainframe maintenance can be incorporated into the WOA.

So, summarizing, the UK report cited by Clive actually tends to support my position when one looks more closely, and especially when one considers that my suggestion includes using web-enabling, and web services-enabling rapid application development tools with no language programming needed, a situation not envisioned in the UK report, or evidently, by either Louis or Clive.

I think that the lesson emerging from Clive’s comment is that when criticizing a suggested alternative, one needs to be careful to be specific and not to rely too heavily on general rules that do not relate to the specific suggestion being considered. I think that the Naked Capitalism critics are making many pronouncements of the very loose “lessons learned” variety, that are not specific enough to actually speak to the suggestions at hand. Specifically, the two suggestions I outlined in my chapter. I also think that successful criticisms of what I suggested need to be much more precise and focused on the specifics of my suggestions and not on more general classes of situations that do not apply to what actually has been suggested.

The exchange between Ben and Clive then continued further for another round:

Ben continues:


You argue that Louis’s statement to the effect IT is more than credit cards and hospitals is a true statement and therefore not a strawman. But a strawman is mischaracterizing someone else’s argument and Louis clearly implied that Joe and Mitchell ignore the complexity. It therefore is not material whether the statement is true.

There is a similar theme to your disliking Louis’s choice of words in making the case that converting legacy systems to web-enabled services is very difficult.

Doesn’t matter. Louis did not present such evidence, he simply indicated the idea is stupid and rapidly moved on. I applaud your technical knowledge but that isn’t the issue at hand. The logic and style of this person’s post are my concern and in my opinion both are sorely lacking.

I’ve refrained from commenting on this topic for months simply because I’ve watched people whose work I respect as well-argued go off the rails into exactly the sort of thing NC has stood as a bulwark against. Posting derogatory and inflamatory text like this is not only (in my opinion) beyond the pale but damned weird.

Clive replies:

Sorry Ben, but in trying to make the case for Joe and Mitchell by refuting Louis’s piece you end up digging a deeper hole to fall into. When you suggest that Louis was straw manning because, as you correctly put it

“Louis clearly implied that Joe and Mitchell ignore the complexity.”

Yes, Louis did clearly imply that Joe and Mitchell ignored the complexity. In fact, he (Louis) wasn’t at all subtle about it — he came right on out and said it. He stated quite clearly that Joe and Mitchell were ignoring complexity. But I too have read the piece and my reading of it is exactly the same as Louis’s. I’ll say it here too: Joe and Mitchell, based on what was published, ignored the complexity.

JMF: I don’t think I ignored the complexity of the mainframe application at all. In fact, I acknowledged it, and then I proposed the alternatives as worth a discussion as possible ways to avoid the re-engineering of a complex application in the short run, by avoiding converting that mainframe application. That was the whole purpose of my approach to the software problem! I also said that in the longer run the mainframe application would have to be re-engineered due, in part, to its complexity and difficulty of maintenance. So, how was I ignoring “complexity,” or is Clive just saying that if someone suggests that it may not be necessary to re-engineer that application to perform Grexit successfully, they are doomed to failure. If so, then a proof of that conclusion is not in evidence in his comments, or in Louis’s blogs on this subject, or anywhere else on the Naked Capitalism site, or anywhere else, so far as I know.

Clive continues:

The whole thrust of Joe’s article was that suggestions that Greece would have difficulties in implementing the necessary changes to the IT systems in the financial infrastructure of the country was just naysaying and that there were solutions which could be implemented fairly easily and quickly if only people were willing to look for them. Now, you’d no doubt call what I’ve just done there “straw manning”. But I would call it what it is (certainly it is what I am attempting to do): “summarising”.

JMF: Clive is simply wrong about this. I never said that such suggestions were “just naysaying,” nor did I imply that. On the contrary, I said I was persuaded about the complexity of a conversion by their very posts in my book, and that consequently I favored an approach that would avoid conversion in the short run. Nor did I suggest that any permanent solutions to the IT problem could be implemented quickly, but only that there were alternatives that would allow Grexit while the longer-term software conversion project was going on.

So, I think Clive is not just “summarizing” what I said, but rather is “absolutely mis-characterizing it,” compounding Louis’s previous “straw-manning” as well as his own. If Clive doubts this claim, then I challenge him to quote the e-book to the contrary, or forever hold his peace.

Clive continues:

If after reading Joe’s work you come to the conclusion that it is indeed a description of the complexities which are inherent in migrating the IT systems in the Greek financial system from the euro to a new currency then, well, we must be reading entirely different articles. Joe’s feature does not make that point. It makes completely the opposite point. Me saying that is not straw manning. It’s making an accurate précis.

Joe is wrong. Louis is right. I was about to add in a run-on sentence “in my humble opinion”. But that’s just the point: it’s not either my opinion or Louis’s. We can both point to significant bodies of work which substantiate our positions. Louis didn’t apparently feel the need to go to town with endless footnotes and links like some college dissertation.

But that doesn’t make what Louis wrote wrong just because his article wasn’t peppered with links to other pieces which are easy to locate in the Naked Capitalism archives. I’ve found plenty of supporting evidence myself elsewhere which I linked to in my above comment. So I’m happy to concur with Louis.

If you think we’re wrong, then the onus is still on you to provide supporting evidence and facts.

JMF: First of all, my “article” wasn’t an article. It was a chapter in the book, suggesting again that Clive has not read it. But, apart from that, of course, and once again, I didn’t make the case that the mainframe application was characterized by complexity. That case had already been made convincingly to me by the NC bloggers and commenters, including Clive.

I was suggesting, once again, that its complexity was not enough to conclude that an immediate uncooperative Grexit wasn’t feasible, because there might be ways of avoiding changing the very complex mainframe application in the short run that would allow Grexit to occur.

Why is it so hard to convey this point to the NC bloggers and commenters and to get them to discuss why specific alternatives that seek to avoid changes to the mainframe application for the short run are unfeasible? Why are their minds so closed against discussion of such possibilities. Why do they keep coming back to the thousands of difficulties involved in re-engineering the mainframe application, rather than avoiding doing that?

OK, folks, point taken. It was taken at the beginning of my chapter on the IT software problem in my e-book. Can we please move on now to discuss whether problems of the mainframe application can be avoided for purposes of Grexit by the two alternatives I suggested or by others we can collectively think of?

8 responses to “Grexit: Exchanges on the IT Problem Continue

  1. Jerry Miller

    Thanks for your continued inquiry on this salient issue. You are too kind in providing a highly complete roadmap for your commenters, perhaps. Perhaps they never get to the guest, which you pose clearly in your final paragraph.
    Here. Let me ask for you.

    Dear Experts in Financial IT Systems:
    Is there a modern, perhaps incremental, pathway to implement a new currency for Greece, including all current user/bank/agency interfaces? Please illustrate, perhaps, with recent projects in which a new or modified currency scheme was developed. Or, perhaps, with failures in such attempts.
    Thank you.

    • Joe Firestone

      Most of the experts who commented on financial systems were, apparently expert in mainframe financial applications, their internal characteristics and the difficulties in modifying them due to their complexity. They really didn’t have much to say about about embedding them in comprehensive web-based architectures and constructing composite applications using them would have augmented capabilities. I infer from this that the “experts” are not “expert” in that subject and could not comment on the WOA alternative I pointed to.

      The closest anyone got to such a comment was Louis in his latest post where he says about my two possible alternatives for postponing immediate conversion of the mainframe financial applications:

      This assumes that you can hold off converting “the mainframe application” for the future but that’s not the way that banking systems are put together as if they were Lego toys made up of discrete modules that can be assembled in phases.

      I’m afraid I don’t know what “this” refers to in the above. Is it the WOA alternative, or the what I called the “minimal change” alternative proposing setting up a firewall between the ECB and the Greek banking system. As far as I can see, neither one proposes to take the mainframe system and break it down into its component parts within the time frame of the initial Grexit. The WOA alternative just wraps the whole mainframe back office application. The minimal change alternative focuses on a firewall external to the application cutting it off from the ECB and target, an approach that also doesn’t modularize the mainframe application. So, I think Louis’s contention is not relevant to my alternatives.

      Think of it this way. When you open a checking account, you sit at the desk of some bank officer who begins entering your information into a computer, starting with name, address, social security number, etc. He or she then issues you a temporary ATM card that can be used immediately for deposits and withdrawals.

      In the ensuing months, customers might take out a credit card from the bank and afterwards a mortgage and/or an auto loan. And each month they expect a statement that will have an accurate record of their transactions, both debits and credits. I am sure everybody is accustomed to this unless they are used to keeping cash under a mattress.

      The implicit assumption (bordering on explicit) in both Mitchell and Firestone’s presentation of the problem is that such a “phase” is essential to moving to a drachma. I can certainly understand why someone might think in those terms because that is generally how we relate to a bank—as a customer. I should add that the applications that handle such relationships are generally referred to as belonging to the “front office”.

      Unfortunately, most “back office” operations must be converted on the very day that you implement a new front office based on a drachma since they are designed to support the managers and clerks who are invisible to the customer but critical to bank operations.

      I’m afraid, I don’t see the relevance of these claims either. Let’s concentrate on the immediate Grexit implementation. In the minimal change alternative, the only change to the system is cutting it off from the ECB and giving the BoG or a new public bank the authority to issue Greek Euros. How does this affect the IT aspects of the current system other than creating the need to use another international financial settlement system?

      In the WOA alternative, the basic idea proposed by Bill which I agree with, is that the Drachma would be used only for deposits from the Government and those choosing to deposit Drachmae in their new Drachma accounts issue by the Government; and only for payments to the Government, to other sources required to accept payment in Drachma by the Government, and other sources willing to accept Drachmae for goods and services. Most of the economy would not be involved in such transactions. For them the old system still works. For the transactions in Drachmae, the wrapper works to do the necessary input/output euro to drachma conversions in real time, without touching the mainframe code. So, why must the back office functions be converted on the first day when it has been “wrapped”?

      • Yes.

        You get a new currency in Greece the instant the ECB closes the Greek central bank’s TARGET2 account. At that point all transactions across that interface will simple fail.

        So all you need to do is put in place correspondent banking arrangement with commercial banks to do the *exchange* between Greek Euros and German Euros. And that simply requires a bank with a leg in both camps – a reserve account with Greece and a reserve account elsewhere in the Eurozone. Or a correspondent between two banks that achieves the same thing.

        The problem here is a bunch of people over thinking the problem. Get down to the essence of the issue – exchanging Greek Euros for German Euros in a float situation.

        Then you keep everything else *exactly the same as it is now*.

        It’s called the Principle of Least Change.

  2. Viral Tarpara

    As an IT person who has worked with the financial industry, I find these collective set of post quite pedantic and overly academic. It is clear that the necessary expertise has not been truly tapped and that the discussion has not even reached the envisioning stage. I will avoid going into a point by point critique, however I to establish a baseline, I feel it important to show a visual representation of what a mature, functional, and comprehensive representation looks like when discussing the banking sector:

    Readers will note that this poster represents “7 Business Areas, 36 Business Domains, 280 Service Domains, 1960 candidate Service Operation and 178 Business Scenarios.” So when economists or even IT people throw phrases such as, “its not rocket science,” it borders on delusional to imply that the real IT issues are trivial or even solvable on a fixed time schedule. Conversely, realists within the defeatist camp poorly argue why a Grexit is not viable because of some technical limitation. A Greek Drachma can absolutely be architected and deployed; the question is which functionality will be prioritized from a design, engineering, policy, and legal perspective.

    Then there is the very real question of transition systems. If the expectation is to move from A to B, this is nothing but a failed attempt at a logical exercise. “Transitioning to Drachma” must be defined in phases which, by definition, will imply pain for businesses, consumers, foreign sector, and government. To reach a mature transition to Drachma covering all mentioned service domains will take years; this is a simple fact. The service domains that are least prioritized will incur the most pain, and is a political choice.

    What matters before all of this is the will to leave the Euro. If the Grexit is to succeed, there first needs to be a firm political, social, and legal commitment to do so, only after can the technology can follow. This may require nationalizing bank functions, importing existing IT banking platforms, and perhaps setting up a national agency responsible for overseeing modules and standards. Alternatively, Greece can choose a wild wild west system and go back to 19th century banking models augmented with modern technology and let markets sort it out–though I’m not an advocate of this sort. The reality is that the solution will probably lie somewhere in the middle. Regardless the model chosen, the public cannot be under any such opinion that their financial and banking affairs will resemble the service levels provided by the Euro. It will be gradual continuum of progress and functionality is developed, systems are transitioned, transition problems are remediated, and final service levels established.

    Greece will have many capable technology companies ready and capable to assist with this massive project. What they will need above all else is a pragmatic leader who can envision the path and executive against the economic priorities. For Greece it will never be a question of whether a complete transition can be successful, but rather, how long will it take. Therefore, the relevant discussions by thought leaders should be less about abstract IT problems, less about the nuts and bolts, and more about the political, legal, and economic resources the country is will to deploy to move forward, as well as the key stakeholders who will be accountable in the process.

    • Joe Firestone

      In my e-book, I have two chapters on this. One is on the No Grexit/Grexit strategy alternatives and one is on the software difficulties in Grexit. Above you begin by commenting on one of my IT alternatives which is only part of the IT chapter, and the continue with considerations which, in part, are covered in my strategy chapter. So, you may want to read that, as well the rest of the technology chapter.

      • Viral Tarpara

        Thanks Joe. I reread Bill’s original post and on balance agree with his position almost completely. Where I became a little unhinged mentally was when the discussions, both in posts and responses, started discussion actually software solutions, web services, and building middleware over legacy systems. Such conversations are wholly premature from an IT architect’s perspective. IT architecture for a central bank and corresponding banking sector is serious work that should not be discussed like a Silicon Valley project, which was the feeling I got from many comments.

        • Joe Firestone

          Well, I’m probably guilty of the web services part of that. But I still think that the mainframe “wrapping” approach using a tool like those I suggested is worth investigating, just because it doesn’t tamper with the mainframe application.

          Btw, one of the main issues in the background here is whether, as Bill suggests, the Drachma gateway for the mainframe application can just be turned on. That’s a matter of fact someone who knows the Greek Banking system could settle. If that can be done, Bill’s view would be validated and the objections we saw at NC just disappear.