Unmasking the BRM’s role in enterprise architecture

Enterprise architecture provides the operating principles for an organization. It’s the layer above business and technology capabilities that defines the core tenets of the business strategy.

Enterprise architecture and IT architecture are commonly confused. They are, in fact, similar terms, but the intents radically differ. Enterprise architecture intends to define the degree of standardization and integration; e.g., what data is shared. The intent of IT architecture is to define the interrelationship between technology components; e.g., how a technology component is leveraged across a technology ecosystem.

Should a business-relationship manager (BRM) be involved in the development of an organization’s enterprise architecture? They should if they want to influence the operating principles of the organization.

Value-driven enterprise architecture

Taking measurements of capabilities won’t be useful at this point. Spend time developing enterprise architecture and reaching consensus on the basics.

The guiding steps to developing a robust enterprise architecture are:

1. Define standardization
2. Determine integration
3. Develop business and technology capabilities
4. Establish policies, standards, guidelines, and procedures
5. Set business and technology competencies

Defining standardization provides a guideline for how business units will relate; e.g., will business units make decisions independently? Determining integration helps an organization draw a line between business services that might be shared; e.g., human resources or business services that could be isolated such as business-aligned analysts. Development of business and technology capabilities refers to features, faculties, or processes that can be developed or improved; e.g., does the organization have the ability to meet strategic commitments? Establishing policies, standards, guidelines, and procedures describes outputs of the enterprise architecture framework; e.g., limits and boundaries of standardization, integration, and capabilities. Setting competencies determines the utility of knowledge, strengths, or skills; e.g., how the skills of quality-control resources support organizational goals.

Combined, these five principles provide a channel for BRMs to open the discussion of business strategy and make it tangible. Business leaders have a strategy. Sometimes it’s even a business strategy. Instead of asking for a business strategy, help drive the discussion by developing an enterprise architecture.

The role of the BRM in enterprise architecture

In an earlier discussion, we defined the twenty responsibilities of the modern change agent—the BRM. The first responsibility was to “ensure that solutions and services deliver expected business value.” Products, services, and interactions must link back to the business strategy. This is accomplished via enterprise architecture.

Standing at the edge of a cliff with a challenge to rappel down the rock face, we’d be sure we had enough rope to make it safely to the ground 150 meters below. Ensuring delivery means capturing assurance that commitments will be honored. In our rappelling example, the goal is to not run out of rope. In business, it’s no different.

A business strategy that isn’t linked to enterprise architecture creates a disconnect between the business strategy and the technology strategy. What would happen if we had a business strategy and a strong technology strategy but no enterprise architecture? The first 50 meters of the rope (business strategy) would be secured with climbing cams. We’d have to free climb down the middle 50 meters and then pick up the last 50 meters (technology strategy) that are again secured with climbing cams.

Where will we find the bulk of the challenges? Yes, in the middle, where we have no plans and have haphazardly connected business strategies to technology strategies, all the while hoping we connected them correctly.

Use these questions to gauge where to start your enterprise architecture:

Define standardization

• Are processes standard across business units?
• Is growth with duplication of processes acceptable?
• Do the business units have accountability for their functions, or does this reside at the organizational level?

Determine integration

• Is data shared across business units?
• Do workflows span departments?
• Are automation and orchestration managed at the product, business unit, or organizational level?

Develop business and technology capabilities

• Do business units share business capabilities?
• Are technology capabilities consumable at the enterprise level?
• Has the organization accounted for all capabilities required to execute the business strategy?

Establish policies, standards, guidelines, and procedures

• Are policies departmental or organizational?
• Are the standard operating procedures (SOPs) specific to a business unit or a function; e.g., networking or tissue-sample management (biotechnology)?
• Does the type of policy determine whether it’s adopted at the department or organizational level; e.g., standards for security versus electronic lab notebooks?

Set business and technology competencies

• Are job descriptions consistent across the organization?
• Do the roles coincide with organizationally equivalent roles?
• Are competencies measured at the team, department, or organizational level?

Make your business strategy deliberate. Use an enterprise architecture.

The IT role in enterprise architecture

IT enterprise architecture provides organizations a method to standardize, consolidate, and optimize information technology assets.

Traditional IT architects do have a role to play in developing an enterprise architecture. The enterprise architect links the business strategy to the IT strategy. This is accomplished by using architecture frameworks, also known as reference architecture models.

Common reference architectures include performance, business, data, application infrastructure, and security. By designing integration points among these reference models, the IT enterprise architect can illustrate the current and future state of an IT enterprise ecosystem. Reference architecture produces reusable, technology-design patterns that are consumable by other teams, departments, and business units. These technology-design patterns model how programs, processes, information, applications, technology, investments, personnel, and facilities work together to deliver business strategies.

One of the first models of IT enterprise architecture was developed by the National Institute of Standards and Technology (NIST) in 1989 (since revised). The model defines five layers of architecture:

1. Business: business functions and standards
2. Information: information flow
3. Information systems: systems integration
4. Data: physical and logical data design
5. Delivery system: infrastructure and security

The Common Approach to Federal Enterprise Architecture defines a similar, five-level model:

1. Strategy plans: business-strategy requirements
2. Business activities: workflow
3. Data and information: data exchange
4. Systems and applications: applications
5. Network and infrastructure: hosting

Recently, a simplified, four-layer model has been more widely adopted:

1. Business: business strategy and governance
2. Application: business functions
3. Information: data and service management
4. Technology: infrastructure management

The IT enterprise architect is accountable to deliver a strategic plan, workflow diagram, data-flow diagram, system interface, network diagram, and security controls.

Whether you’re exploring a digital strategy, cloud-first model, or a big-data strategy, IT enterprise architects will play a critical role. The challenge is not if you should leverage an IT enterprise architect but when.

Reference architectures or reference models should cover at least four basic areas:

1. Taxonomy: to incorporate components to be categorized and inventoried
2. Methods: to define the alignment of best practices
3. Use cases: to explain how the reference architecture will be applied in context
4. Touchpoints: to define the relationships among reference architectures

There’s no single best way to develop an enterprise architecture. The standards will vary for each enterprise. At the conclusion of your review of the reference architecture, if you’ve defined the taxonomy, methods, use cases, and touchpoints, there’s a good chance you’re on the right track.

A model of destination

Ask to be involved in the development of the enterprise architecture. These discussions will form the foundation for the operating principles of your organization.

Enterprise architecture ultimately results in defined reference models for business, applications, information, and technology. The critical component of enterprise architecture is the business architecture. Enterprise architecture, as a whole, is owned by the business. The confusion typically arises regarding who has accountability for each reference component of the architecture. Here’s a quick synopsis of the lines of accountability by reference architecture model:

1. Performance: business accountable
2. Business: business accountable
3. Data: business accountable
4. Application infrastructure: technology accountable
5. Security: technology accountable

Enterprise architecture comes down to two principles: standardization and integration. Siloed architecture offers the benefit of local control. Standardized technology provides reduced-cost footprints due to interoperability. Rationalized data can improve business performance integration. Modular approaches enable speed to market and strategic agility. In the right environment, any of these approaches to enterprise architecture can be the best strategy.

Center the business strategy with defined business processes before linking to applications, data, and infrastructure. Savvy companies realize that enterprise architecture is the single greatest generator of organizational value. As the agent of change, BRMs are well positioned to champion organizational transformation to enable organic growth.