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?
- I do not think there can be a definitive "theory of EA"
- 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.
- 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.
- 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.
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!