Enterprise technology architecture (ETA) should focus not just on establishing technology standards, but also on ensuring that ETA standards and other guidelines are embraced and used throughout the enterprise — by focusing, in particular, on process- and communication-related issues. Connect the technical architecture back to the business vision and strategy. It is important that ETA decisions are driven — as EA, in general, and other EA viewpoints too should be — by requirements derived from the enterprise’s business vision and strategy, and that this connection is made clear in communications with key stakeholders. For example, rather than justifying a server operating system (OS) based on arcane details about why the upgraded OS is technically superior, link the upgrade to a strategic need — for example, the need to support a CRM-enabling application that is critical to the company’s customer-focused business vision, and that won’t run on the prior version of that OS. “For any ETA decision, there’s always a story to tell that relates to how that change affects the business and its strategy,” a group participant observed. Communicating this connection can be particularly challenging for technical architecture because — compared with other dimensions of the EA, such as business architecture or information architecture — the connections to business vision aren’t usually as direct or easy to see. For example, if the company strategy is to boost sales by doubling the size of the sales force, then this may bring a requirement to upgrade the remote-access infrastructure. However, it may take a couple of steps to communicate that line of sight from one requirement to the other: For example, a bigger sales force will cause more system access to sales-lead data to occur from remote locations via handheld devices — which, in turn, will necessitate a more-robust remote access infrastructure to support these needs. Don’t expect stakeholders to figure this out on their own. Bad technical architecture isn’t a deliberate choice. It creeps into a company in undetected increments, the result of point decisions that seemed entirely logical when each was made. As these narrowly focused decisions accumulate, though, they begin to collide with each other, and as they do a number of common, expensive, bottleneck-inducing symptoms begin to emerge. ETAM matters because its point is to fix these symptoms and to prevent recurrences. Its goal is to build architectural awareness into IT’s most important methodologies so that enhancing the architecture is a natural part of the work that gets done.