Relationship of Business Architecture to EA Practice

1

Twin Cities Business Architecture Forum

20 September Session Notes

Relationship of Business Architecture to EA Practice

Target

 Enterprise Architecture is accountable for application and technology direction and portfolio management

 IT Strategy team is accountable for business architecture standards and practices

 IT Business Relationship Managers* (BRMs) are accountable for actually defining and planning for their business capabilities and business processes

 Business Architecture is fairly well socialized within IT, but still is a challenge to sell to business partners

 *NOTE: many of the organizations had a business relationship management function that acts as a liaison between the business and IT. Most of these are all called something different, so for the sake of taking notes we captured this generically as a Business Relationship Manager (BRM). Express Scripts

 Business Architecture is located within the IT organization, primarily within a BRM-type function  One challenge of this is the matrixed structure of the BRM function (e.g., some are product

oriented, some IT oriented, while others are aligned with business lines); sometime each area works at cross-purposes

 This dynamic makes the Business Architecture practice fuzzy

 Overall, Business Architecture is facing some buy-in challenges both within IT and the business US Bank

 IT Strategy team is accountable for business architecture standards and practices, separate from the EA practice

 BRM function is aligned by Line of Business, and is a practitioner of Business Architecture  Business architecture has good adoption inside and outside of IT

Thrivent

 The Enterprise Architecture practice is matrixed across the organization

o Accountable for technology portfolio management, asset management and technical planning

o While reporting is matrixed, there is a centralized director for an enterprise EA vision  IT Strategy team is accountable for business architecture standards and practices, separate from

the EA practice

o Business Architects were centralized under Strategy & Planning to drive more consistency in the Business Architecture practice

2 o Are now able to swarm Business Architects to high-priority work better/faster

 Business Architecture is aligned to each BRM organization

 Thrivent has achieved real business buy-in from the C-suite on down in the organization  In the long-term, the Business Architecture practice may be migrating towards the business Ameriprise Financial

 EA team is accountable for business architecture standards and practices

 EA is also accountable for application, information and technology standards and portfolio management

 VP of Business Architecture reports directly into the CIO; he is the creative arm of business architecture and is more of a innovation officer within the IT department

MoneyGram

 Business owns business process management and improvement

 IT owns IT strategy, product management – but no real “branded” Business Architecture practice

 There are some early signs that Business Architecture could be taking hold within IT Wells Fargo

 Has a patchwork of Business Architecture initiatives

 Business Architecture is owned by the business in some areas, and by IT in others

 There is enough sensitivity around the title “business architect” that IT can’t always go by that moniker

 However, Business Architecture has had some limited success; it needs to be tied to some kind of governance to really ensure that it is successful long-term

 Is long-term trying to figure out what should the role of Business Architecture be Metropolitan Life

 Business Architecture is within the business

 Business Architecture is driven by key business metrics (e.g., cost savings, sales lift, etc.)  Business Architecture enjoys a good partnership across business and IT

Cargill

 Business architecture is positioned within EA; they help define what it is and the overall associated practices

 Much of the Business Architecture practice is oriented around a large-scale program implementation

 With that context, Business Architecture has not yet been applied to the entire enterprise  This is becoming to change with some merger and acquisition work

3 Optum Health (UHG)

 Business Architecture practice is centralized under Optum

 There is an enterprise (UHG) practice that trickles down, but primarily the team is using what was developed locally

 Large EA team

GMAC/RFC (as of several years ago)

 Project, Data and Process Stewards existed on the business side (outside of IT) to help promote a Business Architecture-like environment

Excel Energy

 Largely think in terms of applications and not business capabilities  Has a young EA practice, focused largely on technical standards

4

Thoughts on Governance

What do we (or can we) govern?

 Business capabilities – how these are defined and used  Mapping between IT investments and business capabilities  Investment process guided by (or based on) capabilities  Artifacts: capability models, definitions, etc.

Different perspectives on governance

 Strategic governance vs. tactical governance (i.e., governing the overall planning process vs. governing the execution once funding has been achieved)

 “Legislative” process vs. “Cops on the Beat”

 Some resistance to using the word “governance” particularly with respect to how IT interacts with business (e.g., “business architecture enables business strategy” vs. “business architecture governs business strategy”)

 Business Architecture inherently governed through enterprise strategy and planning as we participate in and align with business strategy

 Business architecture supporting governance rather than being something that is actively governed

Thoughts on roles

 Business “steward” of capabilities at a domain level o VP-level individuals (but tasks are often delegated)

o Primarily involved in change control and communication of changes  Getting to the right level within an organization

o Starting at grass roots level, but then pushing out and hopefully eventually driving tops-down

 Invoke tops-down support to bring planning up to an enterprise level Ways to apply governance

 Help to raise awareness

 Facilitate consensus building around “horizontal” capabilities (those that span departments or domains; areas where there is no natural owner or steward)

 Help communicate / demonstrate value of business architecture to drive adoption o Helping to inform investment decisions

o Value to be found in fostering reuse  Tying health of assets to capabilities

o Tying health to importance of a capability within the organization

o Next step would be tying resources to capabilities to inform sourcing models  Improving communication (creating a dialogue versus a one-way communication)

o Help to bring all the pieces back together across capabilities and down into specific domains

o Create feedback loops to help leverage information

o Connecting business drivers all the way down into operational layers  Helping to connect the dots

5 o Way to update roadmaps as work gets done

o Support care and feeding of the architecture over time o Keeping maps and models current

 Governing the discipline of Business Architecture

o Figuring out who collectively owns the “work” of business architecture o Ensuring consistency and standards over time

6

Thoughts on Tools

Key questions discussed by each group

 Describe the tools in place at your company.

 Do you centralize the artifacts? Integration to other EA applications?

 Do/did you lead with a tool and build a practice around the tool or vice-versa?  What are the librarian/data stewardship roles for your tool/artifacts?

Common Themes

 Tools front end – none, powerpoint, visio, excel, homegrown with visio overlay, word to Aris, Casewise (some are in the process of evaluation tools (blue works, enterprise architect (sparx)  Back end – local (BA’s hard drive, LAN, SharePoint/plan, MS Access, SQL Server, Excel, enterprise

tool

 In general - Most lead with a practice, then a tool vs. tool then practice  Librarian – none, BA’s own their own, limited sharing, defined roles on IT side.

Comments:

 Maybe keep it all simple vs. million dollar tools  Our tool is not low tech, but our data is (low tech)

 Should the librarian reside in the business? Ever? And Why?  Industry wise – where are the tools and their artifacts housed?

7

Methods / Artifacts

The following emerged as common methods in business architecture planning and execution  Business Capability Frameworks

 Business Capability Strategic Plans  Capability Roadmaps

 Balance Scorecard  Remediation Plans

 Strategy on a Page (simple strategy)  Value chains