CEB Blogs


IT Enterprise Architecture

Don't Strive for a Seat at the Table

Despite the allure, functional teams don't always need that seat to do their jobs well

Meeting TableThose working in corporate functions anywhere in a large company must always find a balance between two competing aims.

First, they want to support those in the line that are actually making money for the firm but, if all they did was try to answer every question and say “yes” to every project they were asked to work on, it would be unlikely to help the business at all.

So their second job is to coach, coerce, and coax (among other tactics) better decisions from line partners than they may otherwise make, especially in their desire to hit short-term targets and with an often limited view of how their decision will make a difference to overall corporate goals.

Sometimes functional employees can go too far and succumb to the siren song of their own importance: “If only they would listen to us…” and so on. It’s certainly true that corporate functions should do more than just take orders but a balance must always be found.

One common phrase about the desire to work more closely with line partners is that functional teams want a “seat at the table,” or a way of helping shape decisions before they’re made rather than having to try to support initiatives that haven’t been thought through as well as they might.

This is certainly a worthwhile idea, and should produce a more achievable initiative that will do more to benefit the company (i.e., it should cost less than it otherwise would and it should do a better job of contributing to corporate strategic goals).

Enterprise Architecture and a Seat at the Table

This need for balance applies to the world’s IT functions as much as any other part of the business, including enterprise architecture (EA) teams. Their job is to describe the design of an organization, including its operations, information, systems, and technologies, and then use that understanding to reduce technological complexity, speed up the completion of IT projects, and improve employees’ productivity and collaboration.

EA is an immature discipline, and with a mixed record of success. And this means the tenure of EA groups can be short-lived. CEB data show that over the past two years, 28% of EA groups have been disbanded or demoted, and that, on average, low-performing EA groups are disbanded 13.5 months after inception.

So we often hear when talking to EA groups in the CEB Enterprise Architecture network that “getting a seat at the table” is a prerequisite to better understanding — and influence over — business plans.

But if they’re not there today — and that is the case for most EA groups — it’s worth assessing how realistic an aim it is at all. Or, put more positively, what will it take to achieve that seat? The following are some reflection questions:

  1. EA’s credibility: What ability do we have to encourage IT stakeholders such that business partners would see value in including EA? [Note that this doesn’t imply that you must be able to measure and report EA’s value/contribution as a dollar figure.]

    Who do you engage with most often today? How often are your stakeholders truly business leaders (as opposed to IT partners or intermediaries)?

  2. Business interface maturity. Does my company have the maturity and rigor to engage in a meaningful dialog with EA? How many tables are there in our organization that EA would need to be a part of? (Is it realistic given our resources/capacity?).

  3. Crowding the table: Business leaders may already interact with business relationship managers (BRMs) or liaisons, service managers, IT functional executives (e.g. applications development) and even business analysts and project managers.

    Will more roles at the table really result in better translation of business needs? It is clear what each participant would contribute and be responsible for?

Sitting It Out

If EA teams aren’t at the fabled table, they can still manage enterprise architecture and be in tune with business needs. It may just require new kinds of cooperation with BRMs or service managers to source the right information and understand business leaders’ architectural considerations.

Moreover, there are other opportunities to improve understanding of architectural requirements in the absence of direct engagement. Some EA groups integrate customer experience and customer expectations data gathered by sales and marketing teams to improve how they plan the architecture. One of the lessons of business architecture is that EA does not need to be the one who maps and models everything — and probably shouldn’t be.

In many cases, EA should use what others have done and rely on others’ expertise where it makes sense.


More On…


Leave a Reply



Recommended For You

IT Enterprise Architecture: Is Roadmapping Dead?

A combination of a rapidly changing operating environment, employees' increasing comfort with technology, the extent...