A Day in the Life of an EA

35
Copyright © Adrian Campbell. All rights reserved. A day in the life of an Enterprise Architect Adrian Campbell – Enterprise Architecture Consultant V2

description

A day in the life of an Enterprise Architect

Transcript of A Day in the Life of an EA

Page 1: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

A day in the life of an Enterprise Architect

Adrian Campbell – Enterprise Architecture Consultant

V2

Page 2: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Topics What is Enterprise Architecture (EA) Scope of the EA role Drivers for EA EA team EA Role activities Skills and experience needed Typical Challenges EA Process and its alignment to other processes EA Pitfalls (by Gartner)

Page 3: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

What is Enterprise Architecture?

Page 4: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

What is Enterprise Architecture? A process

For developing and using enterprise architecture in an enterprise

A product The complete and consistent set of methods, rules and

models, which will guide the (redesign, migration and implementation of business products and services, processes, organisational structures, information, applications and the technical infrastructure within an enterprise.

Page 5: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Enterprise ArchitectureA definition of Enterprise Architecture is addressed in 2 constituent

parts – enterprise and architecture. The Open Group defines ‘enterprise’ as follows:

An ‘enterprise’ is any collection of organisations that has a common set of goals and/or a single bottom line. In that sense, an enterprise can be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organisations linked together by common ownership.

Gartner define ‘architecture’ as follows; 1. The grand design or overall concept employed in creating a

system, as in the architecture of a city or a customer information system; also "an abstraction or design of a system, its structure, components and how they interrelate"

2. A family of guidelines (concepts, policies, principles, rules, patterns, interfaces and standards) to use when building a new IT capability.

Page 6: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Scope of EA Strategic / long term viewpoint (up to 3 to 5 years in the future) Support the CIO/CTO and main board Supports the Business

Aligning the IT Strategy with the Business Strategy and Business Operating Model

Architects the (extended) Enterprise and not just the organisation EA provides value by supporting:

IT enabled policy changes Major initiatives Change programmes

EA is mainly seen as an IT management leadership role Not as a Project/Solution/Technical Architect role But many organisations new to EA confuse these roles

Page 7: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Drivers for EA Support major programmes for:

Ecommerce Consolidation Cost reduction New organisation Mergers & Acquisitions Smarter solutions Reuse of shared services New technology Regulatory

Page 8: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

The EA Team Chief Enterprise Architect Enterprise Architect

Business Architect Information/Data Architect Application Architect Infrastructure Architect Security Architect Domain Architect

Business Unit Architect (Focused on a Business Domain) Functional Domain Architect (focused on a Business Function)

Virtual Architecture Team Solution Architect

Page 9: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Example: Viewpoints of an EA team

System Thinker

FacilitatorVisionary

Governance

Quality Assurance Design

Assurance

Compliance

Business Viewpoint

Architecture Viewpoint

Governance Viewpoint

Enterprise Architecture

StrategistBusiness Support

ArchitectureDevelopment Process

Page 10: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Stakeholders

Page 11: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Skills of an EA Motivation

Evangelist Visionary about the future Leadership

Negotiation Most EAs are contributors and do not have organizational power

System Thinking Problem Solving Business knowledge and credibility. Process knowledge Innovative Soft Skills

Management Persuasion

Page 12: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Stakeholder management Review Business Strategy Contribute to IT Strategy Modelling the enterprise architecture (current and future

states) Develop EA Roadmaps Develop EA reference architecture Evaluation of vendors Support the initiation of programmes and projects Decision making (Governance, Compliance and Design Assurance) Communication

Page 13: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Stakeholder management

Engaging Planning Meetings Messages Requirements Workshops

Page 14: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Review Business Strategy

Goals Objectives Measures Business Operating model Business Policies Regulations

Page 15: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Contribute to IT Strategy

Patterns IT policies Guidelines Product specific roadmaps and blueprints Standards

Page 16: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Modelling the enterprise architecture

Develop future state enterprise architecture models (interim and future states)

High level design of architecture building blocks Develop current state enterprise architecture model Contribute to Solution Architecture models

Page 17: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Develop EA Roadmaps

Sequence of initiatives and activities to achieve the future state architecture

Via interim states Provide timely value at all stages Align IT initiatives with Business Initiatives Initiatives feed into a ‘funnel’ of procurement, funding and

programme management processes

Page 18: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Develop EA reference architecture

Often as an EA web site and/or EA Handbook Standards Patterns Guidelines Standards Blueprints

Aligned to industry specific reference models FEAF eTOM XGEA IFW IAA

Page 19: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Evaluations of:

Vendors or Suppliers Their product and service offerings

Page 20: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Support the initiation of programmes and projects

EA initiatives help to scope and define programmes and projects to be initiated

Support the governance and compliance of programmes from the enterprise perspective

Page 21: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Decision making - Governance

Architecture Review Board Strategic Architecture Forum IT Management meetings

Operational status Costs Incidents Risks Portfolio of changes

Regulatory Mandatory Business as usual

Page 22: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Decision making - Compliance Ensure that Solution Architects have complied with:

Future state enterprise architecture EA reference architecture (patterns, IT policies, guidelines, reference

models etc.)

Exemptions and waivers for non-compliance Solution Architecture / Project Steering Boards

Quality Gates (i.e. OGC Gateways)

Page 23: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Decision making – Assessment/Design Assurance Approval to continue/sign off during Quality Gate/Steering group

meetings Business Strategy Planning

Idea/vision stage Feasibility study High level cost estimation

Programme Management (i.e. MSP) Project Management (i.e.Prince2) Solution Development (i.e. RUP):

Inception phase Elaboration phase Construction phase Transition phase

Service Delivery (i.e. ITIL) Production Operation

Page 24: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Activities of an EA Communication

EA by walking around Communication can be up to 40% of the role Preparing messages, presentations, posters Develop and maintain an EA web site Publish a status Dashboard and MI reports Publish EA models and artefacts on the Intranet

Page 25: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

The EA Process Based on TOGAF ADM or FSAM or Spewak Should be aligned with other standard processes:

COBIT MSP Prince 2 RUP ITIL etc.

And with non-standardised processes for: Strategic Planning Procurement Cost Estimation etc.

Page 26: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Example: IT management processes around EA

IT Strategy & Vision

Governance

Compliance

Performance

Solution Development

Provide Architecture DirectionCommunicate ArchitectureDefine Architecture BlueprintsDefine Principles, Standards and Best PracticeDefine Architecture Reference ModelsDefine Target Enterprise Architecture

Perform Architecture Compliance AssessmentAssess Architecture Compliance (for Applications and Services)Provide auditMonitor Applications and ServicesMonitor QualityMonitor SecurityMonitor the Enterprise ArchitectureUpdate the Enterprise ArchitectureAssess the Architecture Maturity Level

Collect Architecture MetricsMeasure total cost of ownershipMeasure performance Measure qualityCreate Balanced ScorecardReport management information

Set Architecture ObjectivesDevelop Architecture StrategyDefine Architecture Roadmap

Service DeliveryDeploy and operate applications and business solutionsAcquire and maintain technology & infrastructureDefine and manage service levelsManage third-party servicesManage performance and capacityEnsure continuous serviceEnsure systems securityIdentify and allocate service costsEducate and train usersAssist and advise usersManage changeManage the configurationManage problems and incidentsManage data storageManage physical facilities

Planning & Portfolio ManagementManage Application Portfolios, Programmes and ProjectsPerform Project AssessmentMake Architecture Decisions at Project Quality GatesDefine the IT organisation and relationshipsManage the IT investmentManage human resourcesAssess risksManage prioritiesManage qualityManage value

Enterprise Architecture(Current & Target)

Gap Analysis (Gaps)Identify Architecture Requirements (Topics)Reuse Existing ServicesDevelop New ServicesDecide on Integration StrategySelect, Acquire and maintain COTS ProductsDevelop and Maintain Services Develop Business SolutionManage application changes

Page 27: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Example: Aligned EA Processes

Page 28: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Example: Services provided by EA

Page 29: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Example: Change Portfolios

Page 30: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Example: EA ‘Funnel’ of changes and initiatives

Page 31: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Example: EA Governance for Solution Development

Inception Elaboration Construction Transition

Statement of Architecture Work

Project Initiated

Assess Architecture

Assess Architecture

Solution increment Released ?

Enterprise Architecture Development

PostImplementationReview

Architecture Contract Authorised

Architecture Contract Approved

Release Authorised

Iteration Assessed

ArchitectureContract Refined

Software Development

Enterprise Architecture Governance

Requests for Architecture Change, Request for Deviation from Architecture

Project Completed ?

Architecture Defined ?Feasible ?

Assess Architecture

Review Compliance

Update Architecture

Architecture Contract Defined

Architecture [Solution] Authorised

Impact Analysis,Gap Analysis

Project Closed

Decide on Architecture Request

Approve Architecture Contract

Ensure Architecture Compliance

Architecture Contract [Proposed]

Architecture Contract [Approved]

Acknowledgement Architecture Contract [Compliant]

Project Architecture [Solution]

Page 32: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

EA Challenges Prove the ROI for EA EA seen as an Ivory Tower Need for a Business Sponsor Communication about EA Lack of maturity in the organisation Need for process improvement No centralised budget for EA sponsored initiatives EA often has no formal authority EA often needs to be aware of thousands of application services/

applications etc. High expectations from stakeholders EA is often confused with IT Architecture Enterprise Architect is often expected to be a solution architect as

well

Page 33: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Gartner identified 10 Enterprise Architecture pitfalls http://www.gartner.com/it/page.jsp?id=1159617 1. The Wrong Lead Architect: Gartner identified the single biggest EA problem as a chief architect who is an ineffective leader. He or she

may understand EA well but has ineffective leadership skills that even a good organisational structure and staffing levels cannot overcome. Gartner recommends that such a lead architect be replaced by someone with strong ‘soft’ skills such as enthusiasm, communication and passion, as well as being well respected and strategically minded.

2. Insufficient Stakeholder Understanding and Support: This happens when employees outside the EA team don’t participate in the EA programme, EA content is not used in projects and management questions its value. Gartner’s solution is to make EA education and communication a top priority to secure executive-team sponsorship. “The key is to ‘sell’ first and architect later,” said Mr Bittler.

3. Not Engaging the Business People: When IT and business goals are not aligned, resultant problems include non-technical people trying to make technical decisions while enterprise architects become too reactionary and tactical in response to projects. To overcome this, Gartner recommends that enterprise architects get involved in the development of the business context and engage jointly with other employees in the business architecture.

4. Doing Only Technical Domain-Level Architecture: This dated EA approach is still in use in some organisations and is even narrower in scope than technical architecture. Holistic EA best-practice is much broader as it includes business, information and solutions architecture.

5. Doing Current-State EA First: Successful EA provides prescriptive guidance but current-state EA does not, so it delays delivery of EA value and hinders the creation of good future-state EA. “The temptation is often to do the easy – current-state – EA first,” said Mr Bittler. “Instead, establish the business context and then focus first on future-state EA.”

6. The EA Group Does Most of the Architecting: This is a pitfall because the EA content is typically off the mark as it was not informed by those on the business side. There is also consequently no buy-in for the EA. The primary job of architects is to lead the EA process rather than impose EA content on the organisation. They should form virtual teams to create content and seek consensus on the content.

7. Not Measuring and Not Communicating the Impact: The value of EA is often indirect, so it may not be obvious to everyone in the organisation. This then exposes the EA programme to risk of failure. Gartner recommends that enterprise architects create a slide to demonstrate each success story of EA applied to a project. They should include measurement and documentation of EA in the programme plan.

8. Architecting the ‘Boxes’ Only: Enabling better business agility and integration is key but architecting standards for the ‘boxes’ (business units) in process, information, technical and solutions models doesn’t address this. Integration and interoperability standards are high EA priorities and must account for more than just technical architecture. Architects should focus more on the links between the boxes.

9. Not Establishing Effective EA Governance Early: Enterprise architects must resist the temptation to wait for more architecture content before setting governance processes and instead develop content and governance in parallel.

10. Not Spending Enough Time on Communications: Key messages about EA are not intuitively obvious, so enterprise architects must work to educate the business. It is critical that organisations develop and execute an EA communications plan with messages tailored to each audience.

Page 34: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Page 35: A Day in the Life of an EA

Copyright © Adrian Campbell. All rights reserved.

Contact Adrian Campbell Enterprise Architecture consultant

blog: http://ingenia.wordpress.com/ web: http://iea.wikidot.com/ LinkedIn: http://www.linkedin.com/in/adrianrgcampbell

ArchiMate and TOGAF expert (TOGAF certified)

Member: Center for the Advancement of the Enterprise Architecture Profession, ArchiMate Forum