Characteristics of Effective EA (Revisited)
Below you will see the content of a previous post, reposted for a couple of reasons. One, I had a recent conversation with a client about this topic which brought it to front of mind. Second, I have been having a lot of conversations with clients, prospects, George, and some of our peers regarding the lack of proactive, strategic, forward looking, broad perspective. Instead there seems to be a swinging of the pendulum back to having more emphasis on the tactical, project-oriented assignments for most IT resources. So just a little reminder for our readers…
There are a few characteristics of an effective Enterprise Architecture (as well as IT Architecture) practice and its artifacts that must be established and maintained throughout its existence. In order to be effective, EA and ITA need to influence investment decision-making at the portfolio level. This means being able to show the impact of investment alternatives across the enterprise, on other investment choices (including current investments) and over a longer period of time than just the current and next budget cycle. Regardless of goals, objectives, industry, size, or stage of maturity, these 5 characteristics are necessary for effective EA and ITA to influence the investment portfolio:
Business Driven: In order to be business driven, the EA program needs to involve professionals with an understanding of the operations and the executive leadership of the organization. If you are architecting an enterprise, then your primary audience is the group of individuals with overall responsibility for the enterprise as a whole. Your artifacts need to be able to communicate at the executive level, as well as create a forum for collaboration on the impact of strategy on the operations of the organization. HL context models, relationship maps and strategic capability change analysis are the deliverables that represent this characteristic.
Forward Looking: Too many EA programs attempt first to impact implementation level decisions and projects. While this is not only futile (one an effort is at the implementation level, EA impact is minimal at best), but also potentially dangerous. Without an idea of the long-term direction of the business processes, information assets, business systems and technology, what meaningful and systemic guidance can EA or ITA provide at the implementation level, or even at the design level. The architecture as a whole must be based on a consistent and portfolio-oriented view of how the enterprise will evolve as a whole over time. This only comes from looking 3-5 (or more in some instances) years ahead. Roadmaps are the deliverables that represent this characteristic.
Enterprise Breadth: Many organizations have a history, sometimes successful even, of silo-oriented decision-making. However, as complexity has increased and rates of change have decreased, the impact of silo decisions is being felt by these organizations. And it is usually not a good feeling. To combat this, EA must have an enterprise-wide scope to help senior executives understand the impact of decisions in one silo on other parts of the organization, because within the silo, this is not easily recognized. And for the most part, if this perspective is not maintained by the EA group, it may not be evident anywhere. This characteristic should be represented in all types of EA deliverables, providing the context to link artifacts from other levels of architecture (domain, solution, etc.), as well as planning and development activities.
Maintains Linkages: To increase the impact that the previous characteristics can have on overall effectiveness, the EA must establish and maintain both vertical and horizontal linkages in the participation and deliverables of the program. EA is not responsible for the creation of every planning, design and modeling artifact in the enterprise. But to increase the value of the lower level artifacts, as well as enable the impact of business driven, forward-looking, enterprise wide activities and deliverables; linkages across silos and domains and between levels of architecture must be established and maintained. These linkages are generally represented in the overall EA meta model.
Proactive: As I mentioned earlier, many architecture activities are focused on implementation and project level details, which is too late in the life-cycle to have meaningful impact without the benefit of process and artifacts that reflect the above characteristics. Please don’t misunderstand my message. EA needs to be able to impact the implementation and project level decisions, but not in the reactive way we see it happening in many organizations. By creating teams, process and artifacts that are business driven, forward-looking, enterprise wide and maintaining linkages; EA can proactively impact the mix of projects and the implementation level design, technology choices and integration BEFORE projects are even started or implementation decisions are made.
The true test of EA effectiveness is the ability to change implementation level decisions based on a reflection of what is in the best interest of the whole enterprise. Without these 5 characteristics present, an EA program will struggle with that test.