Chapter 8 - The Enterprise Architecture Paradox
Enterprise architecture is increasingly difficult to wrangle, as many firms have accumulated a bizarre assemblage of technologies over time. The most efficient path, to standardize on a few basic tools, is at the same time the most limiting path, in that the firm is limited to doing what a small set of technologies is capable of doing, and is unable to take advantage of newer technologies.
The bewildering array of technologies often results in an squally bewildering bureaucracy of silos, with small groups of specialists in specific systems and few generalists who are able to look broadly across the landscape. This factionalism is further complicated by business units, each of which need solutions that suit their own needs - given that what is needed, wanted, and important to marketing may not be at all desirable to accounting, each has its own array of systems. And this is all good and well until one group needs access to another's data and must face tight controls and a very limited set of options.
Attempts to define a future state likewise lead to resistance: enterprise architects are often too overwhelmed by the present needs to think toward the future, and the business units are likewise focused on achieving this year's goals and are not interested in anything that constitutes an immediate expense for a possible future return.
At the same time, it is necessary to project forward. Consider the metaphor of traffic: cities that build roads based on present demand eventually find themselves gridlocked as the metropolis evolves organically. Those that have the vision to think for the future - where neighborhoods, businesses, commercial centers, stadiums, hospitals, and the like will be built over the next ten years - can plan accordingly and build an infrastructure that will accommodate their future needs.
Another problem is that skilled technical people matriculate into enterprise architecture, but are never really able to get away from the trenches. Whenever a major project is launched or a significant problem encountered, the enterprise architects get pulled back into the tactical world, and the strategic work is set aside and often never completed.
Think About How You Manage the Function
The author has interviewed "hundreds of enterprise architecture leaders" and find that many of them never get to spend much time doing enterprise architecture. There time is filled with other things, and the fact that the department is able to function adequately without high-level plans is taken as proof that high-level planning is unnecessary.
The CIOs who manage enterprise architects well tend to keep their groups well separated from the trenches and focused on the future. So long as they remain engaged in the tactical work, they will not be able to focus on the strategic, and their plans will be anchored in the present state. That is, when a company wants an EA to consider the potential of portals, he should start from a blank state and consider possibilities that might require the firm to invest in new technology, which will not happen if the EA is merely inventorying the portal technology that is presently in place and considering what might be done with it.
At the same time, completely divorcing the EA staff from ongoing projects is potentially dangerous: it may be difficult to answer the question of the business value they provide, and justify the expense of their salaries. One approach that was used to balance the strategic and tactical value problem is tasking the EA staff with maintaining the blueprint of the current systems, which gives them the ability to make projects more efficient by identifying the best resources to leverage, as well as to provide cost-savings by recognizing redundancies that can be eliminated by consolidating applications. This gives them the ability to demonstrate short-term value while at the same time planning for the future.
Another tip is to dispense altogether with the "standards police" mentality - there are very few instances where the benefits of standardization are worth the trade-off in terms of agility. Such groups can hold back innovation and slow projects down for months while they attempt to work out the standards. By having an overview of the present and a plan for the future, the latter functions as a nonrestrictive standard - the way things should be done, but not the way that they must be done.
Find the Right Talent
Because enterprise architects must be familiar with the idiosyncratic systems that a specific firm uses, it's next to impossible to recruiting outside talent that can competently step into the role. Companies are better off developing their own people into the role whenever it is possible to do so. Hiring them from outside is "not impossible, just very hard."
One common but ill-advised approach is merely to grant the title of "architect" to your top technologist - e.g., the best Java programmer is promoted into the role, or merely given the title. The problem with that approach is that architecture, by nature, requires a broad view of various technologies rather than deep expertise in only one.
Yet another component of the EA paradox is that you have to prepare people now for a future you cannot see. Given the pace of change, it is impossible to know what technologies will be in vogue five years into the future, when things can shift dramatically. That is, if you merely promoted your top Java programmer into the EA position, he would be totally out of his element if the business suddenly wanted to focus on the mobile platform.
One CIO downplays the importance of nuts-and-bolts technical expertise, but instead sees the EA as a generalist who has a broad but shallow understanding of a wide range of technologies - and, more importantly, the "soft skills" to work with a broad range of difficult people who have the heads-down expertise. Because EA involves getting the diverse array of systems to cooperate, it also involves getting the diverse array of people with expertise in these systems to play nicely - so an EA who is skilled at diplomacy will have more success than one versed in technology.
One firm has a rigorous process for grooming technical talent, which includes an annual review that considers each member of an 1800-person staff in terms of their capabilities to identify gaps in critical skills as well as opportunities for development. Doing so is time-consuming, but the CIO sees it as the key to building and maintaining the IT organization, so he makes the time.
The same CIO has a three-month orientation program for college new-hires that is geared to orient them not just to the IT systems and processes, but the core business as well as the function of various departments of the company. Hiring managers routinely complain about the process, because they want to put their new hires to work right away, but the CIO feels it is important to give employees a broader vision before putting them to work.
One CIO notes that "the skills and attributes of what an enterprise architecture position requires ... are nearly identical to what is required of a CIO." The author also adds an instance in which she was able to recruit a CIO of a small firm into the role of enterprise architect for a larger one, which is unusual because many C-level executives are not willing to take a step backward in rank and prestige.
In essence, an enterprise architect is a CIO "with no staff or operational responsibility," which makes it difficult to keep good people into that role, as other firms in need of a CTO or CIO will be eager to pick them off. One solution was simply to do away with the title, and assign EA responsibilities to members of the core team. Another is the creation of "mini-CIOs" who each have authority over the systems that serve a given line of business.