The Rising Importance of the Enterprise Architect

Enterprise architecture focuses on four crucial C’s: connection, collaboration, communication and customers. Imagine needing to manually log onto five different systems to create and track an order, or putting in 20 hours researching a project because you didn’t know the information already existed in another department. These situations result from fragmentation and siloed thinking; the goal of enterprise architecture, on the other hand, is to create unity.

In its simplest terms, enterprise architecture is the process of aligning a business’s strategic vision with its information technology. It connects different business units for synergistic communication and collaboration, creating a more seamless customer (or end-user) experience. The enterprise architect, of course, is instrumental in this process.

Enterprise architecture’s goal is IT that enables business strategy today and tomorrow, says Peter Heinckiens, chief enterprise architect at Toyota Europe. “The ‘tomorrow’ part is especially important,” he says. The enterprise architect must map, define and standardize technology, data and business processes to make that possible. This means that the architect must have both a macro and micro view: He must understand the business strategy and translate this into an architectural approach (macro view), but he must also be able to work with individual projects and deliver very concrete guidance to these projects that focuses on the successful delivery of the individual project within that macro view. The enterprise architect transforms tech-speak into the language of business solutions, and he knows what technology is needed to enable business strategy, says Heinckiens.

In other words, he knows how to bridge silos. An oft-used metaphor for the enterprise architect’s role is that of the city planner, since he also provides the road maps, zoning, common requirements, regulations and strategy-albeit for a company, rather than a city. And this role is increasingly important as enterprise architecture itself becomes more important.

The Rise of Enterprise Architecture

The field of enterprise architecture has moved away from reactive one-off projects to becoming an increasingly structured field. With the government’s formalization of enterprise architecture after the Clinger-Cohen Act of 1996 and its increasing prevalence in the private sector, participants are discussing what components enterprise architecture comprises and how to develop best practices. “Only in the last couple years are people converging about what [EA] means,” says Gene Leganza, vice president at Forrester Research.

Enterprise architecture’s roots are in the desire to serve what is best for the enterprise versus the individual department or project, says Campbell Soup Company Vice President of IT-Shared Services Andy Croft, who has the enterprise architect role at Campbell’s. He speaks of the days when employees within the same company were unable to share information via e-mail, because of incompatible e-mail systems. Each department thought it needed its own brand of PC, even its own network or security system. Finally, Croft says, “People lifted their heads and thought, maybe it’s more important to be able to work together rather than me having the ‘best.'” Enterprise architecture gained traction from the bottom up. The first big projects were typically CRM or ERP ventures.

Enterprise architecture requires looking for whatever is reusable, such as opportunities for standardized technical platforms and access to shared data. It is the overarching architecture that guides business, data, information, technical and network architectures. “As we look at current trends, we see companies taking a step back and saying, We want everyone to have access to product or customer files and have the same definitions,” says Jeanne Ross, principal research scientist at the MIT Center for Information Systems Research.

Ross believes enterprise architecture is proactive. She points to the example of UPS. When the company was building its package-tracking application, senior IT executives looked beyond the immediate need and decided that UPS should have only one package database ever. Simultaneously, they decided that UPS IT should run its operations in a highly standardized, reliable, cost-effective manner always. So instead of designing and delivering a single package-tracking application, UPS delivered access to a single package database and a low-cost operating environment that the company continues to reuse to support new applications.

Service-oriented architecture (SOA) is often spoken in the same breath as enterprise architecture, as if SOA is a crucial component of enterprise architecture. This is not the case, points out Leganza. SOA is one possible tool at an enterprise architect’s disposal-one that may or may not make sense, depending on the situation. “Plenty of organizations are interested in enterprise architecture but not SOA,” he says.

However, “SOA is something towards which most companies will evolve,” says Ross.

Spotlight on the Enterprise Architect

Figuring out what systems to map and connect, how best to accomplish this and how to get relevant parties on board does not come easy. That is why the enterprise architect has become a key player in bringing to life the enterprise vision.

To become one, you need a myriad of qualities. An enterprise architect needs solid technology knowledge, says Heinckiens. Plus, he says, you must be really great at business, both generally and specific to your industry. You have to be able to describe an IT project as a business solution, not in terms of the cool technology involved. Another crucial skill is the ability to see from various viewpoints, and to understand the implications for the customer, for the business and for all its units. The architect must enable future visionary strategy, while being pragmatic enough to execute the tasks of the day. These are not easy feats to accomplish, which is why great enterprise architects are in demand.

The ability to engender a more holistic vision in others is important too. Although many companies promote a “we’re on the same team” philosophy, it’s no secret that people tend to see their own needs first. That applies to projects that have limited business value, save for the one department or unit that wants it. This aspect of human nature is a main challenge for enterprise architects, says Campbell’s Croft. “The big thing becomes, ‘What’s best for me?'” he says. “The business unit wants XYZ, but ABC is better for the enterprise.” He points out that ABC may even be more expensive or may take longer, but because it’s for the greater good, it’s a better investment to make. “What’s best for the enterprise versus the individual-that is always the issue,” he says.

That siloed view on projects may come in the form of “I want to use this package” or “I want to build this application,” according to Heinckiens. As an architect, he advises, it’s important to take a step back: Try to understand what problem the proposed project will solve. Is there already a solution that covers the proposed area being researched? Does the proposed project fit into the wider picture? Structurally, business units are silos-and therefore often have a limited view-but the enterprise architect ensures that the pieces of the wider-picture puzzle fit together, says Heinckiens.

As an illustration, some projects use data that nobody else in the company will be interested in, while other projects use data that are useful and relevant to everyone in the company. It is the enterprise architect’s job to figure out how to make the latter type available to the rest of the company, and one part of that task is creating compliance standards. “It is important that this discussion takes place,” says Heinckiens. “Then you see other discussions start to happen.” For example, who owns this data? Who should receive permission to access this data? What is a customer? For the marketing department, after-sale department, finance department, the definition of customer is totally different, even though they refer to the same person.

In many companies this process is ultimately formalized. At Campbell’s, it’s called a “blueprint.” Before a new project can be started, each technology area must review a proposed project to ensure it fits into the overall strategy.

Enterprise architects, for all their vision and forward thinking, need two feet solidly planted in today’s work, the ability to execute that work-just enough at the right time-and the insight to know when goals are too lofty or unworkable, points out Heinckiens. He cites as an example a problem that many organizations are facing: building a common database of dealers or customers (or rather the impression of having a common database). How do you connect a plethora of companies’ dealer and customer databases? He says the most important question isn’t the obvious one, How do you create a common database? He says what really counts is how you get there. One option, the self-contained, static approach, is creating an intensive research project to find the ideal database, build that, then migrate all systems to it. That’s not ideal.

The better choice, Heinckiens says, is to build the database so that it can gradually evolve and is built in line with actual business needs. “As I get more business projects that will actually need the database, it will get more complex,” he says. How do you ensure backward compatibility? There are a number of things an architect needs to focus on, such as defining dealer, both from the internal and external standpoint, and also making that definition dynamic enough so that the architecture can evolve along with business needs. Then he builds the systems in such a way that everyone helps implement that common dealer view, he says. “All of a sudden, instead of an expensive project, I get a project in which the delta cost is almost zero,” he says.

The Movement Toward Enterprise Architect Credentialing

To codify what an enterprise architect is and what she should know, a growing number of certification programs are being offered, such as those by Carnegie Mellon and the Open Group. Allen Brown, president and CEO of the consortium Open Group, believes today’s focus on IT-business alignment has created a greater need for enterprise architects and for the standardization of their skills. To wit, more than 2,000 people have completed the Open Group Architecture Framework certification and 1,700 practitioners have achieved the organization’s IT Architecture Certification (ITAC) in the past two years. On Jan. 29, the group launched the Association of Open Group Enterprise Architects to further the profession and to enforce standards of excellence.

Forrester’s Leganza believes certification is a sign the industry is maturing. He says, “As people agree what [enterprise architecture] is, then they better agree what people should know.” Still, he thinks the tendency will continue to be hiring from within, rather than hiring outsiders with credentials. “Architects hardly ever wield a big stick,” he says. “They influence through thought leadership.” This means they need to know the organization’s business intimately, and those within need to believe that they do.

For her part, Ross worries that certification programs might be limiting. “Enterprise architecture has grown up within IT. And for most companies, that will be a big limitation,” she says. “If we are trying to define and build out enterprise architecture as part of the business, then it has to be equal.” Ross believes that enterprise architecture certification programs that emphasize IT at the expense of business strategy will limit the profession. Since the ability to understand business is so important, she sees great value in aspiring enterprise architects balancing their technology background with an MBA.

Yet, both Croft and Heinckiens point out that it is easier to teach the right IT person business skills than it is to teach technology to a businessperson. While enterprise architects may come from either side of the business, they tend to come from the technology side, such as a leader in application development. The enterprise architect role itself is a gateway to multiple positions, including CIO, CTO or a role that is more strictly business focused.

Heinckiens believes that credentialing is a good step in the right direction. He says there are two main benefits of credentialing: It creates standard competencies, making architecture less of an art and more of a well-defined process. Second, it sets a minimal level of quality. When hiring architects, organizations face the issue of making sure the candidate is right for the organization. Once the architect is hired, they need to make sure the person is familiar with the architecture of the organization. According to Heinckiens, many good developers and senior developers call themselves architects, but being a developer and being an enterprise architect are not the same thing. All that said, he believes you shouldn’t try to find all qualities in a single person, since it’s better to create teams of complementary skills.

In other words, you need synergy. An appropriate word to apply to enterprise architecture itself. Enterprise architecture is not about IT serving the business needs. It is about IT and the business working together to turn a company’s vision of greatness into reality. And the enterprise architect can be instrumental in making that happen.

Associate Online Editor Diann Daniel can be reached at ddaniel@cxo.com.