The term "EA" has developed some unfortunate connotations e.g. it has been confused with "technology architecture", "systems architecture", "solution architecture", "software architecture", "business process modelling" etc.
This is reminds one a little of the famous strong of the "blind men describing the elephant".
If one uses the analogy of town planning - it is a bit like confusing town planning with: architecture, electrical installation, landscaping, interior design, plumbing etc. When asking for a tool selection to support townplanning - one is then asked if it has a electrical load modelling capability; hydrological modelling capability; a lighting model for examing interiors, or a CAD tool for drawing beams [see http://ea-in-anz.blogspot.com/2007/09/ea-and-analogies-with-built-environment.html]
In EA at present one is often asked if it the EA tool is a CASE tool (ER modeller) or process simulation tool - and what this illustrates is that the person asking the questions does not a good grasp of what EA actually is. [see http://ea-in-anz.blogspot.com/2007/09/ea-cant-be-done-with-document-or-case.html]
EA also is often seen as some ivory tower activity that at best produces lots of large complex documents (that always out of date, and that are of little value to anyone other the authors) - mainly because EA is done in the wrong way.
[see http://ea-in-anz.blogspot.com/2007/08/myth-of-heavy-weight-ea.html]
It may well be that the pragmatic way around this is to abandon the term, and the
focus on the end goal which is business and IT transformation.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment