Nick Malik brings up a good point regarding the need to have extra - IT driven - capacity to apply purely to the task of simplifying and reducing the complexity and maintenance of systems. In my experience, nature abhors a vacuum, and it's particularly difficult to have a full team dedicated to reducing complexity, even if you could justify the expense by having the team pay for itself through reduction of costs.
I think it would be particularly important in the establishment of such a team to ensure that it was driven by it's mandate to reduce complexity, and to ensure savings over the long term. I agree that it would be best to be IT driven, and not driven (directly) by the ongoing business concerns.
I think it's wise to also ensure that effort is applied (almost) always towards achieving the target state objectives of your EA. This is an area where I notice I have to put a lot of communication effort. If you're trying to achieve a short-lived business opportunity, it may be (in my mind, almost always) is better to put those resources towards the longer term target effort, as opposed to refactoring legacy, improving existing (soon to be phased out) offerings.
My experience has been that it's hard to illustrate and communicate to business that if we keep our eye on the ball, the long term business accepted target, and avoid supplementary diversion then we'll achieve a great efficiency in our efforts.
But I guess, it's human to want to eat your cake now.