EA Voices

To ensure your EA initiative delivers business value, focus on the needs of the business community from analysts to middle managers to senior leaders. Present the information using visualizations they find useful, rather than trying to teach them EA models. Let business users describe architecture components using terms they are comfortable with, and make sure you can quickly deliver finished architectures when users demand them.

Those are the lessons USAA’s architecture team has learned in its five year push to move EA from an IT-centered function to a vital solution for business planning and strategy at the financial services giant. As USAA has grown to 23,000 employees and 8.2 million members, the rate and magnitude of change has resulted in a level of complexity that requires a single cross-discipline, cross-organization architecture team.

In a June 15 Webinar for Troux, Michael Pemberton, Enterprise Architect in Transformation and Integration, suggested that EA and Business Technology Management practitioners focus on the following areas: 

Find Your Proper Place in the Organization: Instead of an “Information Architecture Steering Committee” or a “Business Architecture Steering Committee”, USAA established a “Unified Architecture Steering Committee” that represents business architecture, information architecture, process architecture, IT architecture, change management, and organizational design. 

To closely align Business Architecture with both business strategy and IT partners, the architecture team is part of the Transformation and Integration group, which along with the Strategy team is part of the Enterprise Strategy and Planning organization reporting to the CEO.  IT Architecture lives within the CTO organization, reporting to the chief administrative officer who also reports to the CEO. While EA and IT do not report to the same organization, they work closely together daily – a key success factor.

Think Through Your Model: Correctly “architecting the architecture” improves the accuracy and maintainability of the models over time. Pemberton recommends, for example, using one model only for processes, another only for data, and another only for information. That way, he says, each model “will be simple as it can be, with the simplest mappings” but represent the complexity of the organization through “the relationships among the elements of each model.” He also recommends using a metamodel, like Troux’s that limits flexibility within each model, but allows flexibility among models. “That forces you to have better architectural practices,” he says.

USAA is using Troux to build a common repository and metamodel designed to unify the architects into a single, cohesive community.

Visualizations: Pemberton jokes about the pain the architecture team experienced trying to teach business managers to use EA models, rather than “enlightening” them with well-done visualizations that answer their critical business questions. After being told in no uncertain terms they weren’t useful, he says, the architecture team will “never again show one of our primitive models to the business. Our visualizations must be highly graphical, and show things like context, rather than content, and convey understanding and meaning, rather than information.”

Let the Business Use Its Own Vocabulary: The architecture team has very rigorous rules for naming functions with its models, but allows business executives to use more familiar names for functions within visualizations. “We maintain aliases to our strict definitions, but let the business use the terms with which it’s comfortable.” That way, business users get the answers they need, while the architecture team can enforce the rules that assure consistency and accuracy over time. Similarly, “If we are presenting a methodology to the business and use the word ‘architecture’ eyes glaze over,” he says. “We’ve learned to use the phrase ‘business design’ and business users respond ‘Ah ha! You are helping me design my business.’”

Build Your Capacity:  Watch out for what Pemberton calls “killer demand curves” where business users suddenly demand lots of full architectures – immediately. “If you don’t have an EA practice that’s built to scale up to deliver quickly on demand, the business becomes disenchanted and sees you as an ivory tower, and what you do as vaporware.” Rather than deliver only visualizations, USAA’s architecture team is creating other deliverables such as a “Unified Business Design Playbook” that documents common methods for aligning deliverables across the organization. That’s among the ways it is attempting to scale the architecture by turning it into a multi-disciplinary, collaborative team sport.

As USAA’s EA/BTM practice continues to progress, he says, “the biggest benefit will be through the delivery of better business outcomes, through the reduction of redundancy and risks and sharing costs”.

It’s a far cry from being seen as an ivory tower exercise – and the key has been focusing on the needs of business users at all levels and delivering architectures in a form they can use.

To watch a replay of Michael Pemberton’s webinar, click here