A day in the life of an
Enterprise Architect
Adrian Campbell – Enterprise Architecture
Consultant
Copyright © Adrian Campbell. All rights reserved.
V2
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 Architecture
A 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
Business
System
Thinker
Viewpoint
Business
Strategist Support
Facilitator
Visionary
Architecture Governance
Viewpoint Governance Viewpoint
Enterprise
Architecture Compliance
Architecture Quality
Development Assurance Design
Process Assurance
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 Planning & Portfolio Management
Set Architecture Objectives Manage Application Portfolios, Programmes and
Develop Architecture Strategy Projects
Define Architecture Roadmap Perform Project Assessment
Make Architecture Decisions at Project Quality
Gates Solution Development
Define the IT organisation and relationships
Governance Manage the IT investment
Manage human resources
Gap Analysis (Gaps)
Identify Architecture Requirements (Topics)
Assess risks Reuse Existing Services
Provide Architecture Direction Manage priorities Develop New Services
Communicate Architecture Manage quality Decide on Integration Strategy
Define Architecture Blueprints Manage value Select, Acquire and maintain COTS Products
Define Principles, Standards and Best Develop and Maintain Services
Practice Develop Business Solution
Define Architecture Reference Models
Define Target Enterprise Architecture Enterprise Architecture Manage application changes
(Current & Target)
Compliance Service Delivery
Perform Architecture Compliance Deploy and operate applications and business
Assessment solutions
Assess Architecture Compliance (for Acquire and maintain technology & infrastructure
Applications and Services) Define and manage service levels
Provide audit Manage third-party services
Monitor Applications and Services Manage performance and capacity
Monitor Quality Ensure continuous service
Monitor Security Ensure systems security
Identify and allocate service costs
Monitor the Enterprise Architecture
Update the Enterprise Architecture Performance Educate and train users
Assess the Architecture Maturity Level Assist and advise users
Collect Architecture Metrics Manage change
Measure total cost of ownership Manage the configuration
Measure performance Manage problems and incidents
Measure quality Manage data storage
Create Balanced Scorecard Manage physical facilities
Report management information
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
Enterprise Architecture Governance
Decide on Approve Architecture Ensure Architecture
Architecture Request Contract Compliance
Requests for Acknowledgement Architecture Architecture
Architecture Change, Contract Project Contract
Architecture Architecture
Request for Deviation [Approved] [Compliant]
Contract [Solution]
from Architecture
[Proposed]
Enterprise Architecture Development Architecture Solution increment Project
Feasible ? Defined ? Released ? Completed ?
Assess Assess Assess Review Update
Architecture Architecture Architecture Compliance Architecture
Impact Architecture Architecture Architecture Post
Analysis, Contract Contract [Solution] Implementation
Gap Analysis Authorised Approved Authorised Review
Statement of Architecture
Architecture Contract Architecture
Release
Defined Contract Iteration
Work Authorised
Refined Assessed
Software Development
Inception Elaboration Construction Transition
Project Project
Initiated Copyright © Adrian Campbell. All rights reserved. Closed
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
Copyright © Adrian Campbell. All rights reserved.
