What are some of the things a tool needs to do?
The correct selection of the technology requires a clear understanding of what is required. This includes:
- Communicating- to a broad set of stakeholders (not aligned to any specific technology, and most not aligned to any technology). This requires communication in many forms (diagrams, forms, reports, documents etc.) and using many media. This in turn requires a range of publication techniques.
- Accessible - if the information held in the EA is not accessible (e.g. via a Web portal) and searchable (i.e. based on the specific, and immediate, area of interest of the person looking for information).
- Analyzable - one must be able to analyse the information (this requires that concepts and relationships are explicitly recorded.
- Aggregating - the EA will contain data owned by many constituencies (people and systems) and it is necessary to be able to aggregate the information from the various sources. The systems include operational systems (e.g. CMDB), design-silos (e.g. ER models, UML models, BP models), and business people (with the plans, products etc.).
- Maintainable - as a natural part of day to day activity i.e. without requiring any substantial additional work by any of the data owners.
- Secure - reflecting who owns the data, and who can access it)
- Auditable -
- Consistent - so that if a change is made to a concept (e.g. a business goal, a technology component) it is reflected everywhere.
- Integrated and cohesive - so that all connections known are recorded.
- Explicit and precise - this requires that the semantics are able to be explicitly recorded i.e. the core concepts and the relationships between them (their types, properties, weighting, etc.).
- Business oriented - this requires that languages suitable for communication with non-technical people be used (e.g. not languages just used by design people UML, ER , BP etc.).
- Technically connected - this requires that the EA can represent the semantics that occur in the various technology design silos (UML, ER, BP, etc.) so that explicit connections can be made to things elaborated in related tools (e.g. CASE) and eventually leads to executable code.
If an EA professional advocates doing EA without suitable tooling - I would characterize it as unprofessional i.e. either they are ignorant (of what EA is, and what is required to achieve it) or they are being disingenuous (i.e. they know what is required, but don't see it in their interest to make it clear).
By way of comparison - if someone's profession was creating complex models in another domain e.g. large project plans, complex budgets, complex building design - they could not (in any of these domains) credibly advocate doing this just in say Powerpoint, Word or Visio (and at the same time claim to know a great about project planning, budgeting, complex building design).
What about an Office suite as a tool?
EA tools must have the detailed representation of information that BI requires, have the communication and ontological capabilities of knowledge management tools, be able to support the detailed semantics required for connection to dedicated design domains, and be able to graphically communicate complex designs.
Office suites fail for reasons such as:
- Communicating - Documents can't practically be produced for each and every stakeholder focusing on the small subset of the information they are interested in at any point in time, and presenting it in precisely the way they want to see it (diagram, forms, report, chart) etc.
- Analyzable - Documents (Word, Powerpoints etc.) can't be analysed (except by people)
- Aggregating - Documents don't lend themselves to aggregating data.
- Maintainable - no one can credibly suggest that all data held in documents is practically maintainable.
- Explicit and precise - Documents seldom explicitly record all the relationships within them and never record all the relationships across concepts held in sets of them.
What about CASE tools?
People' who start looking for EA solutions by asking about CASE capabilities - indicate that they have not understood the essential nature of the problem see:
http://ea-in-anz.blogspot.com/2007/08/business-modelling-with-domain-specific.html
http://ea-in-anz.blogspot.com/2007/08/uml-is-not-language-suited-to-most.html
1 comment:
Would agree with everything in that list, with one addition that links to 'Auditing': the tool should directly support whatever governance methodology is in use. For example, it should generate and store PRINCE2-style 'products' associated with the governance of each phase of the architecture cycle. As one example, System Architect does this for the standard version of the TOGAF cycle. But it could be done a heck of a lot better - especially in Troux Metis, with its much stronger alignment to real EA (rather than to the misuse of CASE that - as you say - occurs in so many other 'EA' toolsets).
On the limitations of MS Office et al as standard, as a toolset for EA purposes, I fully agree; though you might like to take a look at Orbus Software's iServer. It's an interesting attempt to provide an EA-oriented repository to cross-link and merge EA-related artefacts in MS Office documents, using Visio as the visual environment, SQL Server as the database engine and SharePoint as the distribution mechanism. Dunno how well it actually works, though - still waiting for a test-drive - but it might be a good intermediate step in some contexts, as long as people don't confuse it with the kind of real EA toolset you've described above.
Post a Comment