13 years, 3 months ago

Troux 2011: Journey to the Business Side of Enterprise Architecture at USAA

Link: http://www.biske.com/blog/?p=830

Speaker: Michael Pemberton, Enterprise Architect and USAA

USAA has had an enterprise architecture practice on the technology side and is now establishing a business architecture practice.

First point: Why did USAA take the journey? They realized that without a business-driven, integrated enterprise architecture, it would be like driving without a map.

Their challenge was that they are trying to increase their revenue and the membership, but at the same time, reduce their operating ratio. They needed to reduce the complexity and operating friction within the organization.

For them, being too close to the Enterprise Strategy team was a problem for their Enterprise Architecture team. It may seem counterintuitive, but there are some pressures to keep the strategy team “clean” while the Enterprise Architecture team needed to be out there working with the community.

Models need to be designed to answer questions. The business doesn’t care about the components and representation in the model, they care about the answer to the question they asked. They aim to create visualizations for the enterprise.

USAA Opportunities and Challenges:

  • No metamodel, no design!
  • Architect architecture
  • Business focused architecture
  • Visualizations, visualizations, visualizations
  • Roadmap capabilities
  • Killer curves: supply/demand

They showed a visualization which was essentially a spoked wheel with member at the center of the universe. A layer out from the member was a set of capabilities, then another decomposition to the business level, and then finally a set of processes out in the business. They found the normal “box-in-box” capability view to be unwieldy for the number of capabilities they had.

They also made a commitment to never come to the business with a single taxonomy again. They needed a single taxonomy to do their work, but the business needed to see the results in their own language and taxonomies. They create taxonomy alignment, but they don’t force a single taxonomy on the entire organization.

Principles they use for their visualizations are:

  • Use graphics, not words (look up InfoGraphics)
  • Show context and meaning NOT context and conclusion
  • Enlightenment NOT training
  • if you ever show the business your model, you deserve whatever you get – and it won’t be pleasant
  • Quit telling executives they should use the tool!

Post to Twitter