Relationship of Business Architecture to EA Practice

Transcription

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 1

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 2

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 Some denial on the business-side that IT is a critical component of the company 3

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 topsdown 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 4

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 o Methods have to be nimble; can t build in too much structure 5

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? 6

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 Process models 7