Hype cycles are common in many markets. For technology markets, Gartner® has established a five-phase hype cycle used since 1995 to track a new technology from its trigger phase to the point where it has become widely demonstrated and accepted. For many technologies, these hype cycles typically span anywhere from three to ten years.

When a technology breakthrough gains momentum with the press and possibly launches a product, that particular technology gets triggered. This describes the first phase of the cycle. In the second phase, expectations for that technology are inflated because of a few over-enthusiasts pledging unrealistic paybacks. When these paybacks are not obviously realized, the press walks away from that technology, leading some of the enthusiasts to drop out in the third phase. The enthusiasts who remain on board continue to utilize the technology during the fourth phase and find boundaries within which that technology can be practically utilized. Finally, in the fifth phase, the utilization of that technology within these boundaries is widely demonstrated and accepted.

I have seen several technologies go through these hype cycles. Some of the now widely accepted technologies that traversed through these five phases include Service Oriented Architecture (SOA), Linux, XML, Knowledge Workplace, and B2B CRM. These bring back a few memories for many of us. Today, we are going through the second phase of the hype cycle for Master Data Management (MDM), Social Networking Software, Smart Grid technologies, and Cloud Computing.

The hype on Enterprise Architecture (EA) started ever since the Zachman Framework was defined in 1987, and it still continues after three decades. Now in 2009, which phase of the Garner hype cycle does EA find itself in? Believe it or not, there was never a hype cycle created by Gartner specifically for EA. Greta A. James, a research Vice President at Gartner focusing on EA, will tell you that EA is a program, not one technology. Under the EA umbrella we find several hype cycles including Application Development, Application Integration & Platform Middleware, and EA Tools.

If a hype cycle for EA did exist, with thirty years under its belt this topic would have been well adopted by many organizations, and the role of EA probably would have been well accepted within these organizations. Unfortunately, this is not the case. For 2009, Greta has predicted that more than half the existing EA programs are at risk and will be discontinued in the near future. Remaining ones that survive this economy, per Greta, will struggle with framework and information management problems. Many of my friends who didn’t already get cut are now hoping that their EA departments won’t be eliminated.

Why have Hope in the midst of so much Hype? Did we miss the boat on reaping the rewards from the thirty-year hype? Let’s look at other sections of IT. If the Operations department is cut, we know that systems will be on the floor. If Business Intelligence is cut, we know that customers will scream for reports and analytics. If Application Development is cut, we know that new functionality cannot be built to keep the business moving forward. A friend of mine who is the CIO of a company going through a Chapter 11 still keeps scaled-down versions of these departments. But if EA is cut, who will feel the pain?

Changing Hype first to Hope and then to Reality requires us to go back to basics and investigate the purpose of EA. Gartner defines EA as: “Enterprise Architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.” From a tactical perspective, lots of goodies are embedded in this definition.

Translate Business Vision and Strategy
To successfully implement the EA function, we need to ensure that the EA group has a dedicated staff that understands the business. For example, in a publishing company architects need to understand their media products whether they’re books, print magazines, or online magazines. They need to understand how the company makes money through these products. Architects need to become familiar with the business terms and the company’s underlying business processes. Then they need to understand where the business wants to go in the current year in contrast to the company’s objectives for the previous year. Using this expertise, architects need to put together relevant programs to move the organization forward using technology as the vehicle.

Create Key Requirements, Principles, and Models
There must be a different EA staff that brings these programs down to reality through the Program Management Office (PMO). Key requirements need to have a basis of underlying EA principles. These can include strategic principles about the company’s cyber security environment or tactical principles about how EA gets embedded into Change Management. To successfully create these requirements, a set of base architectural models is needed. These models must be specifically tailored for the organization, with direct linkage provided to the blueprints of core systems.

Describe Enterprise Architecture’s Future State
Describing the future state requires the involvement of a few EA staff members with strong technical expertise. They need to understand the current state and define the future. We need to limit these future state objectives to a handful of items to make sure they get the necessary attention. Additional technical details about the future state can be embedded into technology roadmaps and standards. If the main objectives aren’t limited to no more than a handful, though, the purpose of EA and its objectives will get lost.

Enable Enterprise Architecture’s Evolution
The evolution of an organization’s technical capabilities requires well defined, well organized, and well managed technology proposals. This can be achieved only by creating well defined standards, clear lines of communication on why these technology standards are in place, and a well managed process for technology governance. If we are ready to implement a technology law, we need to make sure that there is some staff on EA dedicated to processing the requests for waivers and providing the necessary reasoning for such standards.

In conclusion, when these simple principles are followed, Hype becomes Reality and the term Hope will no longer be needed. When Enterprise Architecture is able to prove that it can bridge the business vision to IT’s tactical operations, its function will no longer be Hype and EA staff members will no longer need to Hope they won’t be cut. Enterprise Architecture will become an organization without which the company will feel the pain just as it would if other departments within the IT organization were cut.