Intro

After several re-curring forum conversations I thought I’d could be helpful to document the steps taken in order to procure and establish our Enterprise Architecture Repository (EAR).

Of course this is by no means the only way to find the right EA Repository for you but it worked for us and we are still very happy with our choice.

Context

Probably like many other organisation we started off creating our EA assets in Microsoft Word, Excel and Visio diagrams and stored it on shared file servers and our Document Management System DocuShare.

The problem with this approach – as you know – is that there is no underlying content meta model which semantically links the architecture artefacts. The consequence is that analysis needs to be done manually. You can write macros in Visio, Word & Excel but I don’t think that is time and effort well spent for an Enterprise Architect.

The Team

To get a broader view of requirements across the business I assembled a team comprising the following:

• 2 Enterprise Architects
• 2 Solution Architects
• 2 SOX Compliance Officers
• 1 National Quality Assurance Officer

Due to many conflicting projects and activities and only 1 Enterprise Architect being the ‘business owner’ of the EA Repository, we ran into several conflicting resource schedules. As you can only objectively score if you sit through the presentations  and demos of all vendors, that has been a challenge.

Fortunately, one of the Solution Architects and the National QA Manager were really dedicated, so that we ended up with 3 different scores we could average. I recommend to involve also an IT Operations representative, so that the requirements of the Application Portfolio Management component are represented if that’s a use case for your EAR within your organisation.

The Process

You won’t get it 100% right. 1 year down the track we are using the EAR in ways we didn’t think of, but that’s only a good thing as we are reaping rewards beyond what we have envisioned.

After high level requirements gathering, the process we followed was:

1. Market Research & Product Shortlisting
2. Requirements lock-down & Weighting
3. Product Demonstration & Scoring

Market Research & Product Shortlisting

The company had a ‘all you can eat’ arrangement with Gartner and Forrester Research. That made it easy to execute a quick market research. We also talked to fellow Enterprise Architects and opted to include one product which wasn’t on the Gartner Magic Quadrant.

Gartner and Forrester have quite a comprehensive selection of papers on this topic. The documents we found most helpful were:

• Gartner: Understanding the Eight Critical Capabilities of Enterprise Architecture Tools
• Gartner: Select EA Tools Use Cases Are Not Optional
• Gartner: Magic quadrant for Enterprise Architecture

After reading through the documents, I had scheduled a call with a Gartner Analyst on that topic to clarify my understanding. I asked specifically why a tool like Orbus iServer is not mentioned in the Magic Quadrant paper as it has been recommended to us from other Enterprise Architects and we knew that Cathay Pacific is using it, too and that they are happy with it.
I learned that the Magic Quadrant selection process also includes things like disclosing the product roadmap to Gartner, Gartner specific certifications and customer references. Not all of those have been satisfied by Orbus (trading under Seattle Software) and hence it didn’t make it into the Magic Quadrant. For us not a strong enough reason not to look at this product, especially after it came with strong recommendations and it was fully compatible with our existing EA assets which have been created with the Microsoft Office Suite.

The Magic Quadrant for us looked as per below screenshot at the time of evaluation. I recommend to get the latest report from Gartner if you’d like the latest view.

The Product Shortlist

After a first high level evaluation of the products in the market, research papers and recommendations we shortlisted the following products (vendors):

• ARIS (Software AG)
• Abacus (Avolution)
• iServer (Orbus)

At first, alfabet was not on the shortlist. Software AG has just had acquired this product through the acquisition of planningIT. The Software AG technical representative offered an introduction and demonstration at short notice which fitted our schedule, hence we agreed to have a look at it as well. After the demo it was clear that this product is not what we are looking for in an EA Repository due to its rigidity of the prescribed process and the absence of a content meta model. I also downloaded iteratec’s iteraplan for a quick evaluation but found the tool not very user friendly.

Requirements Lock Down & Weighting

The evaluation group defined the evaluation criteria categories and weighting as follows:

The weight semantics were defined as: 0 – Irrelevant; 1 – Insignificant; 2 – Fairly unimportant; 3 – Somewhat unimportant; 4 – Nice to have (e.g. ease of use); 5 – Nice to have (increased productivity/efficiency); 6 – Somewhat important; 7 – Important; 8 – Fairly important; 9 – Very important (represents key requirements); 10 – Critical/extremely important (failure to satisfy requirements in this category will cause elimination of product)

Our Requirements

ID	Category	Description
1	10	Repository must be shared and accessible by all EA practitioners, Solution Architects, Business Analyst and Business stakeholders
2	1	Must allow for customised meta models
3	10	Existing assets (.ip – process files & visio diagrams) need to be converted and linked into meta-model
4	10	Built-in Version Control
5	11	Integration/Linkage with requirement system
6	11	Integration/Linkage with other systems WIKI, DocuShare, FileFolder
7	8	Must be able to deal with a large number of artefacts (10,000+) & performance tuning options
8	2	Must be able to understand & analyse complex (ontop, links, semantics of an relationship, 1:n, m:n) relationships between artefacts
9	2	Support Scenario (what-if) planning & scenario modelling
10	4	Support multiple/different stakeholder viewpoints & presentations
11	2	Facilitate implementation of business strategy, business outcomes and risk mitigation
12	2	Repository supports business, information, technology, solution and security viewpoints and their relationships. The repository must also support the enterprise context composed of environmental trends, business strategies and goals, and future-state architecture definition.
13	2	Modelling capabilities, which support all architecture viewpoints (business processes (BA), solution architecture (SA))
14	3	Decision analysis capabilities, such as gap analysis, impact analysis, scenario planning and system thinking.
15	4	Presentation capabilities, which are visual and/or interactive to meet the demands of a myriad of stakeholders. Presentations can be created via button click.
16	5	Administration capabilities, which enable security (access,read,write), user management and modeling tasks.
17	6	Configurability capabilities that are extensive, simple and straightforward to accomplish, while supporting multiple environments.
18	7	Support for frameworks (TOGAF, COBIT, eTOM), most commonly used while providing the flexibility to modify the framework.
19	8	Usability, including intuitive, flexible and easy-to-learn user interfaces.
20	2	Draft mode before publishing edited and new artefacts
21	1	Supports linking Business Motivation model ((Means)Mission, Strategy, tactics >>> (Ends) Vision, Goals, Objectives)
22	2	Needs to support multiple iterations of TOGAF (Architecture Capability, Development (AS-IS, TO-BE, Gap), Transition, Governance iterations)
23	2	Support for multiple notations(Archimate, UML) connecting semantics to the same content meta model
24	10	Repository Search and Browse capability for the entire organisation
25	3	Creation of Roadmaps
26	3	AS-IS, Transition & TO-BE state based gap analysis across processes, information, technology, Business reference models, application architectures and capabilities
27	10	Reverse-Engineering/Introspection Capabilities for Oracle eBusiness Suite/ERP
28	6	Ease of Editability of meta model relationships
29	2	Support for linking Strategic, Segment & Capability Architectures across architecture models, processes and roadmaps
30	6	Ease of Editability of meta model objects & attributes
31	3	Strategic, Segment & Capability architectures need to be referenceable across all models, building blocks and projects
32	8	Lock-down/Freezes on changes
33	8	Role based edit/view/read/write access restrictions
34	5	Administration & Configuration training will be delivered by vendor
35	10	Price within budget
36	3	Supports “is-aligned-with-roadmap” analysis via button clickc
37	7	Supports library concepts (lock down/freeze) for reference models, refrence architectures, Architecture/Solutions Building Blocks
38	9	Vendor has proven capabilities/support for change management efforts associated with the roll-out of a EA tool/repository
39	2	Supports multiple notation standards (Archimate, UML, TOGAF)
40	10	Preserves meta-data of exisiting FXA process model (mappings to Software and applications are imported and semantically correctly mapped)
41	10	preserves & understands meta-data of exisiting FXA visio models (BRM, Capability, etc)
42	11	Integration with Portfolio Management tools and Project Management tools
43	12	Alignment of what FXA needs with Gartner analysis
44	12	Provides technical/customer support during Australian business hours
45	12	Vendor pays attention to FXA requirements and business environment and build demos, questions & dialogues with FXA around it.
46	13	Must have different role-based user access levels for read, write, administration and public (browse) for different types of assets
47	13	Must not allow users to sign up for inappropriate level of access without permission
48	13	Writes access logs for successful, failed logon and user profile/role change logs
49	10	Supports the modelling, documentation, query & analysis of Customer Touchpoints

The Result

Once we finally received a quote we realised that it was beyond our budget hence we had to remove ARIS from the shortlist.

After use case demonstrations from the remaining vendors the evaluation team scored independently and came up

Abacus TOTAL 2399
iServer TOTAL 3582.2

This concluded the evaluation and made Orbus iServer a very clear choice for us.

Next Steps to Consider

• Decide a content meta-model (TOGAF VS Archimate)
• Repository structure & library setup to support automated roadmaps and gap analysis and to support projects
• Import Application catalogue (application & interfaces, live date & status) (AS-IS)
• Import existing EA assets (AS-IS and TO-BE): processes, Business Functional Reference Model, data models

Things to be aware of – Before you jump

• Resourcing: There will be people necessary to administer, maintain and continuously update your Enterprise Architecture repository. Whenever there is a a large change coming which impacts your EAR, you need to understand that this can be a full time job for a little while
• Licensing: Make sure your business case caters for growth and additional licenses. In case of iServer you need Visio and iServer seat licenses.
• Training: Ensure you got a team that you can work with to roll out training. Especially across different domains: Business (BPMN, process modelling guidelines) and meta model extensions (eg Interfaces, RICEFW) and the correlating relationships.
• Publish guides and reference material (we found a WIKI most useful!)
• Standards & Reference models: You will have to spend time and effort to define your own standards (eg subset of BPMNv2.0 or APQC PCF)