220 likes | 634 Views
EA Best Practices: The Top 10 List and Case Studies. Daniel Chong. Key Issues. 1. What are the 10 best practices of enterprise architecture? 2. What benefits do organizations see when they apply these best practices consistently?
E N D
EA Best Practices: The Top 10 List and Case Studies Daniel Chong
Key Issues 1. What are the 10 best practices ofenterprise architecture? 2. What benefits do organizations see when they apply these best practices consistently? 3. What are the techniques for applying these best practices? 4. What can we learn from real world case studies regarding success?
The 10 Best Practices of Successful EA Programs 1. Charter Your EA Program 2. Develop (and Execute) a Communications Plan 3. Treat Each Iteration Like a Project 4. Start With the Business Strategy and Obtain Business Sponsorship 5. Do the Future State Before the Current State 6. Be Pragmatic 7. Don't Forget Governance 8. Set Up a Measurement Program 9. Track EA Program Maturity 10. Pay as Much Attention to Competencies as to Skills
1. Charter Your EA Program The EA program charter represents the agreement between the EA team and the stakeholders What is the value proposition? Who are the stakeholders? What are their obligations? What are the obligations of theEA team? What is the scope of the EA? What is the timeline for delivery? What is the governance model? 2. Develop a Communications Program Key Messages Audiences and Their Key Issues Messages by Audience Benefits/Value EA Creation Process EA Governance EA Measures Sponsoring Authority Media Used Intranet Publishing Meetings One-on-Ones Action Plan Action Items and Responsibilities Timeline: Actions and Milestones Expanding Participation Feedback Process The 10 Best Practices
3. Treat Each Iteration Like a Project EA is not a project —it's a process It has a beginning, but never ends Iterations ensure that the EA will respond to change In the business In technology In the external environment But without project discipline, it can meander Timelines Milestones Deliverables Responsibilities 4. Start with the Business Strategy Starting with the business strategy ensures that: The architecture supports the business goals of the enterprise (and you can demonstrate it). You are engaging the businessleadership on a subject they care about (they don't care about technology or architectural purity). You can identify the business value that the architecture must deliver. Obtaining business sponsorshipensures that: The business will support EA decisions. The business will understand the value that EA provides. The 10 Best Practices
5. Do the Future State Before theCurrent State EA is about what we haveto change, not what we currently have. Current-state analysis provides you with a very detailedpicture of how messed upyou really are. Developing the future state first constrains the level of detail required for the current state. "What do we need?" vs. "What can we do with what we have?" 6. Be Pragmatic Don't model everything in sight. Don't attempt to boil the ocean. Focus on the strategic imperatives of the enterprise and what's important (right now) to your business. Deliver value early and often. Be alert for signs of "modelitis." The 10 Best Practices
7. Don't Forget Governance EA governance Architecture creation Architecture compliance Characteristics of successful governance: Complements the business governance model Is lightweight Is integrated into the strategic and operational processes of the enterprise Has a waivering process (and the waivers have a shelf life) 8. Set Up a Measurement Program Metrics Program Internally Focused Externally Focused Is the EA program delivering what it said it would deliver? How mature is the EA program compared to best and common practice? How does the EA program impact IT directly? How does the EA program impact the business directly? Program Deliverables Program Maturity IT Benefits Business Benefits The 10 Best Practices
9. Track EA Program Maturity Part of a continuous improvement program Focuses on critical constraints What are the problems that are preventing you from being effective? EA programs must change over time As the enterprise matures and changes The 10 Best Practices APMA Results Architecture Scopeand Authority 5.0 Stakeholder Involvementand Support Architecture Impact 4.0 3.0 2.0 ArchitectureTeamResources 1.0 ArchitectureDevelopment 0.0 Future-StateRealization Business Context Architecture Content Self Reported Results Gartner Average Target
10. Pay as Much Attention to Competenciesas to Skills Skills Create EA Documents Manage EA Processes Define EA Governance And so on… Competencies Conceptualization Innovation Enterprise perspective Foresight Consensus building Facilitation Leadership Logic Communication Enterprise architects must possess the necessary competencies before learning the tools of the trade The 10 Best Practices
What Are the Benefits of a Best Practices EA Program To the IT Organization? • Reduced technology diversity • Planned rather than Ad Hoc • Reduced cost • Support costs • Project costs • Increased reuse • Operational stability • Less "management by magazine" • Reduced dependence on flavor of the month To the EA team? • Stability • Job satisfaction • Opportunities for personal and professional growth • Recognition of the valueof the EA • By the business • By the IT organization To the business? • Alignment with the business strategy • Faster time to market • Greater agility • Greater consistency • Better decision making • Better ROI • Better information
Tips and Techniques • Time-box • Don't try to change everything at once • Rome was not built in a day • Carry a bigger carrot than stick • Make sure you understand the incentives and disincentives of your constituencies • Make sure that you're focusing on the important stuff • If it's not going to make a real difference, it's not worth doing — no matter how elegant the solution is • Get management sign-offs (EA Charter, CRV, plan) • If senior managers will not commit support in writing, the program may be in trouble
Case Study 1 – Banking Organization • A multi-national Bank with one of the largest branch networks in the world • One of North American top 10 • Multiple lines of business – banking, trust, investment services, insurance • Highly sophisticated organization – leading edge in many areas Bottom Line • Technology architecture is often an IT focused initiative, and for that reason prone to failure, or lack of relevance to the organization. This case study demonstrates how to overcome these traditional issues
Background and Approach EA team recently established and looking to establish first iteration of the Technical Architecture Very complex environment with highly diversified infrastructure – the goal was to make this more manageable Technology knowledgeable business owners capable of making IT decisions and adopting line of business solutions – proliferating IT diversity Developed first iteration of Technology Architecture through a collaborative approach involving IT, business and EA Facilitated through interviews, workshops and stakeholder reviews Results Established a set of IT domain definitions, and developed first specification of architecture “bricks” Identified IT and business stewards for bricks, as well as subject matter experts with overall responsibilities for architectural maintenance and renewal Established vendor management processes to streamline and manage IT and solution acquisition Eliminated direct buying from lines of business Full endorsement and adoption by the business of the bricks All new procurements require brick specifications in the RFP All variances driven from the business – no new technologies without granting of exceptions Governance framework and processes established to manage ongoing architectural renewal, as well as compliance and variance processes Case Study 1 – Bankingcontinued
Lessons Learned Participation of business and IT in the development of the architecture was crucial EA did not “own” the resultant architecture Leveraged a virtual EA team Highly knowledgeable business staff as well as all IT areas named as stewards and SMEs To be successful, the architecture must be internalized into the day to day operations of the enterprise Architecture is a way of doing business – ingrained into the way business is enacted Governance was a key Understanding ownership, decision rights and processes allowed the architecture to be used effectively Best Practices Applied Charter your EA program Develop and execute a Communications Plan (this project was “branded”) Treat each iteration like a project Start with business strategy and obtain business sponsorship Be pragmatic (goal was not to eliminate diversity, but to manage it) Don’t forget governance Case Study 1 – Bankingcontinued
Case Study 2 – Financial Services Organization • A large regional Property and Casualty and Health Insurer based in the United States • In business over 80 years. Over $15.5B in assets under management, over $4B in policyholder equity • Offers auto, home, life & annuities, health, business and farm & ranch insurance • Operates in 19 states Bottom Line • Many EA programs want to drive “up the value chain” in terms of evolving their EA focus to be more business focused. However, engaging the business is often easier to propose that realize. This case study discusses a best practice example of how to achieve real engagement
Background and Approach EA team was already established. Technical Architecture / Standards were in place – wanted to evolve to the next level of maturity Wanted to focus on business alignment and value – followed Gartner approach and developed a common requirements vision (CRV) Team involved representatives from key lines of business and strategic planning group and EA Used a six week time-boxed approach for CRV development – focused on a “good enough” product Results “Hugely” successful Produced a set of key initiatives and business solution requirements for the organization Produced a set of architectural principles to support and aid decision making and governance for the organization Full endorsement and adoption by the business at senior management levels Used by the PMO to assist in project prioritization and funding Now in second iteration – will become integrated with the overall strategic planning processes for the organization Case Study 2 – Financial Servicescontinued
Lessons Learned Scope was practical – focus of the CRV was not organization wide but on 3 select business areas Used business plans and strategies to drive the CRV – this ensured relevance and alignment Future focused – did not analyze current initiatives or plans Full participation from the business – representatives at senior levels, with involvement in all workshops and reviews EA team focused on “doing the work” – business teams focused on “validating and approving the results” Time boxed – this prevented the CRV from endless iterations of successive refinement Best Practices Applied Charter your EA program Develop and execute a Communications Plan Treat each iteration like a project Start with business strategy and obtain business sponsorship Be pragmatic Case Study 2 – Financial Servicescontinued
Case Study 3 – State Government Organization • A large State Government organization • Facing numerous challenges due to the dire economic situation in the state – impacts on Social Services, Tax, Health, Criminal Justice and other agencies Bottom Line • Many organizations struggle with enterprise wide Information Architectures, particularly in governance and ownership – this is especially difficult in the public sector. This case study highlights a successful implementation, something rare in this domain
Background and Approach IM team recently established for the state, with a focus on developing state wide information architecture in conjunction with the technology architecture team Many different data warehouses and information sources across the state Varied and duplicate infrastructures No common semantics Extremely difficult to share and exchange information Emerging needs for analyzing data across different agencies E.g. criminal justice with education, healthcare with welfare, etc. Established a multi-agency task force to collaboratively develop first iteration of a state-wide information architecture Team worked on defining requirements, analyzing alternatives, and ratifying recommendations IM/EA team developed alternatives and approaches Results Adoption of a strategy that supported an enterprise wide approach for information sharing while maintaining individual agency repositories Developing of common semantics for shared information assets across the state Citizen Locations Etc. Developed a state-wide data warehouse that has allowed the state to alter health/human services outcomes, and save the state hundreds of millions of dollars Applications include: Fraud detection (Health, Tax, Human Services) Cross agency withholdings Improved program policy And many others Case Study 3 – State Government continued
Lessons Learned Scope was practical – did not try to rationalize all information sources across the state – but to provide an enterprise “slice” Multi-agency approach ensured buy-in and support from all stakeholders Focus not on technology/infrastructure, but on business issues and implications – semantics, data ownership and stewardship, data sharing agreements – these drive success, not concerns such as the DBMS Governance a key issue given the multi-agency focus and the government context Benefits measurement and quantification a CSF – understanding the value drives continued development Best Practices Applied Develop (and Execute) a Communications Plan Start with business strategy and obtain business sponsorship Do the Future State Before the Current State Be pragmatic Don't Forget Governance Case Study 3 – State Government continued
Contact Information Gartner Contact Daniel Chong Vice President, Gartner Consulting Telephone: +1-416-228-7662 Email: daniel.chong@gartner.com