Review - RecEAtion by Chris Potts

RecrEAtion by Chris Potts is an IT fantasy novel aimed at frustrated Enterprise Architects. The novel begins with an Enterprise Architect named Simon starting a job in the role of Vice President of Enterprise Architecture at a global company. He meets the CEO who says “Sounds like we have the same job!” Obviously the CEO had never heard of Enterprise Architecture, which would be easily believable, but the fact that the VP of EA reported to the CTO should have set off the warning bells. It is comedy gold, as the CEO mistakenly construes Enterprise Architecture as something to do with designing the enterprise!

At this point the novel turns into pure fantasy. Undeterred by the fact that Simon is actually a mid level IT person with an impressive title the CEO decides to take Simon under his wing for no obvious reason, and within a few days Simon is reporting to the CEO and sitting in on a meeting with one of the senior executive team. Then with one fairly inane idea blurted out in this meeting the CEO decides Simon is a genius and sends him around the world to meet and advise senior executives in the company’s most critical locations.

During the journey Simon realises that everything he ever thought he knew about Enterprise Architecture was wrong, that his whole career is a lie, and that what he really should be doing is flying around the world chatting to senior executives about financial ratios and organisational issues. And just to prove you can take the man out of Enterprise Architecture but you can never take Enterprise Architecture out of the man he manages to develop a new process model and framework diagram that solves all EA problems!

The critical issue with EA that Potts fails to grasp happens in the workshop with the team of EAs in Hong Kong. Simon asks the Architects to answer two questions:

1.      What is Enterprise Architecture?
2.      What constraints affect EA contributing to the company’s success?

The answers to the first question were completely inconsistent, which is to be expected by anyone who has ever had to deal with Enterprise Architects.  Rather than attempting to clarify the definition Simon takes the role of a true EA and says that all responses were part of EA! Like the Force, EA is everywhere, able to do anything. Crisis averted.

The second question is wrong in so many ways. The various responses really boiled down to a marketing problem with the rest of the business, and EA needing to communicate their brilliance in a way that the dolts in the rest of the business could understand.

A much better question would have been “What is the purpose of Enterprise Architecture?” Potts provides a mission statement for EA that provides something of an answer. Although the statement is essentially meaningless (“structured innovations” sound like fluff) it does capture at least some of the aspirations of EA. 

“Enhancing Enterprise performance with structured innovations”

I think this is really the critical question for all EAs. If you know your purpose then you can plan your strategy and tactics for achieving your purpose. It really does not matter how much business engagement you have at a senior level, or how much marketing activity your team does, you are never going to provide much contribution to company success by mapping all of the company’s systems and processes in Archimate J

I am not sure I have a better mission than Potts, but then again I am not the one writing the book J I guess if I had to come up with a mission for EA it would be something like this:

“Helping the company make better decisions about systems and processes to enhance current and future performance”. OK, so a bit ungainly, but captures the essence of what effective EAs actually do, rather than a fantasy about engaging seasoned executives with undergraduate business school ratio analyses (what do they think they are; consultants?!).

When I do IT strategy sessions with customers I ask them to define their end state in terms of what can be achieved with current technology. There is no point in trying to predict what technologies, vendors or practices might be ascendant in five years. Strategy is hard enough without trying to incorporate fortune telling in to the process. I always tell my customers to wave a magic wand and describe what good would look like today if there were no constraints. It gives a realistic goal to shoot for while clearly understanding that the goal is not reality. 

In many ways RecrEAtion is also trying to wave a magic wand and imagine how Enterprise Architecture could be. But unlike my strategy example there is no value in imagining a fantasy, as there is no practical roadmap to get there. In its current state the reality is that EA will never be anything more than an IT discipline because the people that do EA are essentially technologists. In fact in the last few years EA has drifted further off course. The over reliance on EA frameworks, EA tools and certifications has fostered a very insular community that is not only out of touch with the core business, but increasingly out of touch with IT as well.

The idea that many EAs would be able fit in to the executive group of most organisations is laughable. There are such fundamental cultural differences, and a requirement for skills that I would not usually associate with many Enterprise Architects, such as the ability to deal with ambiguity, big picture thinking, non binary decision making, diverse relationship nurturing, concise presentation, rapport building, consensus building, engaging public speaking, optimism, determination, passion, leadership…. I could go on, but you get the picture.    

So ultimately a though provoking and interesting book, but no real solutions. 

Review - FruITion by Chris Potts

FruITion by Chris Potts is an IT fantasy novel aimed at frustrated CIOs. Chris tells the tale of a typical IT department caught up in providing IT to the business. After developing the IT teams 75 page strategy document the CIO presents the strategy to the CEO and effectively gets it thrown back in his face. How is a 75 page document of IT expenditure a strategy? And how is it remotely useful to the CEO, or the rest of the business as a whole?

Potts does a good job of identifying the typical IT structural issues. The main problem if an IT department wants to act as a supplier then why don’t they get treated like a supplier? If they are part of the business then why aren’t they embedded in the normal business?

So the ultimate solution in the novel is the IT operations team is placed under procurement, the IT projects team is placed under operations, the Enterprise Architecture team is placed under corporate strategy and the CIO role is effectively abolished. In the novel the CIO becomes the Chief Internal Investments Officer (CIIO), a brand new role that reports to the CEO and is part of the executive team.
So let’s start with the dumbest idea first, the role of the CIIO. For the vast majority of enterprises this responsibility is clearly the remit of the CFO, with the exception of financial services organisations. If the role existed it would be part of the CFO team. In any case who in their right mind would put an IT manager in that role?

The idea of splitting the IT teams into business functional teams is not new, in fact that is how IT started. Back in the 80s these types of structures were common, the rise of the monolithic IT department only really started to evolve in the 90s. And the reason IT departments evolved was because IT projects and operations are complex. IT is treated differently because it is different. Building and running an IT business system is not the same as paying the electricity bill, no matter what cloud vendors try and flog. There needs to be a single point of responsibility for IT service delivery. That is the role of the CIO.

Sure you can run projects and operations separately. You can outsource one or the other, or even both. But if the only point in the hierarchy where responsibility for both comes together is the CEO then you are in serious governance trouble. It the point where they come together is the CFO then you are not much better off. The tradition IT department structure is a bit like democracy, it has its flaws, but at this time it is still probably the least worst way of running IT.

The big problem with this is that simply restructuring the org does not provide any value at all unless you take the next step and completely outsource the whole thing. All you do by restructuring is add complexity and risk to existing operations and procurement teams, who are not equipped to cope with IT, and were probably doing stuff that was critical to the business before they got derailed by IT. So the real question is whether or not to outsource, not to restructure.

Which just leaves us with the Enterprise Architects. Potts’ argument here, and in the next book, is that Enterprise Architecture really should be part of corporate strategy. I am kind of mystified by this solution, if you want corporate strategists you should hire corporate strategist, why try and recycle Enterprise Architects when they are woefully inadequate for the job? The fundamental question here is if the traditional role of Enterprise Architecture adds any value at all, and Potts is really suggesting that is doesn’t. In that respect I completely agree with him. 

So in the end the real world outcome for the scenario presented in the novel should have been sack the CIO, sack the architects, outsource all IT operations and projects, and leave a small IT team in place to manage the outsourcing relationship, reporting in to the CFO. Otherwise why go through half of the pain of an outsourcing style transformation and get none of the benefits?

So ultimately a though provoking and interesting book, but no real solutions.