Calling the Elusive Enterprise Architect: You’re More Important than Ever
Readers who have been following ZapThink for a while know we talk quite a bit about Service-Oriented Architectures (SOAs). We talk about how in an SOA, the architecture provides a layer of abstraction that hides the complexity of the underlying technology implementation, while providing location-independent, business-oriented Services. We also talk about how line-of-business users can then orchestrate those Services into Service-oriented business processes. And when you really get us going, we speak about the practice of SOA — what it means for SOA to be enterprise architecture.
The mention of the practice of SOA brings us to the topic of this ZapFlash — the architect. It is difficult to pin-down the exact role of the architect for several reasons, including a widespread lack of understanding in enterprises today as to what IT architecture really is, as well as the flexible, unique job descriptions architects typically find themselves with. Nevertheless, for enterprises to be successful with their SOA projects, it is absolutely critical that they have one or more people serving the role of enterprise architect — or Service-oriented architect, if you will — that is able to provide and manage the big picture of the enterprise SOA.
Pinning down enterprise architecture
First, let’s start with a definition of architecture. There are several, but the official IEEE definition is one of the most concise: architecture is “the fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guiding its design and evolution.” There are many related, but different kinds of architecture, including component architecture, systems architecture, and information architecture. The one we’re most interested in is enterprise architecture. Enterprise architecture is the aggregated architecture of all the individual IT systems within an organization, including the human element within the enterprise. Enterprise architecture involves the systems, people, and organizational constructs at other companies that have relationships with the enterprise, and for a consumer-facing company, the enterprise architecture includes the individual consumers who are that enterprise’s customers. So yes, if you’re using your bank’s Web site, then you too are a part of your bank’s enterprise architecture.
There are two characteristics of enterprise architecture worth emphasizing. First, such architectures include people, not just systems and hardware. How people interact with IT is as important to the enterprise architect as the IT itself. Secondly, enterprise architecture goes beyond the boundaries of the enterprise to include systems and people at customers, suppliers, and partners. The enterprise architect, therefore, often works with individuals and systems outside their own company.
Enterprise architects often have very different titles and diverse responsibilities, and often don’t even agree on what enterprise architecture is. Some enterprise architects are very technical, while others are more IT managers than hard-core techies. Many companies also have enterprise architecture teams or committees that serve the role of the enterprise architect, rather than a single person. In addition, some enterprise architects are at the level of a senior developer, while others can be vice presidents who report directly to the CIO. Therefore, finding the enterprise architects in an organization can be difficult — whether you’re inside the organization or outside looking in.
The Service-oriented architect
The reason this ZapFlash is spending so much time defining enterprise architecture is because SOA is actually a form of enterprise architecture. While SOAs can be suited to small and midsize companies, as our last ZapFlash explained, SOAs for those companies tend to be outward facing, extensively involving outside systems and people. For a large company, an SOA may be either primarily for internal or external use, or frequently a healthy combination of both. In any case, the Service-oriented architect must be responsible for understanding both how IT personnel provide and manage the Services available to the enterprise, as well as how line-of-business accesses and orchestrates those Services. Without this single individual (or team) responsible for the big picture of the SOA, it’s quite likely that the business and IT organizations will go off into the weeds, leading to IT that doesn’t meet the needs of the business. And if that happens, then there’s hardly any reason to have an SOA in the first place, because such an SOA won’t solve any of the problems that faced the enterprise before they decided to adopt Web Services.
The reason the role of the Service-oriented architect is especially important has to do with the fundamental nature of an SOA — that is, that the SOA provides a layer of abstraction that hides the underlying complexity of the technology. It is because of this curtain of abstraction that there needs to be someone at the organization who can see on both sides of the curtain. Remember, one of the idées fortes of SOAs is loose coupling: fundamentally, the consumers of the Services shouldn’t need to know about how the Services work, and the producers of those Services likewise should not need to know how the consumers operate. Such loose coupling doesn’t work by magic. Rather, it requires a sophisticated software infrastructure as well as the professional, purposeful design by architects that understand what’s really going on. So now more than ever, the enterprise architect is a critical role within companies looking to build SOAs.
Enterprise architects: the key to the SOA marketplace
ZapThink talks to many software and hardware vendors, and we can’t stress strongly enough how important the enterprise architect is to any vendor who offers a piece of the SOA puzzle. Whether a vendor offers solutions in the integration, security, management, tools, infrastructure, or process market segments, if their particular product helps companies with their SOA initiatives, they must target the enterprise architect. Focusing on a developer message is a great way to sell early Web Services-related solutions, but developers aren’t responsible for the architecture — so the SOA message is largely off-point with them. On the other hand, focusing on a high-level, executive IT message can gain a vendor some traction when discussing the long-term SOA big picture, but such messages are strategic, not tactical. As such, the enterprise architect audience is the sole audience that can both understand and value the SOA message, and incorporate these vendors’ solutions into their SOA roadmaps today.
So, if you’re an enterprise architect, or a member of an enterprise architecture team, you’re in the driver’s seat. You need to understand SOAs deeply, so that you can make the appropriate architectural recommendations and decisions for your organization. You’re the one the vendors must talk to, which gives you both power and responsibility. If you’re a vendor who is considering an SOA message, such messages resonate best with architects at this point in time. On the one hand, this fact means that in large part, it’s still too early for many vendors to focus on having an SOA message, and on the other hand, finding and educating architects is a critical market building activity for any vendor who believes that it’s only a matter of time until enterprises of all types begin to demand SOA solutions.