LEADing w/Enterprise Architecture

LEADING w/Enterprise ArchitectureLeveraging EA to Define and Deliver the Future-State

LEADING w/Enterprise ArchitectureLeveraging EA to Define and Deliver the Future-State

1

Rod Rod Rod Rod Dickerson Dickerson Dickerson Dickerson

[email protected]@[email protected]@verizon.net

1

Version 1.0 DRAFTSeptember 2009

Version 1.0 DRAFTSeptember 2009

WHY

WHAT

Current State Challenges (the Need for EA)

Enterprise Architecture Practice

2

HOW

WHO

DO

EA Approach & Process

EA Participants (Roles & Responsibilities)

Key Performance Measures (KPIs) & Next Steps

IMPACTS (of having no architectural direction or standards)

Operational / Efficiency(Customer)

Regulatory / Compliance Financial

Areas of Focus (Domains)

Business

� No consistent way to anticipate requirements in advance

� Lack flexibility to quickly accommodate requirement changes

� Continue to solve the same problem over and over again

� Inability to easily communicate principles, policies, standards, and architecture to new employees or contractors

3

Areas of Focus (Domains)

Data� No gauge on the cleanliness of the OAKS data� No identified measures for efficiency

� No access specifications; staff has access to more than needed for role

� No retention specs; leads to keeping to much data

Application� Scheduling problems� Performance seen as less important than

function leading to degraded run-times

� User dissatisfaction leads to non-use; workarounds, and help desk tickets

� Poor performance leads to missed opportunities to do more with applications

Technical� Inefficient processes� Number of different environments supported -

increasing complexity and causing inefficiencies

� Standards and policies not documented� Standards not enforced leading to poor code

� No capturing and implementation of lessons learned and/or best practices

� Poor knowledge transfer

Security� Controls tied to persons rolling off projects or

roles� Audit failures; invalid security assignments

WHYWHY WHATWHAT HOWHOWWHOWHO DODO

� To provide a mechanism (process & tool) that informs and guides technology decision-making� Planning decisions

� Investment decisions

� Solution Design decisions

4

� Solution Design decisions

� To define a set of principles, policies, standards, guidelines, processes, reference models/architectures—anything that can help us make better decisions!


� 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,

5

� Focus on decisions makes EA action-oriented, real, and practical…rather than theoretical


Senior IT Management

Enterprise Architecture

Doing the Right Things

• Business Strategy• Best Practices• Industry Trends

• Principles / Culture / Education• Decision Framework• Future State Recommendations• Decision Impact Vetting / Analysis• Research

6

Enterprise Architecture

Development / Delivery

Doing it Right

• Policies• Standards• Guidelines• Governance• Design Reviews

• Industry Trends• Technology• Laws / Regulations• Vendor Capabilities• Research• Market Conditions

Business Data Application Technology Security


� 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

7

information

� Recognize innovations and best practices from across the enterprise

� Are more consistent and predictable

� Trace back to principles and rules


� Non-Stop Operations� Facilitate a highly available, maintainable environment

� Ensure stability of IT platforms

� Better performance of systems

� Manageability

� Efficiency� Optimize IT spend

� Leverage vendors

� Lower costs

� Prevent re-inventing

� Efficient use of resources

� Consistent behaviors, design pattern

� Common direction / guidelinesManageability� Consistency in procedures

� Consistent decision-making

� Improve communications

� Simplifies environment and processes

� Makes environment easier to support

� Reduces operating risks

� Security and safeguards, protects integrity of our work

� Common direction / guidelines

� Reduce errors

� Easier to train new associates

� Agility� Faster decision-making

� Allows more expedient service

� Increase product time to market

� Reduce excuses

WHYWHY WHATWHAT HOWHOWWHOWHO DODO8

� 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

9

� Easier to find existing elements

� Promote reuse of architectural best practices

� Examples: NASCIO, TOGAF, Zachman, Federal EA


Ap

plic

atio

n

Business

Ap

plic

atio

n

Business

Reference Model

EA GOVERNANCE

Operational

Regulatory

Financial

Security

Views

GovernanceGovernance

Dat

a

Sec

uri

ty

Ap

plic

atio

n

Technical

Governance

Dat

a

Sec

uri

ty

Ap

plic

atio

n

Technical

Do

mai

ns

Technical

Security

Application

Data

Business

10 WHYWHY WHATWHAT HOWHOWWHOWHO DODO

BusinessBusiness

Design Design PrinciplesPrinciples

Common & Shared Guiding PrinciplesCommon & Shared Guiding Principles

Future Future State ArchitectureState Architecture

DataData


ApplicationApplication


TechnicalTechnical


SecuritySecurity


ProductsProducts

TechnologiesTechnologies

StandardsStandards

ConfigurationsConfigurations

ProductsProducts


StandardsStandards


ProductsProducts


StandardsStandards


ProductsProducts


StandardsStandards


ProductsProducts


StandardsStandards



Framework BusinessArchitecture

DataArchitecture

ApplicationArchitecture

Solution Architecture

Over-arching Principles, Drivers, Trends

TechnologyArchitecture

SecurityArchitecture

Process

12

Document

Review

Communicate

Monitor Governance


Arc

hit

ectu

re R

ole

s an

d R

esp

on

sib

iliti

es

Role Members Responsibilities

Chief ArchitectWorks with OAKS Senior Management to develop EA Primer and architecture policy. Oversees EA product development, use, and refinement. Serves as owner of EA repository and is responsible for architecture sequencing plan.

Change Control Board (CCB)

Responsible for monitoring and controlling changes to the EA after initial development. Assesses business alignment, solution proposals, and technical compliance; evaluates architecture compliance; assesses waiver/exception requests; and conducts standards review.

Domain Owners • Business Unit Managers• Application Managers

Provides senior-level stakeholder and sponsor participation; works with architecture team on 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

13

Arc

hit

ectu

re R

ole

s an

d R

esp

on

sib

iliti

es

Enterprise Architecture Core Team (ARB)

• Chief Architect• Business SME• Technical Architect• Data Architect• Security Architect• Application Architects • PMO

Responsible for development and refinement of enterprise and application architectures and for populating the EA repository. Develops formal standards requirements and manages the architecture processes; provides guidance to other teams. Provides for administration of the EA processes; influences agency officials so that project resources are obtained/retained, objections are properly handled, progress is maintained, and a high-quality, usable architecture framework is established. Monitors and measures the architecture’s effect on projects via process and product measurements.

Application Architects

Develop business, information, technology and solution architectures related to their specific domain. Participate in recommending and drafting architecture policies and standards. Define technical 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).

Subject Matter Experts

Domain experts from within the organization (one from each business unit); may be supplemented with outside consultants

Support in documenting the defined mission or business requirements and related objectives; supports definition of policies that impact business goals; reviews EA repository products.


Approves ChangesP

roje

ctT

eam

s

Sets Priorities & Resolves Conflict

Implementers of Change

Consults

IT Change Control Board

Tea

m

Pro

ject

Tea

ms

IT Steering Committee

Request Change

Advises

Subject Matter Experts

Reviews Compliance & Recommends Actions

Recommends Policies & Standards

DomainTeamsDomain

TeamsDomainTeams

Facilitates / Chairs

ArchitectureReview Board

Manages

En

terp

rise

Arc

hit

ectu

re T

eam

Architecture Guidance

Policies &Standards

Dir

ects

Chairs

Senior Management

Collaborates

Reviews / Influences

Provides Direction & Approach for Solution Options & Design Decisions

14


Connect

• Developing an EA Capability is a major change program that will not happen in a few months (acknowledge/plan for this)

• Strong executive sponsorship from

• Developing an EA Capability is a major change program that will not happen in a few months (acknowledge/plan for this)

• Strong executive sponsorship from

Deliver

� A common language/framework and approach, with supporting tools if appropriate

� A clear governance model over

� A common language/framework and approach, with supporting tools if appropriate

� A clear governance model over

15

• Strong executive sponsorship from within IT and Business

• Working collaboratively with both business and IT as partners

• Regular targeted communication with both the Business and IT

• Strong executive sponsorship from within IT and Business

• Working collaboratively with both business and IT as partners

• Regular targeted communication with both the Business and IT

A clear governance model over projects/Solution Architectures, including sufficient Authority

� A pragmatic approach so that we can delivery some results early and we are 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

A clear governance model over projects/Solution Architectures, including sufficient Authority

� A pragmatic approach so that we can delivery some results early and we are 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


� 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.

16

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.


� 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

17

� 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


Reduced Project Risk and Complexity Reduction in project over-runs both in terms of cost and time without reduction of required scope

Improved Project Success Measure around quality of solution; the delivery on-time and within budget

Cost Control and Improved ROI Measuring ROI of projects over time – there is, however, an investment cost to start this (building reusable services)

Reduced Costs for Business As Usual Operational costs of the IT estate to reflect the total cost of ownership and does not just shift (hide) costs elsewhere

18

Facilitate Delivery of IT Strategy Progress in the delivery and sustaining of the IT Strategy, which itself will be delivering Value through IT

Improved Business Requirements This should become visible through better development metrics around faults due to incorrect requirements

Better Alignment with Business Quality-related feedback from the business, for example through annual surveys

Increased Agility & Competitiveness IT seen as an enabler and partner with the business and not just a cost and constraint on the business

Improved Business Knowledge Measure through effect, with the business becoming better connected, business units able to see themselves in context


• % AS-IS architecture complete

EA Coverage

• # Projects compliant with strategy• # Project overruns >x months • Ease of Access to Information• Time to implement new capabilities• # of security incidents

Business Benefits • # Projects mapped to IT strategy• # Projects into support w/o issue• Rate of reactive infrastructure projects• # Applications rationalized• # Avoided purchases

IT Benefits

• % AS-IS architecture complete• % TO-BE architecture complete• % Migration Plans in-place• % Projects engaging design assurance• % Projects with solution architects

• # Projects reviewed/rejected• # Projects rejected 1st time• Frequency of reviews• % Projects engaging design assurance• % Projects with solution architects

EA Processes • # of architects in post• # of architects trained• # of architects certified• # of approved standards in place

EA Presence


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 � 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 WHYWHY WHATWHAT HOWHOWWHOWHO DODO

� Formalize Charter, Strategy, Management Process

� Agree on Time commitment from others

� Create detailed EA implementation Project Plan

21

� Create detailed EA implementation Project Plan

� Execute and Communicate

� Measure KPI at implementation milestones
