Sunday, January 25, 2015

A Theory of EA?

It was with great interest that I read Nick Malik’s recent post “Moving Towards a Theory of Enterprise Architecture” and the response from Tom Graves “Theory and metatheory in enterprise-architecture”. Whilst I generally don’t respond to blogs I thought that the questions and considerations raised by both of these erudite gentlemen raised enough questions in my mind that I thought I should contribute. Whether that contribution is worthwhile is for others to decide.

First some background to my post. Around 12 years ago I set out on an academic journey to better understand the emerging concept of Enterprise Architecture. At that time there was very little material available in either the academic or professional practice sphere to assist in understanding this evolving ICT centric practice. Many organisations had established EA practices in the hope that EA could help unravel the maze of organisational information systems to better understand how they contributed to the evolving mission of the enterprise. Gartner had developed some material around capability maturity in EA which helped EA practitioners to better assess the outcomes of the practice.  
From that foundation, I set out to understand the concept of an EA. In order to focus my work, I turned the lens of my limited understanding onto the equally poorly understood world of emergency management. I established a framework for analysing the operation of an emergency management team. Whilst there is an adhoc element to these teams (specialists are assembled to address specific types of emergencies) many agencies have a permanent cadre of staff who are responsible for maintaining core skills and situational awareness in their sphere of responsibility.

As I met with these core staff, and worked as a member of adhoc emergency management teams I naively assumed that the problems they faced were addressable through the application of technology. I believed that we technologists had only to find/develop the right tools, implement them and be hailed as the “saviours of the emergency management world”.  How wrong I was!

I was lucky enough however, that enough people took an interest in what I was doing to provide me with opportunities to examine emergency management teams in a range of different environments. That included participation in a very large multi-agency disaster exercise in California. At that exercise I was lucky enough to spend time with Alenka Brown (then of Oak Ridge) who gave me a different lens to look at the emergency management world, and particularly the human component of emergency management teams.  I took this lens and used it to evaluate my work to date. In addition I was engaged to look at the design of a permanent police operations centre. The following model sums up what I came to understand about these critical incident management environments:

Now this discussion is not intended to be a discussion about emergency management. However, the case study highlights my fundamental problem with seeking to establish a “theory of EA”.
At this point it is important to understand that I differentiate between the solution architects – the folks who fill in the detail and work out the process and technologies that an enterprise need to put in place to enact the goals of an enterprise – and the EA. The solution architects have a rapidly evolving body of tools and methods to assist them in delivery of their design artefacts.

The EA is a different skillset. I agree with the comments by Doug McDavid where he lists a huge body of work by a range of practitioners. The EA, operating in James Lapalme’s third school of EA,  is someone who has to understand a very large body of knowledge. On top of all the technical, systems and human skills, the EA needs to have a more than nodding acquaintance with economics and accounting in order to have any credibility in shaping a modern enterprise. In many ways a third school EA must be a polymath.

My own work took an interesting turn when I started to work with construction architects to design facilities to support emergency management teams. I had to learn a whole new language. In effect I entered a new two year apprenticeship to understand construction and its language. I had to develop new tools and adapt my thinking to link the development of my design artefacts with those of the construction sciences.  So I could understand these relationships I developed the following model:

Note that the model is NOT a theory. Rather it is a means to express the relationship between the design artefacts which conveys to members of both the ICT and construction disciples as well as the stakeholders in the design of the new facility. This model is currently being used to design a world leading cancer research and treatment hospital where technology, process and the design of the facility will all contribute to the achievement of the aspirations of the community with respect to cancer treatment and research.

Using this model I could adapt a pallet of tools based on the use of Archimate 2 and BPMN to design this facility. I therefore have a school of thinking (Lapalme’s third school), which allows me to drive a philosophy of design which is engaged with construction design, and provides me with a language to engage with all of the stakeholders using a derivative based on a standard ICT architecture toolsets.

Like the world of construction architecture, the world of the EA is about principles of design. The construction architect does not talk about a theory of architecture, instead they talk about schools of thought – and those schools of thought provide a pallet of tools from which they can select a method of design. Construction architects translate human aspiration into artefacts which express that aspiration. In the same way, I believe, after twelve years of academic work combined with professional practice, that it is the role of the EA to express the aspirations of the enterprise through the artefacts developed. Artefacts which encapsulate people, processes and technology to coevolve the enterprise with its environment, both internal and external. Have I met such an EA yet – the resounding answer is NO.

Is such a skill needed? Noting Jamshid Gharajedaghi’s comments about the failure of Dow Jones listed enterprises at the start of his book on Systems Thinking – I believe that the creation of enterprises which can co-evolve with their environment necessitates the development of an EA role. However – that is NOT an ICT role.

So what have I learned in this 12 year journey?
  1. I do not think there can be a definitive "theory of EA"
  2. We need to break the shackles that still link EA to the ICT world. Thankfully this is starting to occur. However we need to further develop the tools and techniques to enhance the ability of the EA to speak across many disciplines. Archimate 2 has tried to do this but we still have a long way to go.
  3. The implications of the third school of EA mean that the EA must be able to understand and apply a wide pallet of tools and a range of technical languages which allows the EA to engage with a wide range of stakeholders and disciplines.
  4. An EA is a designer. In order to understand how an EA should operate within the practice, we need to look at the design disciplines and the thinking of the truly innovative in those disciplines - people like Philippe Starck and Steve Jobs. Such people do not look for a body of theory to support their design. Instead they understand what it means to be huiman and then design artefacts which express the aspirations which derive from being human.
 Anyway – that is what I think. And for the record – I failed to deliver my final dissertation. There is a stubborn determination in academia to use the scientific research method to develop a body of work which encapsulates some element of a body of thought – in effect to create the theory and then test it. EA is evolving too quickly for academic timeframes to work. And this is the core of the problem I have with the proposition that a “Theory of EA” can be developed. EA has to move quickly if we are to ensure the future survival of the enterprises with which we work.

In my own work I have visited many hospitals which have been designed in a way which does not allow them to coevolve with rapidly evolving medical technologies. Consequently the urban landscape is dotted with hospitals that become basic care facilities but cannot provide treatment or care based on new technologies. But that is a whole separate conversation!

No comments:

Post a Comment