Although EA focuses on conceptual and design level, project implementation is at more tactical level, the EA team can find itself getting dragged into project issues for sure, often between the technical delivery team and the business stakeholders over requirements & governance issues. It's not always easy to strike the right balance....But for improving overall IT project success rate (statistically 70% of project fail to satisfy customer), EA needs to become such progress advocate:
- EA governance involvement can vary by project, something which is business critical might prompt the CIO (who may in turn have been prompted by others) to insist that there are regular meetings between the project team and EA people to "keep an eye on it". Generally, enterprise architecture doesn't run projects themselves, and so rely on projects as 'vehicles of activity' which continue to move towards that future state.
- EA as collaborator than controller: If the EA group is given the impression that they are a controlling force rather than a collaborative group, that works with the project teams foster tension between the groups. Measure EA team based on their ability to mentor, to provide best practice analysis to the PA (project architect) or project teams and their ability to incorporate and implement appropriate lessons learned from the PA requirements back into the overall EA. Companies with a static EA get left behind.
- Doing PA and then reviewing the final PA in regards to the EA. This allows consistent application of the common goals of the EA into each project. Also it provides the opportunity to update the EA if new factors are introduced or new technological advances have come to light from the latest PA. Using this method of review help to keep the funding for EA stable and ensures the EA does not get out of step with companies changing goals and focus. At project level, PA (Project Architect) are held to project performance ... while PM are the guardians of Timeline and Budget, Project Architecture are a held to Quality of the delivered product, for that organizations are prepared to pay for.
- EA is not to be measured by itself,
but rather by their influence to the business, governance and projects.
Most of the effort for the EA is in three parts:
- The initial setup and the buy in from the stakeholders. This is when the EA will be initially chartered, scope and objectives defined. Usually the objectives are the business strategies plus the transition approaches.
- The governance. Ensure the relevance, communications and compliance to the EA. This is when the EA interacts with the PA.
- The upkeep. This is when the EA operating charter is realigned to any new business strategies (if any), lessons learned is presented and incorporated into the EA, and approaches that were defined in the charter or updated in previous upkeep sessions are updated.
- There's always going to be a natural tension between enterprise architecture and solutions/project architecture, because solutions architecture is defined by the scope of the project, and so doesn't always deliver everything the enterprise architecture defines it should (a compliant architecture in TOGAF parlance). However, Agile methodology shapes the new way to do project, the design to implementation scenario is no longer following the sequential order, but through iterative communication & process, with agility to adapt to changes. Hence, there's possibility EA needs to be more interactive in PPM & PM level when necessary.