Welcome to Solitech-BA

EAM Framework Decision Points to Consider

Have you selected a framework?
Does it support your organisation framework?
Does it support production of the deliverables your stakeholders require?

- Organisation structures
- 'As-is' process maps
- Process reference models
- 'To-be' reference models
- Interface descriptions
- Customisation areas
- Project scope definition
- Process cost vs value tracking
- Application architecture
- Tecnhical architecture
- Network topology
- BAM capabilities
- SOA architecture


Does the framework include productivity tools that ensure:
- Rapid presentations
- The ability to publish reports to the intranet or a portal

Does the tool support some of the known frameworks, for example, TOGAF or the Zachman Framework out-of-the-box?

EAM Glossary

Is the glossary extendible to become taxonomy?
Is the glossary active to enforce a taxonomy?
Can it meaningfully represent architecture models and views to non-technology stakeholders?

Important points to consider when defining your company's architecture:

- Differentiate between people, process and technology
- Create intuitive icons for your industry

Does it support meta-models, for example an ability to configure and tailor models?
Does it support enterprise use, for example multi-user collaboration support?
Does it allow a drill down function, for example conceptual, logical, physical, etc.?
Does it provide mechanisms for linking requirements to EA, i.e. requirements traceability?

Security features

:

Does it facilitate access control, for example different permissions for different roles?
Does its security design support corporate security policies?
Does it natively support report generation?

- Does the organisation make use of general office tools or are they specialised?
- Are the reports customisable?
- Is data presented in document, spreadsheet or slide format?

Does it support a common language and notation?  

Intuitiveness / Ease-of-Use Factors

(This is where many well conceived Business Architecture initiatives languish and run out of steam)

Who should be able to use the tool?

- technology specialists
- business analysts
- ad hoc business users
- line managers (administrative, financial, sales, engineering, specialist, etc)
- trading partners
- contractors and consultants
- administrators
- project managers

What could be done to make it easier to use the tool?

- An easy to follow "process map" guiding the use of the tool
- Online help
- Relevant out-of-the-box architecture constructs, whether it is Business, Data, Applications, or Technology
- Industry typical applications
- Relevant out-of-the-box templates or patterns for constructs, which can help organisations "jump  start"
- Functional reference models
- Industry reference models
- Support for visualisation modelling, for example drag-and-drop and lines that equate to links

Can it be extended or customised and does it provide utilities to do that?
Does it track and audit changes?
Does it provide a way to ensure consistent naming and organising of artefacts?
Can those artefacts/components be easily viewed, used, and re-used?
What requirements are there for use of programmatic languages?

Organisational Compatibility Factors

Internationalisation/localisation capability:

Can the tool be used in all the geographic locations and/or language domains?

Tool capacity/Scalability constraints:

Does the tool have capacity constraints?
What is the size of your data to be stored?
What are the number of files to be stored? 
How many data entries/records should be stored?
What are the "sweet spots" of the tool's design?

Is there an upgrade path beyond the capacity constraints of the tool?

Architecture of the Tool

Consider the following questions: 

Is the repository distributed or central?
Is the repository dynamic?
Does the tool function with multiple industry data stores (for example SQL server, Oracle)

or is storage proprietary?
Is the tool backwards-compatible with prior releases?
Does it allow integration and consolidation of data into a central repository?
Does it include version control?
Is it accessible through a web client?
What platforms (hardware, OS, DBMS, network) does it run on?

Full Lifecycle Support

Consider the following questions: 

Does it provide full lifecycle support?
Does it support various relevant views out-of-the-box, for example

- Business Process,

- Data,

- Applications, and 
- Technology.

Does it support the creation of custom views?
Does it use modelling methods and techniques relevant to this enterprise's architecture practice?
Does is support simulation?
Is the model that it produces executable?

Interoperability Factors
 
Import/Export:

Can it create an artefact inside the tool and export it to other commonly used tools?

Can the users of those tools use the artefact intact?
Can it import an artefact created in another tool, and use it intact?
Does it integrate with other tools?
Does it provide and support industry standard APIs?
Does it use relevant industry standards, for example XML, HTML, produce hypertext, UML, and other industry standards?

Financial Considerations

What is the acquisition cost?
What is the total cost of ownership?
What is the cost of maintenance
What are the costs associated with equipment?
What are the costs for support?
What number of resources are required to keep it up-to-date
What are the administrative responsibilities and time constraints?
Will there be any impacts when introducing the tool into your environment, for example does it require some unique infrastructure?