Enterprise Architecture programs and some reasons why the don't reach maturity

Top reasons why enterprise architecture initiatives fail

Organizations may be under pressure to implement enterprise architectural programs for a variety of reasons. Perhaps Internal Audit produced a finding that there were insufficient controls around applications and the metadata associated with applications. Perhaps senior management is becoming increasingly aware of the dependency of their business on IT to be able to provide basic services and want to ensure greatest stability around their technology offerings.

The value proposition around enterprise architecture can be compelling. After all, who would not want greater alignment of technology with strategic objectives? Or want to define value streams for their most significant business offering? The promise of being able to use an application repository to allow for greater rationalization of applications and IT and being able to proactively plan for future IT upgrades?

In the real world most enterprise architecture programs never reach full maturity. Understanding the reasons why before embarking on the enterprise architecture journey allows organizations to decide whether they really want to commit the resources and effort to have a successful enterprise architecture program. Having implemented enterprise architecture programs in multiple settings here are a few of my observations.

Do not position Enterprise Architecture as an IT initiative.

While enterprise architecture is clearly rooted in IT it is a fallacy to assume that EA Should be an IT initiative. I have seen enterprise architecture being located in various locations within organizational structures. The most common is to have enterprise architecture reporting up to either the chief information officer or the chief technology officer as a program. Less common is to have enterprise architecture embedded in strategy and planning, which, in my opinion, is a more appropriate location. Why would I say that?

If you look at foundational enterprise architecture diagrams, you will see enterprise architecture being divided among various domains. Typically, you see four domains; infrastructure at the bottom of the pyramid, solutions the next layer up, information (data) the layer above that, and business the layer above that. In many cases organizations will replace the concept of information with the concept of data. I believe this to be a mistake. Ultimately the role of information architecture is to help an organization transform data into information and ultimately transform information into actionable information.

There is a temptation to begin the enterprise architecture journey at the bottom of the pyramid. Enterprise architecture is often started after the closing down of a major failed project or after an internal audit has come up with findings which require actions. One of the most common of these is that the organization does not have a comprehensive repository of applications.

I am not suggesting that having an enterprise architectural repository is a mistake, however having an enterprise architecture repository by itself provides limited value in the long term. The metadata embedded in the enterprise architectural repository need to reflect the objectives of the organization as a whole. For a repository to be successful it needs to map applications downwards to infrastructure and map applications upwards to capabilities. Those capabilities in turn map to the strategic objectives of the organization. IT will never be in a position to fully define and maintain business capabilities.

Enterprise architecture programs are most often initiated at the IT level who then sell them to senior management as providing capabilities that will provide value to the business. What they most often do not do is to make it clear to the business that a lack of business involvement in the definition of the enterprise architecture will result in a medium-term failure of the initiative.

Understand the role of architects

The architectural roles that provide the most value to an enterprise architecture initiative are enterprise architects, information architects, and business architects. For IT executives who do not have a background in enterprise architecture there is a tendency to move architecture roles down the stack rather than up the stack. In practice this means that there is often an initiative undertaken to hire technical and solution architects rather than enterprise architects.

Enterprise architects are trained to work across the entire domain of an organization, meeting with a business as comfortably as they meet with IT professionals. Enterprise architects help define technical strategy, put in place programs to ensure technical compliance, make the business aware of emerging technologies, and own and define technical reference artifacts.

Solution architects work at the solution level, using the frameworks and reference architectures defined by enterprise architecture as the basis to define the most efficient solution for any given set of requirements. Technical architects work at a technical level such as an operating system, a platform such as Microsoft Office 365 or at the database level. Solution architects leverage the solutions put in place by technical architecture using the principles defined by enterprise architecture to create solutions

Technical and solution architects play a vital role in the architectural framework of any organization. However, to hire a team of solution and technical architects and to believe that you are doing enterprise architecture is a fallacy. Technical and solution architects working in isolation will select and architect the best solution based on their own experiences. Without referenced enterprise architecture standards you run the risk of implementing systems that are suboptimized, may not talk with other systems, and may even use technologies which your organization has decided not to embrace at a strategic level.

Often the justification for creating a team of solution architects is that they will do scope definition and total cost of ownership analysis These are really not a part of enterprise architecture and to make them a part of EA creates the false illusion of maturity within your EA program; these are project management functions.

Understand what you want to do with the information you capture

So Internal Audit came along and had a finding that you did not have a complete repository of applications within your organization. You may have chosen to handle this in a variety of ways. One pattern is to hire a consulting company to come in and create the initial version of your repository. Another one is to reallocate resources to create your initial enterprise architecture repository. Often in the first phase of this is done using a spreadsheet. While there are many mature enterprise architecture applications, they tend to be expensive, and organizations tend to not want to invest in them until they see some progress being made.

As you walk down this journey you very quickly discover that their are questions which need to be answered for the repository to be useful. What is going to go into your repository? Is it just applications or is it technology as well.? If you are a medical center are you looking at your enterprise architectural repository to also be your clinical asset management inventory? How does your repository tie in to your security assessments and disaster recovery planning? What fields do you want to capture and what is the data model best suited to meet your informational needs?

A pattern I have seen repeatedly is organization a spending a year capturing initial data for a repository and then having the business ask a question the repository is unable to answer. One of the most common fields not captured is the type of data being stored in information systems. In the healthcare industry this is critical since patient data needs to be treated with specific regulations in mind. Often people will add a data element on later capturing the type of data, however the reality is that most systems will not just capture one type of data, they will capture many (for example) identifiable patient information, identifiable clinician information and credit card information, all of which are governed by different regulations. Often the mistake is made to try and capture this in one column, when it is a one to many relationship. Additionally having a record that a system stores PHI, does not tell you whether the vendor of that system has access to that PHI.

Knowing what you wish to achieve with the data and information at the time that you define the repository will allow you to more accurately capture the information required to meet those objectives. Conversely not being able to define those clearly in advance will result in data and information being captured that are not actionable and do not provide the level of detail that the business may require. This then gets back to the first point which is the business needs to be involved in helping to define what that was to do with an application inventory.

Ensure you engage the business early

It constantly amazes me when I talk with organizations who have had an enterprise architecture program in place for a number of years and hear from senior business executives that they have never met with the enterprise architecture organization. Rather what has happened is that senior IT executives have taken upon themselves to try and translate business drivers and business objectives into language that Enterprise Architecture consumes. Unfortunately, this tends to be a unidirectional process with objectives being driven down to EA 2nd or 3rd hand, and the resulting interpretation of those business drivers and implementations never being fed back up to the executive level and validated.

This is true not only at the strategic level of goals and objectives, but also in the business engaging in tasks as simple as taking an enterprise architecture capability model and validating that it represents the organization’s business model. Often the result is applications being mapped to capabilities which do not make sense for the organization.

Thirdly it is imperative if enterprise architecture is to reach a state of maturity that vertical segments within the organization meet with business architects and enterprise architects to define value streams. Good business executives define these as a natural process of defining minimum viable products for the service they want to provide was to; mapping them into the EA is a critical step in the final goal of aligning technology and business objectives.

In short enterprise architecture should be both a top-down and a bottom-up activity. Hiring teams of solution architects or putting in place an application repository are not in themselves enterprise architecture. These activities may provide a short-term value but will never deliver the promise of alignment between business objectives and technology without the engagement of the business and moving EA the stack to information and business architecture. They in essence become busy activities with limited value.