Recognizing a need to increase awareness of Enterprise Architecture (EA) and related risks, I reached out to a few expert connections. Enterprise architecture is an important topic to organizations from executives, to IT/business resources, to customers, at all levels and around the globe. This blog post features content from three EA experts, from Canada, the United States and the United Kingdom.
Before explaining what enterprise architecture is, Regine Deleu provides a brief history lesson.

It is only within the last 20 years or so that we have begun to develop an art and science for identifying and defining graphical and textual descriptions of Enterprises. Until that time, whatever art and science we had pertained to various unconnected systems within various departments within the Enterprise, for example, organizational design, and/or systems development, to create or do something. Nothing was cohesive.
Were Enterprises never architected? Yes, but they were successful relative to other non-architected Enterprises. Moreover, the pace of change was slower in the Industrial Age compared with the Information Age of today. Contemporary Enterprises have to be able to adjust much more rapidly to meet changing demands in the face of global competition. This makes it critical to have readily available descriptive representations of the Enterprise to use as a basis for making change and achieving goals.

What is enterprise architecture?
Here is how Regine answered the question:
An enterprise architecture is an invaluable communications vehicle that consistently conveys in a precise, accurate fashion, business items of importance, including assets, direction and intent. Enterprise architecture products or artifacts are used in planning, designing and implementation of enterprises. It’s “consumable” by both business and technology stakeholders. Successfully capturing the value of an enterprise architecture is very achievable, if you approach the task in a thoughtful, guided fashion.
Enterprises utilize information technology for their business. There are many projects involved and afterwards there will be continuous operation and ongoing support work. Enterprise architecture involves a lot of different technologies, different people, different infrastructure and many other factors, and managing it all is becoming very complex. Risk management on our enterprise architecture is one of the big topics enterprise architects and executives should care about.
There have been pragmatic guidelines for managing IT risks, but there are not many formal quantitative methodologies of how people should manage their risk. It consists of a lot of human and social factors.
The purpose of enterprise architecture is to optimize fragmented manual and automated processes into an integrated environment such that the enterprise is responsive to change and supportive of business strategy. In order to succeed in today’s business, it is imperative to effectively manage and exploit the capabilities of various technology systems spread across the enterprise. They must integrate with the strategic vision and adapt to the ever-changing needs of the enterprise.
According to The Open Group Architecture Framework (TOGAF), business architecture is a prerequisite for architecture work in any other domain—data, application and technology—as it demonstrates the business value of subsequent architecture work to key stakeholders and business sponsors. Enterprise architecture aligns the technology supply to the demands of the business. In doing so, it optimizes the service portfolio of an enterprise. As the bigger picture gets clearer, it will be easier to identify the projects that contribute to the business strategy of an enterprise. Architecture improves the quality of individual solutions and simplifies their development and maintenance.
When implementing enterprise architecture you need to have a development methodology in place. TOGAF Architecture Development Method (ADM) is an iterative development methodology to deal with complexity. There are several types of iteration, namely:

• The Comprehensive Architecture Landscape – This is the typical waterfall approach.
• The Architecture Development Iteration – Different phases are repeated non-sequentially.
• The Architecture Capability Iteration – The architecture capability is redefined after visiting steps in other phases.
• The Rolling Wave Approach* – This type of iteration co-exists best with an agile development methodology. Here the phases are implemented in increasingly bigger waves going forward with each iteration.

A significant aspect of the issues around enterprise architecture and agile methodologies are the differences between top-down and bottom-up architectures. To “soften” these two approaches is to end the perception of architects as obstacles to project. Enterprise architecture needs to evolve over time. The Rolling Wave approach enables you to act on concrete feedback that you receive when you try to actually implement it, thereby enabling you to steer the development.
Also, according to some surveys, enterprise architecture points to “people issues” being the critical determinants for success or failure. My experience is that the best enterprise architecture or agile approach is to work closely with the intended audience, both business and technology, so that they can leverage the common infrastructure, and to help build the project efficiently and effectively.
* Rolling Wave Approach is a term used by Regine Deleu.
Some enterprise architecture risks
Here are a few enterprise architecture risks provided by Regine you need to be aware of.

• Stakeholders have no understanding of enterprise architecture, and therefore will not support it. This happens when the stakeholders don’t participate in the enterprise architecture program. Another reason can be that the enterprise architecture artifacts are not used in projects, and as a result management questions its value. A solution is to educate and communicate the value of enterprise architecture to all stakeholders prior to the start of an enterprise architecture program.
• The “ivory tower” enterprise architect approach. With this approach you run a high risk that most stakeholders will not buy in. The primary job of an enterprise architect is to lead the EA process rather than to impose the content on the organization. Form an architecture board which governs the implementation of the enterprise architecture and is a representation of the key stakeholders in the architecture.
• A chief architect who is an ineffective leader. They may understand EA well but lack leadership skills that even a good organizational structure and staffing levels cannot overcome. This results in a chaotic architectural design, lack of progress or clarity of direction. The best solution is to replace such a lead architect by someone with strong soft skills such as enthusiasm, communication and passion, as well as being well respected and strategically minded.
• Not establishing effective governance early on. Governance processes are required to identify, manage, audit and disseminate all information related to architecture management, contracts and implementation. If you do not establish governance processes from the start, you run the risk that everyone will have developed their own working style, that there are no monitoring and audit tools available to guide the architectural design. Therefore you have a high risk that the program will fail. As an enterprise architect, you must resist the temptation to wait for more architecture content before setting governance processes and instead develop content and governance in parallel.
• Communication problems. The value of enterprise architecture is often indirect, so a good and continuous communication on the value and the progress is vital for the success of the program.
• Focus only on technology. This enterprise architecture approach is still in use in some organizations and is even narrower in scope than technical architecture. Enterprise architecture is much broader as it includes business, information and solutions architecture. When technology and business goals are not aligned, you have the risk of non-technical people trying to make technical decisions while enterprise architects become too reactionary and tactical in response to projects.
• Doing the baseline “current-state” architecture first. This does not always need to be a risk, it will all depend on the goal of the program. But when enterprise architecture is used for merging enterprises or the design of a new enterprise vision and strategic goals, then you should not start with the baseline architecture. The enterprise architecture provides prescriptive guidance but current-state architecture does not, this will result in a delayed delivery of the enterprise architecture value and hinders the creation of good future-state architecture.

Gaining a deeper understanding
I also asked Sharon C. Evans and Matthew Ford Kern to provide readers with a deeper understanding.
Sharon organizes EA risk factors as follows.
Organization-specific risks:

• EA initiative funding deficiency
• Actual benefits are less than planned benefits
• Lack of relevant resource skills
• Project too large and/or complex
• Inadequate infrastructure for implementation
• EA goals not aligned with business goals
• Internal politics
• Change management
• Absence of architecture governance practices
• Slow diffusion of process ideas
• Lack of senior management EA commitment

Competitive risks:

• Lack of comparative advantage
• Agile competition

Market risks:

• Unplanned legislation changes
• Environment changes
• Vendor stability

Technical:

• Inadequate business process management
• Use of proprietary standards
• Modification of EA frameworks
• Introduction of increased/improved standards
• Use of immature technologies and products
• Absence of solution building blocks
• Lack of traceability in solutions continuum

I use each of these in a chart with these options: Defer, Explore, Increase, Decrease, Grow, and then I coach clients through the decisions. I force them to do this in 15 minutes or less as I want a “gut check”, then we go through and discuss the ones where they truly were guessing, or ones that were alarming to me, or caused me to be surprised. Note: I’ve 2365 documents on the subject so the above provided list is from one of the simplest charts I give my coaching clients when they are getting started (read most elementary). I also have a method I use whenever I’m in the “rent-a-chief-architect” role, and that I have been working on inside a Kindle Book that is scheduled for release 1Q 2013.

As for Matthew, his comment on the subject of EA was:

Good categories Sharon. A full risk list would probably approach 1,000 lines. In enterprise architecture, there are different kinds of risks to different things (e.g., risks to the strategic plan, portfolio risks, risks to the LOB or value chain, risks to programs, risks in the repository and collection of artifacts, risks in different artifacts). A classification system for all the kinds of risks will help in your success, I think. Within LinkedIn I have established an EA Survey group. In coming months we may have some related findings to share with readers of this post.

My sincere thanks to Regine, Sharon and Matthew for contributing to this post.
As always, comments welcome. Here’s a few links and thoughts to further help you explore EA and consider potentially related risks in your organization; ideally:

1. everyone is aligned on the definition of EA (e.g., four well known experts put to task, What is Enterprise Architecture?, Information Management magazine)
2. EA is used to steer decision making (e.g., Gartner IT glossary: Enterprise Architecture, Additional research here)
3. EA helps determine how to most effectively achieve current and future objectives (e.g., SearchCIO definition: Enterprise Architecture)
4. EA utilizes a related comprehensive framework that among other includes guiding principles and is about more than technology (e.g., What is Enterprise Architecture?, National Institutes of Health)
5. EA helps in translating business vision and strategy into effective enterprise change (e.g., Enterprise Architecture, Wikipedia)
6. your implementation of EA considers the top related methodologies (e.g., A Comparison of the Top Four Enterprise-Architecture Methodologies, MSDN)
7. your EA program is robust and forward looking and helps drive communication, collaboration, transformation, innovation and flexibility for the future (e.g., Enterprise Architecture, Forrester)
8. your not without EA and facing unnecessary risks (e.g., Enterprise Architecture: Absence of EA and Risks)
9. EA helps you reduce risks (e.g, Does Enterprise Architecture reduce risk?, LinkedIn survey)
10. your EA investment is worth it and you manage risks inherent to developing EA (e.g., Enterprise Architecture increases project risk … but it’s worth it, MSDN Blogs)
11. you list EA risks and know your top ones (e.g., 8 Enterprise Architecture Risks, Simplicable)
12. you have a related center of excellence (e.g., Enterprise Architecture Center of Excellence)

Ron Richard, I.S.P., ITCP/IP3P
linkedin profile