10 Key Skills Enterprise Architects Must Have to Deliver Value
Receive your complimentary copy of this Executive Report when you fill out our special offer form. Gain strategies for promoting architecture as a value-adding activity, rather than as something that is time consuming. Read It Now.
The first thing to note about architects is that title and responsibility follow scope. Architecture is often done from two perspectives or scopes. At the enterprise perspective, the enterprise architect is responsible for setting the overall context, defining what must be common across the enterprise, and creating patterns and standards for how that should be applied at the project level. For the project, the solution architect is responsible for acting as the bridge between the enterprise context and the application-specific requirements such that the solution meets the project requirements and conforms to the enterprise architecture.
The second important fact is that architects work in domains. Enterprise architecture is typically divided into the domains of business, information, application, and technology architectures. In many organizations, an architect will be dedicated to a particular domain, such as a business architect. For each domain, the architect can be working at either the enterprise scope or the project scope, addressing different issues and producing different things. Using the business architect, for example, at the enterprise level, the architect would be dealing with strategy, goals, tactics, and objectives, while at the project level, the architect would typically be defining business processes or rules.
Regardless of what domain or scope they work in, there are a common set of skills that all architects have. While architecture at the enterprise scope is required to create the big-picture view and provide context, the value of architecture comes when it is applied to help and influence projects. So let's look at 10 things an architect does in the context of a typical project lifecycle.
10 THINGS AN ARCHITECT DOES TO ADD VALUE
Inquire. Architects are asked to solve specific problems. Getting to the core of the problem and soliciting requirements is the first step in addressing any given set of requirements. Of course, the requirements are often vague and presented in the limited focus of a specific application domain. So the inquiry must solicit specific requirements and goals, as well as an understanding of how those requirements fit into the broader enterprise context.
Integrate. Architects act as a bridge between a given project or solution and how that project fits into the broader context. One of the major benefits that an architect brings to the enterprise is integrating the solution for the particular project with the business domain, enterprise concerns, industry standards, established patterns, and best practices.
Analyze. Next, architects have to analyze the information that they have collected. The analysis consists of answering three architectural questions: (1) What are the key elements of the problem or solution? (2) What are the relationships between them? and (3) How do they combine together to provide value higher up?
Conceptualize. Once the overall, integrated solution is framed, the architect needs to create a conceptual vision of the solution. This will typically be in the form of a conceptual architecture diagram, a drawing that shows the major users/channels of the system, the other systems it has to interact with, and the major logical functions and data that it must perform or use. It also must establish the scope of the project within those pieces.
Abstract. The architect also has to communicate the key details to many audiences. This can be accomplished through the use of architectural viewpoints, such as business, information, application, and technology perspectives. Abstraction can be defined as the suppression of irrelevant detail. So one key abstraction is to apply separation of concerns to establish (filter) what details are and are not important for that viewpoint. Within each perspective, the viewpoint will also be presented in different levels of abstraction, often referred to as conceptual, logical, and physical architectures.
Visualize. They say a picture is worth a thousand words. It is also an excellent way to represent the architectural models and drawings at each level of abstraction. So another key skill and function of the architect is to create visual renditions of the
different abstractions and viewpoints.
Formalize. Of course, architecture needs to be more than just pretty pictures. It needs to be specific enough to unambiguously communicate the details to whomever is going to implement the architecture. An architectural "specification" is the usual approach to formalization. But the specification does not have to be a document. A visualization in the form of a complete and precise formal model, expressed in industry-standard notation, is often more beneficial.
Communicate. This is probably the single most important aspect of an architect's job. Fundamentally, architects are in the role of communicator. After they establish and formalize a solution, they need to communicate that solution as well as its importance and value to stakeholders throughout the organization.
Enable. Even the best designed, formalized, and communicated architecture may not be successful. The equation for architecture value is actually pretty straightforward. If using architecture will make someone's job easier, they'll use it. If it adds extra steps and work, without adding extra value, it will be ignored. Of course, achieving this goal is anything but simple, but a key to achieving architecture's goal of influencing IT projects and systems depends on the extent to which architects enable the target audience to easily use the architecture.
Assist. Finally, one of the primary enablers for architecture is to actively assist projects in using it. This is the single most important activity architects can do to make their architecture real. Virtually all successful architecture programs include some aspect of consulting to projects.
While this list is not complete, I hope it gives you some food for thought. Is this what you or the architects at your organization do? Are you missing or skipping some important steps? Are you spending time on the right activities that bring value to your organization?
As the complexity of IT grows, more and more organizations are realizing the need for architecture. But the definition of what architecture is, the titles that architects have, and the role of an architect vary widely from one organization to another. Business, IT, management, and even architects don't necessarily know what a good architect does to add value in his or her organization. This Executive Report discusses the role of the architect and describes 10 activities that architects should perform to add value to projects.