Why No Business with EA?
So there I am sitting on a panel at the Troux Worldwide Conference a couple of weeks ago, answering interesting questions with some interesting co-panelists, when a thought struck me. “After decades of positioning EA as a discipline for business-IT alignment, why aren’t EA programs more in tune with(driven by, owned by, participation from) the business?”
I’m not just talking about myself positioning EA in this way. Just about every definition you come across, from vendors, consultants, analysts, and practitioners alike; EA is described as being business driven, strategic in nature, and focused on the long-term future state of the enterprise. But within most organizations I engage, EA is found to be lacking significant business drivers, business participation or even any level of credibility from business executives.
So I ask again, Why?
I think that there are a variety of reasons for this, and the exact mix of reasons are probably unique for each individual enterprise. However, I would guess that there are a few factors that are predominant in most organizations.
- Lack of EA leadership within the IT organization. I don’t mean that there are no leaders in IT. I mean that the leadership in IT for EA (let’s face it, most EA organizations are within the IT function) isn’t doing what is necessary to form the relationships and value proposition for EA to be relevant outside EA. They remain satisfied with a focus on IT outcomes – applications, infrastructure, standards and governance.
- Lack of business understanding within IT and EA leadership and practitioners. IT leaders and EA program members must develop an understanding of the core operations, motivational forces, financial model, and strategic plans of the enterprise.
- Lack of translation of business understanding. Some EA practitioners have made the initial investment in gaining essential knowledge about the business in which their enterprise competes, as well as the internal operating and financial models, and their strategic drivers. But the next step is the critical one. They need to create artifacts that represent that understanding in a way that communicates with senior executive leadership.
- Too much responsibility at the project/implementation level within IT. Time and time again, we see very capable EA teams try to gain credibility by helping out as an added resource/technical lead/project manager; only to be given these responsibilities as a permanent part of their charter.
While there are other reasons that warrant consideration (lack of understanding/approval by the CIO, wrong personnel involved, economic downturn); the above represent the factors that demand focused effort to overcome.
What can we do to change this? Here are a few suggestions:
- Read books and industry literature of a non-technical nature about the industry in which your company competes.
- Experiment with different types of high level models that represent your understanding of your business’ current and potential future state(s). There are no commonly accepted formats and nomenclature for these types of models, as they are dependent on the executives you are trying to communicate with. And do not be afraid to have different models to communicate the same thing to different audiences.
- Understand the financial model of your enterprise and how it impacts IT’s value delivery. You must develop a contact in the CFO office.
- Resist project level responsibilities for your EA team. If you have to accept them for a short time, develop a plan with your superiors to instill architecture skills into the project delivery staff.