This article examines questions such as:

• Have we achieved what we were set out to achieve with our Enterprise Architecture Repository (EAR)?
• Have we created value through the EAR?
• Have we evaluated the products according to what we value now as important?

Usage Scenarios

We have currently a team of around 30 – 40 people using our EAR to model our business processes and 6 architects creating architectural artefacts across the TOGAF Domains (BDAT).

Business Process Modelling

The process modellers work on our ERP transformation program or on separate business process optimisation projects.
Lessons Learned: We are glad that we have an EAR where our business processes have a predefined home. Equally important is however rolling out training to new starters and people who have done process modelling the ‘old’ way. Most important is to have an Enterprise wide process framework in place to fit all the different projects and programs related business processes together. Without a framework you will only ever end up in point-solutions or project focussed views with no chance to look at business processes across the Enterprise as a whole.

Human Resource Requirements

Due to the extended usage of our EAR we have now 3 EAR Administrators instead of the one admin resource initially. This is due to the higher workload of course, but what it requires is that all System Administrators and ‘Power Users’ share the same knowledge about the foundational principals such as meta-model, library structure and how core features like impact analysis work.
Furthermore other profiles with advanced access rights have to share a common set of guidelines and mapping standards to create EA assets in a consistent way. For example: Knowledge about our APQC PCF, our modelling standards, our versioning standards, the difference between AS-IS and TO-BE.

Access Control VS Roll-Out & Critical Mass

With external consultants coming in, half-knowledge about our EAR has proven dangerous: To satisfy reporting requirements the consultant introduced new relationships altering the meta-model in an inconsistent way. Over 6 month later we are still cleaning up those meta-model inconsistent changes. Giving too much access is probably a cultural aspect, which might not happen in other organisations, but in the initial phases you might struggle to get the critical mass together for an Enterprise wide roll-out, or don’t know the administration/access features well enough, so it’s good to be aware and specifically lock meta model altering access rights down.

Impact Analysis

The architecture team is often tasked with examining ‘what-if’ scenarios.
For example: What if only a single module goes live instead of the entire solution? Questions like this can still not be answered through our EAR. Even though you could customise the meta model to help answer those questions, it would require tremendous discipline to model projects to that level of detail right from the start.

Keeping things consistent

We have a tightly knit architecture team – all the architects sit in the same room as well, which makes it relatively easy to apply the same methodology or synch across the team. However if you don’t have this luxury, it might be good to define tool specific modelling standards before you roll out your EAR. Making changes to existing artefacts is always harder than doing it Right right from the start.

Most important product features

Over 1 year into the deployment of our EAR the following features have proven most important:

• Report generation and information export
• Web browser access with access for everyone in the organisation (using enterprise license, instead of seat license). The saying ‘Architecture is only alive if you can see it’ is very true. You need to be able to share EA assets and views with everyone. Exporting Visio diagrams or PDFs is not going to work as you are constantly updating your artefacts – remember Enterprise Architecture is a living thing. Being able to send out web URLs to specific documents or document versions has proven really useful – no outdated content anymore.
• Visio user interface – Change management and onboarding has been fairly easy given that mostly all modellers have had previous experience with Visio
• Access Control based on user profiles such as
  • EPMO Business Analyst – Read Access to all projects across the Enterprise project portfolio, CRUD access to business related artefacts, mostly processes in the TO-BE and AS-IS libraries
  • Business Architect – same as BA, but across all TOGAF domains
  • Project Analyst – restricted access to only specific project related folders
  • Domain Architect – Same Access as Enterprise Architect
  • Enterprise Architect – Full access, close to System Admin access
  • System Admin – Full access to user, library, meta model and fundamental repository configuration
  • Portal User – read only access to all content
• Library & folder restructuring – We have now several times restructured our library folder structure to satisfy demand and ease of use across
  • AS-IS and TO-BE gap analysis
  • APQC process framework roll out
  • Project based access
  • Avoiding confusion for people with specific project based usage requirements
  • Creation of project and Enterprise wide views

So…

Would we have still examined the same features as we did originally during our vendor selection if we knew what we know today?

Yes and No.
Yes, because all the features we looked at are important still.
No, because we have learned what other features have proven useful and what’s really important and hence additional features would be added and the weighting would be different across all features.