First things first: A TOGAF certification alone, does NOT make anyone an Enterprise Architect. There you have it.

Inspired by a recent article on linkedIn (which seems to have been removed now) I started to think about how we can get back on track bringing clarity into the language around Architecture roles. At the end of the day, a role title should help you communicate what you do and what your circle of concern is. This in turn brings clarity and value to the organisation you work for.

Clear communications is key in all our relationships. With our family, kids and in business. Ambiguity and confusion makes communications and hence relationships more difficult, can cause stress and waste time and money. In IT we see lots of ambiguity and confusion created – either through marketing material or through people who want fancy job titles. I remember meeting my first ‘Enterprise Architect’ at the W-JAX in Munich in the 90’s. I loved his title, he was absolutely an expert, but at coding in Java 2 Enterprise Edition. His session didn’t talk about business strategy, competitive analysis, market forces, business capability roadmaps or sales & operational planning processes. See where I am coming from?

The ambivalence in IT can be mind numbing – SOA, Cloud, API, Architecture roles are just a few to name. Marketing departments wanting to create a ‘me too’ in a specific field even though they don’t have an offering, which then creates confusion. An example is when back in 2006 AWS started to have ‘Cloud Computing’ conversations, simply utility based pay-per-use computing resource consumption. Then VMWare came along wanting to be a ‘me too’ coining the term ‘Private Cloud’ for something that was merely infrastructure virtualisation. And voila: ambiguity created! The result? Today you need to spend 15 minutes if you talk ‘Cloud Computing’ just to establish the context: IaaS, PaaS, SaaS, Private, Public, Hybrid or do you just mean infrastructure virtualisation really – and there are plenty other examples out there.

The author of above article on linkedIn has done a stellar job, up to the point where he introduces the term ‘Enterprise Solution Architect’ which is exactly the reason why the confusion started in the first place.

‘Enterprise’ Architects, meaning architects with the word ‘Enterprise’ in their title are plentiful, TRUE Enterprise Architects are only few. I meet many so called ‘Enterprise’ Architects throughout the year, unfortunately most of them lack

• Involvement in implementing their companies’ strategy
• Involvement in strategy workshops
• Meetings with executives on a regular basis to discuss strategic initiatives
• A business capability or strategic roadmap
• Involvement in business transformation programmes – neither actively or as a steering committee member
• Rarely understand more than 1 or 2 business and technical concepts on a 101 or 201 level (eg S&OP, Order to Cash, accounting, infrastructure, integration, information modelling, business process modelling or applications) to present the necessary architectural options and ramifications for the business.

Architects who lack above characteristics simple DO NOT make an Enterprise Architect, they are perhaps Technical Architects working in an ‘Enterprise’ instead. Technical Architects look after applications, data stores or infrastructure for example.

Developing into an Enterprise Architect requires multiple years of learning all different aspects of the business and the industry. I don’t see any other way a seasoned EA getting her job without being prepared to be the dumbest person in the room – in many meetings, over many month or even years. The resilience, ability and willingness to learn and doing so is paramount – cost centres, deferred COGS, SOX compliance, consignment notes, recovery, pick release, ship confirm, POD, service route optimisation, freight cost, sales and operational planning  – there’s lot to learn.

Here is an attempt to categorise Architecture roles graphically:

In summary, the important points in my view are:

• Solution Architects are allrounders and the vital and necessary glue to deliver successful business outcomes
• Solution Architects overlap with all other architecture roles. The reason is clear: In order to solution the right business outcomes you need to understand the Enterprise Context, strategic roadmaps, industry and technology well enough to have a meaningful conversation with both the business and the technologists in your organisation with the aim to ensure successful delivery
• There can be other Architecture roles focussed on Information, Security, Data or specific Domains
• There is no need to confuse things with the word ‘Enterprise’ such as ‘Enterprise Solutions Architect’. All solutions, projects or capabilities life automatically within the Enterprise Context
• Organisations are different, which means above categorisation is not set in stone but a guide. The scope of each architecture role can be more or less focussed on aspects such as projects, technology, business, strategy etc. There can be many reasons for this, number of architects or the lifecycle stage of an organisation (see STARS Framework ) for example.

Using above categorisation instead of business card titles helps me better understand where architects are sitting within the Enterprise context, their circle of influence / circle of concerns, what topics to prepare for, how to best communicate and the areas I can learn from my interlocutor (I had to Google that word first :)).

Keen to get your view.

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.

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

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)