Copyright © Adrian Campbell. All rights reserved.
A day in the life of an Enterprise Architect
Adrian Campbell – Enterprise Architecture Consultant
V2
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)
Copyright © Adrian Campbell. All rights reserved.
What is Enterprise Architecture?
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.
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.
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
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
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
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
Copyright © Adrian Campbell. All rights reserved.
Stakeholders
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
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
Copyright © Adrian Campbell. All rights reserved.
Activities of an EA Stakeholder management
Engaging Planning Meetings Messages Requirements Workshops
Copyright © Adrian Campbell. All rights reserved.
Activities of an EA Review Business Strategy
Goals Objectives Measures Business Operating model Business Policies Regulations
Copyright © Adrian Campbell. All rights reserved.
Activities of an EA Contribute to IT Strategy
Patterns IT policies Guidelines Product specific roadmaps and blueprints Standards
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
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
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
Copyright © Adrian Campbell. All rights reserved.
Activities of an EA Evaluations of:
Vendors or Suppliers Their product and service offerings
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
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
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)
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
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
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.
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
Copyright © Adrian Campbell. All rights reserved.
Example: Aligned EA Processes
Copyright © Adrian Campbell. All rights reserved.
Example: Services provided by EA
Copyright © Adrian Campbell. All rights reserved.
Example: Change Portfolios
Copyright © Adrian Campbell. All rights reserved.
Example: EA ‘Funnel’ of changes and initiatives
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]
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
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.
Copyright © Adrian Campbell. All rights reserved.
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