EA exists to align IT strategy with Business strategy while minimizing long-term IT costs. EA uses several tools to do this including Roadmaps, Technology Standards, and Application Release Plans. An Architecture Review Board (ARB) is used to ensure projects align with the long-term strategy.
EA has to leverage as much as possible to be successful. EA shouldn't try to boil the ocean. There are a lot of inputs that make EA
work - an application inventory, a CMDB, release plans, vendor roadmaps, project pipeline, etc. If something doesn't exist that is needed, an EA program should start it. The team should build out a skeleton version of whatever is missing and needed to satisfy the EA requirements. The trap with this is that some EA teams will spend all of their effort on creating the prerequisites to EA and never get to the truly value-add activities. Build out exceptionally light versions of these things and pitch them to other groups to own and mature. Remember that these are just the prerequisites and not the end result. Leverage as many pieces of the organization that already exist and "spec out" the rest.
The PMO and the project management process is the most important. IT Governance is usually done through project management in one way or another. If an organization doesn't have a good project management process, they don't have good IT governance. If they don't have IT governance, an EA team will not be successful. In that type of organization, an EA team will create "guideline" type documents that no one will adhere to.
Application Inventory
You have to know what you have in order to know where you're going.
CMDB
This may include your application inventory. Think of it as a current-state snapshot, though. It won't be able to hold your "to-be" versions of the technology landscape. Most organizations don't have one but if it exists, an EA team should leverage it. It can also be used to figure out what applications exist in the environment.
Application Release Plans
Application release planning is exceptionally important. Take the Application Inventory and map out what applications (including versions) will be covering business requirements over time. Update it frequently by meeting with the application owners. This is a great tool to help communicate where the organization is, where it's going, and what it's going to take (at a high level) to get there.
ARB
A project is a unit of change in an organization. If you can keep projects aligned with your IT direction then you will eventually get the IT environment as a whole moving in the right direction. On their own, project teams will (rightfully) strive to minimize their own effort and costs while delivering the business requirements. An ARB is there to keep projects from going too far from the enterprise standards and directions. An ARB process should be tightly aligned with the project management process and take advantage of existing go/no go gates. The ARB should also leverage project management deliverables that project teams have to create. Project Managers will push back if they are forced to create specific documentation for an ARB review. Putting extra work on project teams has the potential to kill an EA program in the long run.
When done right, an ARB can actually help project teams if you understand their key driver - get the project done fast and at the lowest cost possible. The ARB can introduce reusable infrastructure or architecture patterns that project teams can leverage to compress their timelines.
Working with project teams is the most visible thing that an EA team will do. It has to be done in a cooperative "tone" with an eye toward creating converts to the EA way of thinking. Trying to beat project teams into submission may work a few times but will be political suicide if done consistently.
