Wednesday, October 9, 2013
What is EA and what is EPM
There is a lot of miscommunication about what EA/EPM is, should be, could be, should be.
I keep coming back things said in Royal of Academy of Engineering and British Computer Society report on ""The Challenges of Complex IT Projects" (ISBN 1-903496-15-2)" e.g.
- "there is a broad reluctance to accept that complex IT projects have many similarities with major engineering projects and would benefit from greater application of well established engineering and project management ..."
- "a striking proportion of ... difficulties stem from people ... failing to implement known best practice. This can be ascribed to the general absence of collective professionalism in the IT industry..."
- "... problems relate to the people and processes but further in developments in methods and tools is required to support the design and delivery ..."
Re the 1st point above - a starting point would be understanding what we mean by the terms/roles/areas of activity (and using another complex, but very mature, design domain as a parallel) - for what it is worth - this was my view in 2007 (and remains essentially the same):http://ea-in-anz.blogspot.co.nz/2007/09/ea-and-analogies-with-built-environment.html. But to summarise some very broad classifications:
- Portfolio Management (EPM, Property Portfolio) - is not about design it is about economics and metrics (risk, cost, value, etc.).
- Planning (Town Planning, Strategic IT Planning) - is not about design either - it is about having view of the future at different points in time and mapping out, usually broadly, how to get make these views reality.
- Standards Management (Building Material Codes and Standards, Technology Standards Management, Patterns management, Principles definition) - is not about design of any specific solution/design its is about saying what we should build with and how we should assemble those elements. The economic drivers of standards management could come from portfolio management, but if guidelines are easily and accurately reflected in down stream processes then the proliferation of complexity and diversity will proceed unabated.
- Enterprise Architecture (City Design, Large Project Design e.g. Olympic Complex) - is about the design of enterprise (and encompasses many aspects of the above) and unlike its built environment counterpart the flow between what we want to do and with what technologies we do it is far more fluid (because the materials/technologies in the built environments change order of magnitude more slowly).
- Solution Architecture (Building Architecture) - is about design, but it is not really about detailed engineering or construction of the various modules, elements or systems that the building is created from (that is done by specialized sub-trades).
- Software Engineering (covers a multitude of sins - e.g. many Building trades - plumbing, interior design) and it is design.
- Systems engineering to achieve performance standards - "ilities" - is about design and relies heavily on patterns and best practice and calculations.
No one it their right mind would suggest that the same tooling/technology/modelling be used for all of the above:
- Property Portfolio
- Town Planning - maps might be useful
- Standards Management
- Enterprise Architecture - maps useful but insufficient
- Solution Architecture - maps referenced, some CAD capabilities required
- Software Engineering - many CAD trade specific design systems require
- Systems Engineering - as for Software engineering but different e.g. analysis of structure, heat etc.
So one gets an eco-system like this: