LEADing w/Enterprise Architecture

LEADING w/Enterprise Architecture Leveraging EA to Define and Deliver the Future-State Version 1.0 DRAFT September 2009 Rod Dickerson rod.dickerson@verizon.net 1 1

WHY Current State Challenges (the Need for EA) WHAT Enterprise Architecture Practice WHO EA Participants (Roles & Responsibilities) HOW EA Approach & Process DO Key Performance Measures (KPIs) & Next Steps 2

IMPACTS (of having no architectural direction or standards) Operational / Efficiency Regulatory / Compliance Financial (Customer) Continue to solve the same problem over and No consistent way to anticipate requirements over again in advance Business Lack flexibility to quickly accommodate Inability to easily communicate principles, policies, standards, and architecture to new requirement changes employees or contractors Areas of Focus (Domains) No gauge on the cleanliness of the OAKS data No access specifications; staff has access to No retention specs; leads to keeping to much Data No identified measures for efficiency more than needed for role data User dissatisfaction leads to non-use; Scheduling problems workarounds, and help desk tickets Application Performance seen as less important than Poor performance leads to missed function leading to degraded run-times opportunities to do more with applications Inefficient processes No capturing and implementation of lessons Standards and policies not documented Technical Number of different environments supported - Standards not enforced leading to poor code learned and/or best practices increasing complexity and causing inefficiencies Poor knowledge transfer Controls tied to persons rolling off projects or Security roles Audit failures; invalid security assignments 3 WHY WHAT WHO HOW DO

To provide a mechanism (process & tool) that informs and guides technology decision-making Planning decisions Investment decisions Solution Design decisions To define a set of principles, policies, standards, guidelines, processes, reference models/architectures—anything that can help us make better decisions! 4 WHY WHAT WHO HOW DO

Decisions move us from the “as-is” to the “to-be”, one frequent step at a time We want to make our decision-making as effective as possible Focus on decisions makes EA action-oriented, real, and practical…rather than theoretical 5 WHY WHAT WHO HOW DO

Senior IT Management • Principles / Culture / Education • Decision Framework Doing the Right Things • Future State Recommendations • Decision Impact Vetting / Analysis • Research • Business Strategy • Best Practices • Industry Trends Enterprise Architecture • Technology • Laws / Regulations • Vendor Capabilities Business Data Application Technology Security • Research • Market Conditions • Policies • Standards Doing it Right • Guidelines • Governance • Design Reviews Development / Delivery 6 WHY WHAT WHO HOW DO

EA promotes decisions that: Align plans and investments with business priorities and needs Result in more citizen-friendly, integrated services Promote a more efficient IT infrastructure Facilitate cross-organizational sharing of enterprise information Recognize innovations and best practices from across the enterprise Are more consistent and predictable Trace back to principles and rules 7 WHY WHAT WHO HOW DO

Non-Stop Operations Efficiency Facilitate a highly available, maintainable Optimize IT spend environment Leverage vendors Ensure stability of IT platforms Lower costs Better performance of systems Prevent re-inventing Efficient use of resources Consistent behaviors, design pattern Manageability Common direction / guidelines Consistency in procedures Reduce errors Consistent decision-making Easier to train new associates Improve communications Simplifies environment and processes Makes environment easier to support Agility Reduces operating risks Faster decision-making Security and safeguards, protects integrity of Allows more expedient service our work Increase product time to market Reduce excuses 8 WHY WHAT WHO HOW DO

Help organize the elements we build to support decisions (the principles, policies, standards, reference models, etc.) Easier to include new elements Easier to find existing elements Promote reuse of architectural best practices Examples: NASCIO, TOGAF, Zachman, Federal EA 9 WHY WHAT WHO HOW DO

EA GOVERNANCE Views Reference Model Security Financial Business Regulatory Operational Application Security Data Business Technical Data Domains Governance Application Technical Security 10 WHY WHAT WHO HOW DO

Common & Shared Guiding Principles Future State Architecture Business Data Application Technical Security Design Principles Design Principles Design Principles Design Principles Design Principles Technologies Technologies Technologies Technologies Technologies Standards Standards Standards Standards Standards Products Products Products Products Products Configurations Configurations Configurations Configurations Configurations 11 WHY WHAT WHO HOW DO

Over-arching Principles, Drivers, Trends Framework Business Architecture Data Architecture Application Architecture Technology Architecture Security Architecture Solution Architecture Document Process Monitor Governance Review Communicate 12 WHY WHAT WHO HOW DO

Role Members Responsibilities Works with OAKS Senior Management to develop EA Primer and architecture policy. Oversees EA Chief Architect product development, use, and refinement. Serves as owner of EA repository and is responsible for Architecture Roles and Responsibilities architecture sequencing plan. Responsible for monitoring and controlling changes to the EA after initial development. Assesses Change Control Board business alignment, solution proposals, and technical compliance; evaluates architecture (CCB) compliance; assesses waiver/exception requests; and conducts standards review. Provides senior-level stakeholder and sponsor participation; works with architecture team on • Business Unit Managers Domain Owners • Application Managers standards insertion and renewal, assigns business line resources (subject matter experts [SMEs]) and oversees review of business architecture products. • Chief Architect Responsible for development and refinement of enterprise and application architectures and for • Business SME populating the EA repository. Develops formal standards requirements and manages the Enterprise • Technical Architect architecture processes; provides guidance to other teams. Provides for administration of the EA Architecture Core • Data Architect processes; influences agency officials so that project resources are obtained/retained, objections are Team (ARB) • Security Architect properly handled, progress is maintained, and a high-quality, usable architecture framework is • Application Architects established. Monitors and measures the architecture’s effect on projects via process and product • PMO measurements. Develop business, information, technology and solution architectures related to their specific domain. Participate in recommending and drafting architecture policies and standards. Define technical Application Architects services and infrastructure patterns within their specific domain. Collaborate with the enterprise architecture team in the development of domain architecture principles. Prepare domain architecture deliverables for submission to the Change Control Board (CCB) (as needed). Domain experts from within the Subject Matter organization (one from each business Support in documenting the defined mission or business requirements and related objectives; Experts unit); may be supplemented with supports definition of policies that impact business goals; reviews EA repository products. outside consultants 13 WHY WHAT WHO HOW DO

IT Steering Sets Priorities & Committee Resolves Conflict Request Change Project IT Change Control Teams Approves Changes Project Board Teams Implementers Advises of Change Consults Enterprise Architecture Team Reviews Directs Chairs Architecture Compliance & Review Board Recommends Actions Architecture Guidance Manages Provides Policies & Standards Direction & Recommends Facilitates / Chairs Approach Domain Policies & for Solution Domain Teams Domain Standards Options & Teams Reviews / Influences Design Teams Decisions Subject Matter Experts Collaborates Senior 1 Management 4 14 WHY WHAT WHO HOW DO

Connect Deliver • Developing an EA Capability is a major A common language/framework and change program that will not happen in approach, with supporting tools if a few months (acknowledge/plan for this) appropriate • Strong executive sponsorship from A clear governance model over within IT and Business projects/Solution Architectures, including • Working collaboratively with both sufficient Authority business and IT as partners A pragmatic approach so that we can • Regular targeted communication with delivery some results early and we are both the Business and IT not seen as just an ivory tower doing strategy stuff Architecture is a living thing. Use feedback from projects to learn and track the changing priorities and goals in the business 15 WHY WHAT WHO HOW DO

The Chief Architect retains the right and authority to veto any proposed changes presented to the Change Control Board that negatively impacts the environment (related to data, application, and/or technology changes) based on the degree of risk associated with the change; as determined by an Architecture Review and Assessment - based on approved Architecture Polices, Standards and/or stated Technology Direction. Vetoes are only to be used in instances where a proposed solution/implementation deviates from stated direction as prescribed in documented and sanctioned Polices and Standards; and where no alternative solution(s) has been presented or identified. Exceptions/waivers may be requested under certain circumstances; following the approval of a formal Risk Acceptance Document – with sign-offs from the appropriate business and IT accountable parties and their acknowledgement of the risk(s). Vetoes are ONLY valid for technology solution/implementation approaches, and have no bearing on the merit or criticality of the business requirement(s) associated with the proposed implementation. 16 WHY WHAT WHO HOW DO

Review technology plans & approach from the beginning Consistency with technology strategy Facilitate compromise between technical goals & real world constraints Assist/facilitate selection of technology & fit to architecture Assist with design of solutions Focus on architectural qualities Provide consultative input from conception to delivery Eliminate review surprises late in a project Provide an objective point of view to technology Develop w/team, the project’s reference architecture That ties to the Enterprise Architecture Assist/guide interface approach & specification 17 WHY WHAT WHO HOW DO

Reduction in project over-runs both in terms of cost and time without Reduced Project Risk and Complexity reduction of required scope Measure around quality of solution; the delivery on-time and within Improved Project Success budget Measuring ROI of projects over time – there is, however, an investment Cost Control and Improved ROI cost to start this (building reusable services) Operational costs of the IT estate to reflect the total cost of ownership Reduced Costs for Business As Usual and does not just shift (hide) costs elsewhere Progress in the delivery and sustaining of the IT Strategy, which itself Facilitate Delivery of IT Strategy will be delivering Value through IT This should become visible through better development metrics around Improved Business Requirements faults due to incorrect requirements Quality-related feedback from the business, for example through Better Alignment with Business annual surveys IT seen as an enabler and partner with the business and not just a cost Increased Agility & Competitiveness and constraint on the business Measure through effect, with the business becoming better connected, Improved Business Knowledge business units able to see themselves in context 18 WHY WHAT WHO HOW DO

Business Benefits IT Benefits • # Projects compliant with strategy • # Projects mapped to IT strategy • # Project overruns >x months • # Projects into support w/o issue • Ease of Access to Information • Rate of reactive infrastructure projects • Time to implement new capabilities • # Applications rationalized • # of security incidents • # Avoided purchases EA Coverage • % AS-IS architecture complete • % TO-BE architecture complete • % Migration Plans in-place • % Projects engaging design assurance • % Projects with solution architects EA Processes EA Presence • # Projects reviewed/rejected • # of architects in post • # Projects rejected 1st time • # of architects trained • Frequency of reviews • # of architects certified • % Projects engaging design assurance • # of approved standards in place • % Projects with solution architects 19 WHY WHAT WHO HOW DO

Commitment Time Requirement: ~4-6 hours per week Meeting Participation: ~1-2 (1 hour) working sessions per week and 1 (2 hour) ARB session monthly Reporting: Accountable to the Chief Architect for status reporting and deliverable completion Expectations Provide subject matter expertise in one or more of the EA Domains Gather, analyze and finalize business requirements in the context of required architecture Provide solution recommendations based on approved architecture standards and policies Develop recommendations and submit for review to the Architecture Review Board Focus on enterprise technology issues, not just a single agency or application perspective Understand that business requirements drive all technology decisions Develop solutions that: Fulfill business requirements; Leverage existing technology; Adhere to all standards and policy 20 WHY WHAT WHO HOW DO

Formalize Charter, Strategy, Management Process Agree on Time commitment from others Create detailed EA implementation Project Plan Execute and Communicate Measure KPI at implementation milestones 21 WHY WHAT WHO HOW DO

LEADing w/Enterprise Architecture

by Rod Dickerson on Sep 02, 2009

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 5

Statistics

LEADing w/Enterprise Architecture Presentation Transcript