Enterprise Architecture - Common Mistakes by Beginners

Acknowledgements

Thank you to everyone in the “TOGAF for Architecture” group who contributed to this article.

This article concentrates on common mistakes made by Enterprise Architecture beginners and advice on how to be a better EA, and have a better Enterprise Architecture practice.

Lack of Understanding

- Not developing an effective understanding of the key stakeholders and their motivations.
- Not knowing that other disciplines have great material (i.e. Systems Engineering is very rigorous but not necessarily suited to enterprise architecture).
- Trying to do even IT-architecture (let alone a proper 'architecture of the enterprise') without a very solid understanding of 'the business of the business'.
- Lacking the business skills.
- Going by the book only, not taking some courses on EA and thus losing the opportunity to really understand the concept and getting feedback from experience EA practitioners.
- Not understanding that Information Systems are the prime tools to manage and operate an organization. In other words information management is the focus of EA.
- Inventory errors (confusion about components and classifications).
- Within an EA team, the strengths and weaknesses of the staff have to blended and directed to leverage strength and mitigate weakness. if the team is inexperienced, then the problems are compounded.

Lack of good judgement

- Treating EA as a project (rather than as an ongoing capability).
- Need to be more aligned to business needs at times rather than theoretically perfect approach to solve a problem.
- Stakeholder errors (confusion about the 'real' stakeholder, too much/too little time with the right/wrong stakeholder).
- Not having the insight to draw upon multiple methodologies in the tailoring phase to create useful artefacts.
- "Deliver white éléphants". A recent EA projects in public sector with easily two thousands person-days investment and the solution is not used today. They made a damned good and costly picture of the organisation at that time, but it didn't evolved and it's now put on a shelf. Too much unusable documentation. It's a pity for ratepayers and don't give good press for EA projects.

Failing to perform due diligence

- Failing to realize that some EA work is already going on in the company but under a different name and as a consequence failing to interlock with them.

Failing to Plan

- Not developing a communication plan to address the concerns of those stakeholders.
- Failing to understand how EA is IT centric! (it's the IT assets, which - due to complexity - require architectural attention in addition to regular planning work) and ending up making EA too general and diluted.
- Adopting a specific EA framework without any tailoring and thereby preventing the EA practice from delivering 'fit-for-purpose' architecture. Instead, it would become a 'systematic' replica of documentation.
- Selecting a methodology and applying it without tailoring it to the near term objectives.
The type of project requires immediate business benefits quickly or the project will be unplugged rapidly. It’s a fact. Thinking big too fast enters in tedious project that never finish or brings any result. EA has to evolve as the benefits it brings. Reaching a first phase that returns benefits even to one only or few business units is preferable.
- Defining a serial process, when an iterative process is needed.
- Allowing the stakeholders to have fuzzy scope/purpose/objectives for the EA work.
- Not realizing that the time frame between the as-is and to-be models can or should have interim steps with their own gap analysis.
- Trying to do the whole architecture in one big multi-year hit (rather than as small-scale actions in context of a larger picture, and in conjunction with existing change-projects).

Failure in prioritization

When you take an organisation verticals (HR, Finance, IT, Marketing) trying to move through an entire vertical in the Business Architecture for example and then moving to Data Architecture in the BDAT stack. Problem is the effort involved in fully defining the enterprise at the business level is usually so great and so costly that stakeholders get scared and pull the plug before ever moving to the next level. Whereas if you take the vertical zig-zag you explore one line of business or business capability in all BDAT levels, then repeat for other lines of business, zig zagging up and down. Doing this allows you to bite off chunks of Business capability that can be tackled in a reasonable amount of time and cost and lead to tangible results quickly. This encourages the stakeholders with real results that they want to see more of.

Failing in Communication

- Failing to set and communicate some guiding principles
- Lack of Information brevity. Creating too much information for a time-poor audience
- Use of architecture jargon, and a lack of use of familiar business terminology
- Failing to understand the significance of confidentiality. Many business plans are kept confidential and can't be reflected in widely distributed material (like EA artefacts) so appropriate management is needed. A symptom of this is the inexperienced analyst / consultant who doesn't grasp that the business manager they have engaged with may not be able to tell them the whole story due to confidentiality.
- Not tailoring the communication artefacts to the expected audience and the frequency of delivery
- Selecting tools that are difficult to publish to corporate websites
- Not defining or publishing a taxonomy (how artifacts relate) or an ontology (artifact definitions and uses) 

Failing to Market

- What is an Enterprise Architecture – Poor Education to Stakeholders about what value EA will provide in the long run.
- It's hard to make things change and change can seriously hit the bottom line so resistance to change comes with the territory. You're now dealing with people that make decisions and that carries responsibilities. I try and respect that, and understand that the current state is often a consequence of a myriad of decisions taken in isolation many years ago that were probably right at the time. Warm people up to new ideas, talk over coffee, and don't avoid the difficult stakeholders. Be prepared to sell your ideas/findings in 30 seconds or 30 minutes - these CxO types are busy. I have no problem walking people out of the building for a couple of minutes of airtime! 

Failing to Execute

- Concentrating on the as-is (the "we have to understand where we are before we can plan to move forward" fallacy)
- Failing to interlock properly with the business decision makers (often - paradoxically - by creating a "business architecture" which is how the EA team think the business ought to look but is actually detached from actual strategies and plans).
- Trying to do too much all at once. EA is something that evolves. A key to success is to identify the aspects of EA which are important to support planned / intended business change and focus on them.
- Not selecting, modifying and creating a set of reference architectures (part of tailoring)
- More Change or Transformation Centric: Advisory based on change rather than EA as a base recommending change (Considering Customers, Organization as a whole, Departmental level changes and last but not the least Decision at various levels aligned to Organizational Goals)
- Process rigidity (forcing the 'correct' sequence) and errors (can’t start, can’t finish, get stuck)

Failing to Mitigate Risk

- Thinking risk is not concern of EA 

Failure in Governance

- Failing to implement effective governance
- Reinventing the wheel when reference material (architectures) already exist
- Trying to act as the 'architecture police'
- Trying to tell solution-architects how to do their job 

Failure in Information Management

- Not creating reusable artefacts when documenting/defining the enterprise
- Lack of Repositories for EA Artifacts – Visualization of Process and Data Interactions and relation to organizational Goals at various levels can be accessed at certain repositories and further constant updates in Enterprise Architecture is not there in relation to recent goals and objectives

Quality Issues

- Failing to customise (and be pragmatic about the use of) a methodology or framework
- Deliverable errors (artifacts at the wrong level of detail, wrong focus, poor execution)

Lack of Emotional Intelligence and Perception

- Inability to understand the "human psyche"
-  Stubborn in their beliefs and fail to empathize with management and their superiors
- I know it all philosophy, trying to show they are smarter, trying to show the light to everyone in the company from the CEO downwards
- Visualization of a holistic view- EA gets focused to silos and sometimes considered as an increment to IT Architecture
- Ivory Tower Architect syndrome: EA advisory and consulting is not consistent and aligned to Goals and Objectives of an Enterprise
- Vanity/arrogance, thinking that knowing EA makes you better than the business/IT people that hired you, thus not really listening to them and doing your EA.
- Non-architect mind-set. In other words, the architect should adopt the mind-set that enables him/her to capture the 'full picture' and 'long-term' approaches rather than 'on-spot' solutions.
- A belief that Enterprise Architects should be telling the business stakeholders how to enable their business capabilities.
- Lack of soft skills of the practitioner

Some good advice from experienced EAs

- Get good architectural principles to start off with. Standards, policies, patterns etc. can take a very long time to collect. You can start to govern with principles as an absolute minimum. Anything less is sage advice and wisdom. Collect the others as you go along, and get the right people to own them. 
- Communicate with Purpose
- Be a good "political" leader. Try not to be abrasive, keep egos out and work out good solution acceptable as a team; do not seek "self glory"
- Follow the budget. EA is hard without a solid mandate and the best way to ensure that is to align arch governance with project governance - budget milestones are a great way of ensuring projects deliver.
- EA is about bringing business value through IT. If you endeavour on 1+-year efforts on defining the EA, you're on the wrong path. Do the 20% that gives you the 80% of the answers needed.
- Keep it Simple
- Stay evergreen - yourself and your EA. Constantly listen to the business, listen to the IT, and ensure that your EA is giving value also today. Govern hard when it makes sense, but listen to when the EA is out-dated, and modify it to still meet needs.
- Adopt and Adapt 
- Don't worry about failing, and fail fast when you do. Second time around you'll do a better job by learning from your mistakes. The hard fact is a lot of EA teams struggle the first time they try. Divide and conquer can work.. Keep your raw data, take lots of notes, and take time to understand why something isn't working.
- Use their language. By all means geek out when you're talking to your peers, but when you're talking to your stakeholders talk to them in their language. Words like "(business) service", "product" and the trinity of "Vision/Goals/Objectives" mean different things to different people. You have enough to sell them, don't waste it arguing what a Product is.
- Love the Ops team. The teams running the systems day to day are usually the closest to them and can be a goldmine of information for your current state analysis.
- Don't ignore the Project Management Office. They often have a great view of all the finance spend and you can often find the guerrilla IT lurking in far corners of some functions.
- Enable, don't disable projects. I've worked with EA's who love to say no. I've worked with better ones that suggest alternatives, or point out opportunities to help projects move forwards.
- Use a model and build a repository. Don't get hung up on which one - they all have their strengths and weaknesses . Unless you have a real need don't make it more complicated than it needs to be. It doesn't need to be fancy. Excel is better than nothing.
- Keep track of your architectural debt. Waivers are a fact of life in EA. If a programme isn't implementing your "target" architecture for good reasons (like time or money), try and at least steer it in a way that increments the capability in the right direction and can be easily replaced when the time comes. 
- Enjoy the job. Not many people get to solve problems and attack hard challenges all day.