During the time I led an IT enterprise architecture program for a large technology company, we developed an annual cycle of architecture activities. They naturally evolved into four seasons of activities that aligned with the corporate and IT functional calendars. The seasons built on each other, aligned with governance processes, and created annual growth for the architecture program. This model can be adapted to the rhythms of many enterprises.
A fundamental principle of IT architecture is alignment with the overall business or enterprise. That leads naturally to being sensitive to the corporate calendar. Over time, we learned to anticipate key corporate cyclical processes and aligned the EA calendar in support of them. Sometimes that meant doing work in anticipation of an annual cycle, and other times, it meant being ready to react to the outputs of a corporate process.
The four seasons we evolved into were: Research, Strategy and Road Maps, Planning, and Metrics and Rewards.
RESEARCH
Research season occurred in the fourth quarter of the company’s fiscal calendar. The enterprise as a whole was focused on execution and achievement of the annual goals. It was an excellent time for the EA program to update its understanding of corporate strategy, IT industry trends, and key vendor product plans. The timing worked well because we would be in synch with the flurry of analyst forecasts for the coming year and beyond. The tangible deliverables were updates to EA program documents. These included statements of IT principles, industry trends, and corporate strategy implications for IT. We would host meetings to present and highlight key changes to these documents in a webinar format with post-session playback support allowing broad participation.
STRATEGY AND ROAD MAPS
This season follows naturally and is a more detailed look at the EA program domains. In practice, we concentrated on examining the business process/application domains and the technology domains. Each EA domain had a designated domain leader and an executive sponsor. For domain leaders, we recruited the top expert in the organization for that particular topic or an individual who was being developed to be an expert in the area.
Among the standard deliverables for each domain are a strategy summary and a view of the expected three-year forecast of development in the domain. These forecasts highlighted three-year expectations for the industry, recaps of key vendor product plans, and the domain leader’s judgment on the timeline for our specific adoption. These were not plans for the organization but road maps. In our environment, a road map is a statement about what is possible and what we recommend should happen. It is not rationalized against the various resource constraints, which are required of a true plan. When viewed this way, creation of the deliverables and three-year timelines became manageable and easy to create by the domain leaders.
PLANNING
Planning for the enterprise was an annual process driven by the corporate financial function. The “magic” of planning is to interlock the organization on a set of objectives that balance revenue and expenses at a level to achieve a target return. The challenge for IT is to ensure the function is funded in balance with the projects and operating expenses needed to achieve the business initiatives in the plan. In any organization this is a challenge.
The road maps produced in the EA program became a key tool in this process. Having a clear view of what applications or technologies are approaching end of life helps to redirect investment into the appropriate longer term solutions. Having a strategic view of key business process and application developments aids in cross-functional support planning. Having a clear view of applications underlying technology stack allows interlocking application and infrastructure planning. These planning processes can become intractably complex. We used the road maps to develop CIO-sponsored mandates into the planning process. Example mandates included bans on investment in applications targeted for retirement, requiring technology replacements or upgrades in advance of vendor end-of-support dates, and use of only approved suppliers and products.
The EA community became core to the planning process as we matured the program. The inventories we developed of the business processes, applications, technologies, and mappings to projects created the information framework needed for better decision making. The organization became much better at seeing the implications of investment choices and trade-offs.
METRICS AND REWARDS
In our practice of EA, our success was determined by the quality of the participation from the broader organization. This centered on the domain leaders. Over time, we developed a set of metrics for the domains and, by implication, a scorecard for the domain leaders. Tangible metrics were produced that measured the timely production of strategy and road map documents. We measured participation in EA program meetings. We encouraged and hosted domain reviews, a platform for a domain leader to share his or her insights in a webinar format to the IT community, which were also captured for replay. The central EA team would recap these metrics and provide feedback to the domain leaders and their management. We assessed with management the need to rotate domain leaders to improve program participation, create growth opportunities for individuals, or accommodate job rotation and changes in the organization. Effectiveness as a domain leader became a metric in the determination of compensation and career progression within the organization.
SEASONS BUILD INTO YEARS
Each cycle of seasons was an opportunity to build the EA program stronger. My personal experience started with an EA program focused on technology standards. Road maps were added to reflect anticipated changes and facilitate infrastructure planning. Domain leaders were just the experts we knew and did not gain a title until we realized the need to provide recognition and increase accountability for consistent production of deliverables. It took a large-scale merger to drive an ongoing commitment to business process and application domains as we strived to rationalize two large overlapping portfolios of applications. Each annual cycle was an opportunity to leverage the repositories of EA artifacts, develop an enhanced capability, and most importantly, develop a stronger and ongoing contribution to the success of the enterprise.
