Five Keys to a Successful Enterprise Architecture Program
From confusion to overly ambitious goals, we look at five causes of EA program failure and how you can overcome them.
By Sree Sundaram
In the recent past, enterprise architecture (EA) programs have been created and developed with much fanfare in most organizations. It has been successful in a few organizations where process, procedure, and adherence to standards are usually critical to mission success. In most businesses, however, beyond the initial blitz of activity in these programs, they have been largely unsuccessful. In this article, I will examine five main causes why EA programs have failed in IT organizations and the five keys to overcoming them.
Cause #1: Confusion
First, what is an enterprise architecture program? Therein lies the first point of failure: confusion about the program and a lack of a clear shared definition. There are varying definitions by architects who adopt different frameworks. Some of these frameworks are more of a classification or taxonomy; others are oriented toward practitioners.
Adding to the confusion, the role of the Enterprise Architect is rarely perceived clearly. To adapt an oft-quoted idiom, “She is all things to some people and some things to all people.” It might sound cliché, but to avoid this situation, the hiring manager should first develop a job description and gain consensus from both the technology and business stakeholders.
Sudden and unanticipated vacancies in technical managerial positions sometimes add to the confusion about the role of an EA. As enterprise architects are typically well rounded (at least) in their technical capabilities, they are sometimes asked to temporarily fill in for vacant technical managerial positions until a replacement is found. Such a solution is tempting and probably beneficial in the short run, but in the long run the EA program does not have a dedicated steward to chart the course.
Cause #2: Suspicion
The second point of failure stems from suspicion by business users and managers that EA is an IT-led program. In today’s environment, EA is a program that is ostensibly “championed” by the business but in reality, initiated by the IT department. The discussion of the wisdom of this practice is a subject of another article. If there is a historical distrust or a lack of faith between IT and business, the EA program is viewed by business as another attempt to wield additional influence without creating an additional value proposition.
Many senior executives (both inside and outside IT) have come to believe that EA is a pure IT program which has some liaison with the business. As a consequence, EA usually devolves into an oversight of enterprise applications. If enterprise architects take on additional roles (see earlier), the devolution gains further impetus until the entire EA program simply collapses into an enterprise applications architecture program.
Cause #3: Lack of Faith
The third problem is the lack of faith in the program by IT. This typically happens when there is a “disconnect” between the visions of senior IT leadership and its ranks. The IT staff views the EA program as another management layer that has been introduced to hamper their productivity.
In some extremes, even the infrastructure team believes that it is not part of the purview of EA. If there is too much interaction with the business, then a perception if developed that the enterprise architect is a “lackey” of the business. As a result, there is a loss of respect and authority on the EA function from the IT side. This is typically the case when IT is so disorganized that any semblance or order brought about by an EA is considered to be playing into the hands of the business.
Cause #4: Leadership
The fourth problem EA programs encounter is ineffective leadership of EA program. Part of leadership responsibility lies with the CIO. More often that not, enterprise architects are given responsibility that is not commensurate with authority. Consequently, any EA mandate is rendered ineffective as there is no “stick” that goes with the responsibilities.
At the same time, a successful EA should keep expectations real on both the business and IT sides of the company. Although it may not be prudent to strive for radical change in IT from the outset, the EA should not compromise on core principles. (Dramatic changes need to be introduced in multiple steps to gradually ease into a culture of methodology and structure.)
Another leadership problem is the lack of an effective framework. Many EA frameworks are in vogue today. These are all well thought out and require significant of investments in time, effort, and money. In reality, are most corporations willing to spend the time and effort to go through a rigorous exercise of aligning with or developing to these frameworks? Usually, the answer is no. The suitability of a framework depends on the unique business situation. For example, a business that has greater accountability for public safety or public health will need a framework that permits tight checks and balances on both business and IT deliverables.
The size of the business and size of its IT budget are significant factors in the selection of the right framework. For example, a small or midsize business with relatively simple production procedures may not want to get mired in paperwork and procedures that are not appropriately proportional to their core objectives. In such a scenario, a well-intentioned but inexperienced enterprise architect can easily derail the efficacy of an EA program by developing cumbersome procedures that are not really suited to the current culture of the organization.
Cause #5: Overly Ambitious Goals
The final reason an EA program has problems is because it is often an overly ambitious, overreaching program. A successful enterprise architect is one who understands the realities on the ground and fashions the EA program appropriately. Implementing a sophisticated framework with all of its checks and balances for an enterprise with limited resources is doomed to failure. There are EA programs that are developed for organizations in which process, standardization, and precision are necessary aspects of their domain (for example, aerospace, defense, nuclear fields). Some programs are uniquely designed for small enterprises. A “one-size-fits-all” approach will not work.
A lack of budget for a large program is also sometimes the cause of EA program failure. In a typical for-profit business entity that can live with a degree of variability in its product offering/service, investing in developing or adapting an enterprise architecture framework is something that they can always put off until next year when they hope to have a larger budget. This is especially true in times of economic stress on the company; the EA program is one of the first to face the chopping block. If not entirely eliminated, the program is so severely curtailed that it fails to function effectively.
Five Keys to Success
So how does an enterprise -- faced with the possibility of EA program failure -- avoid these situations? Although the problems I’ve described may not be all-encompassing, they are certainly the leading causes for most failures in EA program development. Addressing these issues by IT and business would go a long way in developing a robust program. These five simple edicts would be useful for EA practitioners:
- Keep it simple, unambiguous, and realistic
- Keep it always practitioner oriented
- Be ready to show ROI at every stage of the program
- Keep your value propositions specific
- Quantify your benefits as much as possible
Knowing these five keys will help IT leaders and enterprise architects to create and manage a sustainable program that is beneficial to the enterprise.
Sree Sundaram is a senior director of enterprise architecture at Siemens Information Technology Services. He is engaged in optimization and migration of infrastructure from current platform to newer technological platforms that are in line with customers' current and future business needs. He can be contacted through his Web site: sreesundaram.com.