What Problems Does Agile EA Solve?
- Managing the increasing complexity of information-technology systems.
- Managing the increasing complexity of business systems.
- The increasing difficulty in delivering real business value with those systems.
- Increasing distrust between the Business and the Information Technology sides of the organization.
- Business not being in a position to quickly assess the impact of substantial decisions.
- The business making what at the time seemed a reasonable business decision, only to find huge negative impacts later. (Merges & Acquisitions)
- Enterprise Architecture is a vast subject and as yet still relatively immature.
- No comprehensive vision and goals exist in the industry for what an EA Practice should do.
- Different ideas by different people as to how to proceed.
- Much debate and internal political struggles about to who owns EA within the Enterprise.
- People waste too much time on Framework discussions (not enough doing EA Architectural work).
- Some organisations think they are practicing true EA but in many cases they are just doing Solution Architecture on Enterprise systems.
- Those that do - waste a lot of time and money thrasing because of the above issues.
- Maturity measurement of EA Practices weak (possible exception of NASCIO)
- A muddle of 80's, 90's and 00's conceptual thinking
- A muddle of terminology around Roles in Architecture (Take Enterprise Architect -> Solution Architect often used inter-changeably)
- Many good tools, but no one toolset that does it all
- Some with their own standards, meta-models and notations
- They all try to support as many frameworks as possible to maximise market share
- Seem to either have come from Business Process Modelling, Case Tools or UML Modelling tool roots
- Tools being driven by latest hype or "fashion" in the industry (SOA, Compliance, BPM, etc.)
- Various standards in the industry around EA - no one particular standard/framework has full coverage
- No recognised open practices other than TOGAF (there might be more…)
- No formally defined terminology - inconsistent semantics. e.g What do we mean by the word "Technology" or "System", etc.
- No standard taxonomies and ontologies, everyone has their own idea on what they should consist of
- Too many frameworks.
- Organisations are not sure who "owns" Architecture - spans Business and IT. Traditionally IT. Someone has to be the ultimate custodian.
- Not enough organisations truely practicing EA. Many claim they are, but under closer scrutiny there are many weaknesses.
- Organisations battle to define the return on investment (ROI) for EA.
- Many orgsanisations are only now realising the opportunities and turning their attention to these EA issues.
- EA overlaps with many industry trends, directions and domains such as Business Process Management, Strategy, ITIL, COBIT, Business Rules (BABok), Business Process reengineering, SOA, etc. etc. the list goes on.
Agile EA Solutions
- Helps remove any culture of distrust between the business and technology sides of the organization.
- Takes some of the Practices that are shown to work and adapts them for EA.
- Uses defined terminology.
- Uses a consistent meta-model for defining the process (SPEM).
- Gives practical examples.
- Gives videos to listen to (easy for those who hate reading)
- Allows this to be tailored to suit the organisation's environment.
- Can be used by any size company / enterprise, not only global FTSE1000's.
- Defines consistent Role semantics
- Defines consistent Task semantics
- Defines consistent WorkProduct semantics
- The EPF AgileEA process can be used as a module integrating with RUP, OpenUP, and many other industry standards (and tailored)
- Tries as far as possible to be Notation independent (bias towards primary use of UML and Archimate)
page revision: 20, last edited: 08 Dec 2007 14:21