EA Tools Adoption

Research from 50+ years ago grouped adopted of new technologies into five categories:

• Innovators (about 2% of the population) or enthusiasts, will use a technology based on its features and do not require financial analyses before adopting a new technology.
• Early Adopters (about 13% of the population) or visionaries wait until Innovators have shown a technology has merits but still are not driven by financial analysis.
• Early Majority (about 33% of the population) or pragmatists need to see clear ROI analysis or ROI-based testimonials from others in a similar industry.
• Late Majority (about 33% of the population) needs concrete objective ROI analysis supported by multiple sources.
• Laggards (the remaining 16%) or skeptics will only use advanced technology if they have no other choice. Often new technology must be embedded in a total solution for a laggard to adopt a new technology.

I believe the EA tools adoption is now moving from the 2nd to the 3rd of these groups.

If you encounter an organization where innovation is the rule, you can promote the idea of EA tools based on their technical merits (and allow the innovators and early adopters to map the features to organization advantages and benefits)

If you find early adopters and early majority users you will need to focus on the ROI and carefully map the features of into specific advantages and benefits within your organization.
Promoting to late majority and laggards may require you to bundle EA tools into a larger package and sell that package as an organizational solution e.g. suggesting a complete IRM for the industry (e.g. insurance, health etc.)

RHE Analysis and modelling offerings

RHE offers a range of analysis and modelling services. These cover the:
- business strategies and plans (drivers, strategies, measures/KPIs, markets, products/service).
- business architectures (interactions, processes, policies/rules, information, organisation, agreements/relationships)
- business change (initiatives, business cases, programmes/projects, requirements)
- technology architectures (services/applications/components, HW/SW infrastructures, operational procedures).
- technology industry (vendors/products, standards, visioning etc.)
- technology design (SOA, objects/UML, data/ER, process/BPMN, etc.)

RHE uses techniques semantics, and tools that allow:
- reference models where they exist to supporting industry benchmarking
- information in the different areas to be inter-related.
- artefacts to be produced in a variety of forms (documents, diagrams etc.)

Lattix Troux Interface

(WIP steps are)

See rationale see (Enhancing EA with SW Architecture).

An overview or steps are as follows:

1. Model the application in the Enterprise Architect - e.g. in Troux Architect define an Application (and commit the Application to the Metaverse) or create the application in Metaverse directly. In production environments will have hundreds of existing applications (and these will usually be loaded automatically via Collectors).
2. Load Code for an Application - Load the code related to the Application into Lattix (e.g. on a PC client)
3. Analyse Code of App - Perform analysis in Lattix to determine modules (structure) and their relationships.
4. Export Code Analysis - Export an XML file from Lattix that contains modules and their relationships. The project name should be the identified (UUID-State) for the Application.
5. Move Code Analysis to Troux space - Make the Lattix XML file accessible from Troux Metaverse by placing the file in the Troux Lattix collection directory.
6. Load Code Analysis into Troux - The Lattix XML file placed in the Troux Lattix collection directory will automatically be selected and loaded by the Troux Collector.e into the Troux State, and related to the Application (based on the UUID).
7. Examine Application/Modules in Troux Explorer/BP Manager - in Troux Metaverse find the Application and the related Modules (that have been Collected/Loaded from Lattix - via the XML collector) - show pictures of the applications and its modules, lists of modules etc. using Troux Explorer.
8. Examine Application/Modules in Architect - in Troux Architect client (connected to the Metaverse/State) e.g. select the Application and get the neighbours from the Metaverse, or explore the Metaverse Tab in Troux Architect to see the Modules of the Application.

A sensible IT Strategy extract from

A sensible IT strategy (what I have advocated since 2000)

Overview
Some of the key points can be summarised below:
- Access: core systems should be accessible from anywhere via internet protocols (and not require VPNs) i.e. Troux (Metaverse/Team server), JIRA, Confluence, Domino etc. We should discriminate against users out of the office.
- LAN - should not be used for document storage/repositories (that is the function of the Team rooms and other Domino document databases). And ALL documents of record (contracts, deliverables) should reside in repositories. No new people were to be connected to the LANs after 2000.
- Printing - services need to work in all offices (until we can find a remote solution).
- NW Access - local offices should just provide effectively ISP access (plus printing).
- Devices - all devices connected to local NW should be treated as potentially hostile (i.e. we can't control the devices of all Associates).
- Browser - Firefox is browser of choice (was Netscape), IE should only be used when it must be (e.g. some tools unfortunately require it).
- Email clients - Thunderbird or Note (i.e. not Outlook - which should not exist on any business owned PCs). SMTP/POP/IMAP services provided by Domino.
- IM - AOL/AIM is the IM all users should use. People can use what clients they want to (AIM was the default, but won't connect to other services Cf. GAIM, Trillion).
- Office Productivity - we should aim to move away from MS Office (and should avoid purchasing new copies). Especially we should avoid using the new extended document formats.
- Drawing tools - the default tool should be OpenOffice stardraw (or Troux Architect) - Visio should not be the default (and we should purchase copies of it). If it is needed for specific projects they should fund this (6the proprietary format is not a suitable format for communication).

Document management
Notes client (fat client) allows automated replication of documents - it also provides Web access to documents. Documents used frequently should be replicated so that local copies are keep on the client (this significantly reduces the load on the PC). Large documents should typically not be sent in emails they should be referenced i.e. to team room location.

Our default document database on Notes is a very primitive one called a team room - its main purpose is to replace the file system e.g. LAN). It is does not have great control for concurrent editing (locking, check-in/check-out) - but in practice this is very seldom an issue. There is an index of team rooms which provides you a simple drill down access to all team rooms (i.e. it is a table of contents for the team rooms).

Model repositories
Troux team room - should be used to store copies of models that need to be shared or archived.

Other repositories
JIRA - is used for bug tracking, issues tracking etc.
Confluence - is used as a wiki for informal communications (it is NOT where documents or record should reside).

Other newer issues
- Skype should be used for VoIP (but should not be left running as a default IM).
- PDA/Phones - people will use a variety
- Wireless - our strategy for these needs revision i.e. external services/standards.
- Office formats - we should aim at ODF (not Office XML).
- Project - MS Project vs Open project [need to consider]

Special cases
The above does not apply to 2 special cases - SW developers - who needed what ever their project demands, Accounting. Re Development they will need a range of specialised tools/technologies oriented (IDEs, UML modellers, ER modellers, Databases etc.]