Avoiding the Ivory Tower
One challenge of Enterprise Architecture, in any organization, is figuring out how to "be relevant" to the projects while still planning for the enterprise. This is tough.
Basically, Enterprise Architecture performs three primary classes of activity: Planning, Design, and Assurance. All three require connections between both enterprise strategy and project strategy.
| EA Activity | Enterprise Needs | Project Needs |
| Planning | Alignment with Strategy, IT Simplification, Steering IT towards a rational future state architecture. | Alignment with Information Change Requirements and Business Capability Gaps, planning the use of technology to support IT goals, planning for reuse of assets or for creating reusable assets. |
| Design | Contributing to and leveraging canonical events and business object models, developing a consistent use of integration technology, minimizing cost of ownership | Build for operations, scalability, reliability, maintainability (and more) System Quality Attributes |
| Assurance | Review to assure that the strategic goals are not lost or have not been sacrificed for the sake of delivery. | Review to assure that design elegance and quality have remained balanced and kept in mind as the full delivery of the project approaches. |
Of course, it is sometimes more difficult to deliver EA relevance, not because the activities are poorly understood, but rather because the Responsibilities and Accountabilities are not properly aligned.
This is not particular to EA. Every team faces this problem in a large organization. If the CIO says that "team 1" is responsible for doing "Activity X" but the manager and staff of "team 1" do not see that activity as important or useful, then the activity will not occur. Scorecards are a back-hand way of making sure that these alignments occur because they can surface embarassing numbers. Nothing clears the deck like a manager trying to avoid being embarassed. ;-)
So how do we keep EA out of the realm of "ivory towers?" We figure out how to get all the responsibilities well understood, aligned to strategy, aligned to the scorecard, and reported at the right level.
My opinion: this requires three parts-
- Part 1 - deep executive visibility and engagement on strategy
- Part 2 - deep program engagement on business process
- Part 3 - deep project engagement on design
In a smaller IT department (less than 100 people), a single team can conceivably do all three parts. In medium sized IT organizations (100-1000 people), you may need to have two teams: one aligned to executive strategy and the other to perform both business process and design engagements.
In large IT organizations (larger than 1000 people), you would be well served to create THREE TEAMS, each assigned one of the parts above: strategy, process, and design. How they report heirarchically in a large organization will matter (inevitably). Their role will matter as well.
But more important than all, the three teams must align on a single common set of goals, common communication of progress, and common leadership consensus (no public brawls). The team members must talk with each other, member to member (not just manager to manager) on a regular basis. They are required to collaborate on deliverable models, and understand the work that the other teams are involved in. If if they have seperate managers, and report to different parts of the business or IT, they need to view the entire structure as a single team, and defend that view. Best case: team members should rotate between functions, being trained as they go.
This is a complex structure for a large organization, but it works to keep the three parts of Enterprise Architecture connected to the three activities at both the enterprise and project levels.
And staying connected, to the right people, at the right levels, is how you avoid creating an ivory tower.