Selecting your Enterprise Architecture Repository


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.


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.

Screen shot 2014-06-11 at 8.57.54 PMGartner 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.

Screen shot 2014-06-11 at 9.29.06 PM

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:

ID Description AVG Weight
1 Repository & content meta model – capabilities & fit 8.8
2 Modeling – support for business process and EA modelling 9.4
3 Gap Analysis & Impact Analysis – ease of use, capabilities 8.4
4 Presentation – automatic generation & capability 7.2
5 Administration – system and user access administration 6
6 Configurability –  usage, access rights, output (not including content meta model) 6.8
7 Frameworks & Standards support – e.g. TOGAF, eTOM, BPMN, reference architectures 6.6
8 Usability – Intuitiveness of UI and administration 8.4
9 Adoption/Change Management – effort to roll-out and adopt 9
10 Fit for Purpose (Use case eval, risk, compliance, business requirements, customer centricity) 9
11 Extensibility / Integration ability with other systems 7.4
12 Vendor: Interactions – Responsiveness, quality, detail, professionalism, support 6.2
13 Supports Risk & Compliance (e.g. JSOX) tasks/initiatives 6.8
14 Supports Quality Management (ISO9001) tasks/initiatives 6.6
15 Gartner Research results & recommendations for suitability 4.6

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)

6 thoughts on “Selecting your Enterprise Architecture Repository

    • Hi Keith,

      Thanks for your question.
      There is no particular reason. The Gartner report back then read that there is still mixed user feedback on the strength of the product in certain areas. We had a very tight timeline due to the fact that a major transformation project was about to kick off which we wanted to utilise to get our EA assets created.
      Understanding now better the importance of Visio for our organisation in regards to Change Management, I probably would take V-Modeller into the mix if I had to do a EA repository/tool selection again.


  1. Hello Andreas,

    Thank you for this thorough and insightful post. The architecture team I’m a part are about to undertake a similar exercise, and this post is extremely helpful.

    Which content meta-model did you end up choosing? TOGAF? Archimate? Custom? Other?

    I’m in a position at present to evaluate the meta-models available and decide on the best one. My personal preference would be Archimate, however, I’m aware that there are gaps between the two meta-models and in Archimate which The Open Group have tried to address with the efforts made as part of the “Harmony” project. So it would be good to see which one you went with and if it caused you any issues down the line?


    • Hi David,

      Really good question. We actually spent quite some time on selecting the content-meta model.
      We were looking into both TOGAF and Archimate as a baseline.
      TOGAF seemed too high-level, Archimate way too low level.

      I considered the meta-model customisation capabilities of our EA repository and what type of conversations (Strategic (incl. Drivers/Goal/Objectives) VS Business VS IT) I would like the EA team to have and who my main stakeholders were.

      We have then decided as a group to use the TOGAF meta-model as a basis and added the necessary modifications to that. The add-modifications were Interfaces (Logical & Physical) as well as Customer Touch Points (BPMN Task) and Reports attached to a BPMN Sub-Process or Task.

      One decision I would re-think now was the fact that we removed the TOGAF concept of ‘Business Service’, because no-one in the organisation talked ‘Business Service’ unless they were referring to a department called ‘Business Services’. That alone caused quite some added relationships as we now needed to re-wire relationships between Process/Actor and Information Service/Logical Application Component.

      The fine line to walk I guess is to keep the meta-model customisations to a minimum, but keep the meta model as business relevant as you can.

      Hope that helps. Please let me know if you would like to discuss further.

  2. Fantastic article. We are assessing iserver and Sparx and I am of the view that EA tools should serve a larger purpose for the IT community and help in those intractable discussions rather than just be an architect centric tool. To me the publishing feature is quiet attractive. The question I however have is after having used this tool for some time now, what do you see are the limitations of iserver and what advise you would give for EA teams going into a green field implementation. Guess it’s more than just a product question but am eager to learn from your mistakes.

    • Thanks Vasu – great questions.

      Just to clarify, I am not talking only about IT Architecture here, we have used iServer as true EA repository across Business Architecture, Information, Applications and Technology.

      Some of your questions have been answered in the follow-on post:

      The biggest task was to model ‘What-If’ scenarios quickly, for example: what-if we outsource entire finance operations AR/AP/Cash Management/FA – how many people would we require and how much would it cost? What impact would it have if we switched from Average Costing to Standard Costing? Or what if we do a partial go-live of our ERP migration programme, running 2 ERP systems in parallel and keep all customer facing functions still connected to the legacy ERP, what impact would that have on order entry and fulfilment and complexity, how would stock level get synchronised etc?
      We used to lock our selves away in a meeting room for a week to answer those questions and examine different options.

      I am not sure whether that’s a problem of the EA repository though. iServer was capable to do what if scenarios, but the up front modelling effort to answer random questions would be huge.

      Hope that helps.
      Please let me know if you have further questions.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s