CEB Enterprise Architecture Leadership Council

Reference Architecture
Implementation Guide

Please note that the CEB program names referenced in this document have changed since the time of publication.
 INFORMATION TECHNOLOGY PRACTICE |
ENTERPRISE ARCHITECTURE
EXECUTIVE COUNCIL CONTENT PUBLISHING SOLUTIONS
Executive Directors Senior Analyst Production Designer
Shvetank Shah Skand Bhargava Todd Burnett
Warren Thune Senior Associate Contributing Designers
Managing Director Abhishek Gupta Anita Ann Babu
www.executiveboard.com David Kingston Executive Advisors Supriya Dhasmana
Practice Manager Brent Cassell Nitra Jain
Bart Kaplan Christiane Groth Aron Editor
Senior Director Kuehnemann Karolina Makaira Casey
Chris Mixter Laskowska Bill Lee
Tim Macintyre
Project Managers
Dorota Pietruszewska
Shalini Das
Kristin Sherwood Alex
Audrey Mickahail
Stille

COPIES AND COPYRIGHT LEGAL CAVEAT

As always, members are welcome to an unlimited number of copies The Enterprise Architecture Executive Council has worked to ensure
of the materials contained within this handout. Furthermore, members the accuracy of the information it provides to its members. This
may copy any graphic herein for their own internal purpose. The report relies upon data obtained from many sources, however, and
Corporate Executive Board Company requests only that members the Enterprise Architecture Executive Council cannot guarantee the
retain the copyright mark on all pages produced. Please contact your accuracy of the information or its analysis in all cases. Furthermore,
Member Support Center at +1-866-913-8101 for any help we may the Enterprise Architecture Executive Council is not engaged in
provide. rendering legal, accounting, or other professional services. Its
The pages herein are the property of The Corporate Executive Board reports should not be construed as professional advice on any
Company. Beyond the membership, no copyrighted materials of The particular set of facts or circumstances. Members requiring such
Corporate Executive Board Company may be reproduced without services are advised to consult an appropriate professional. Neither
prior approval. The Corporate Executive Board Company nor its programs are
responsible for any claims or losses that may arise from a) any
errors or omissions in their reports, whether caused by the
Enterprise Architecture Executive Council or its sources, or b)
reliance upon any recommendation made by the Enterprise
Architecture Executive Council.

Please note that the CEB program names referenced

in this document have changed since the time of publication.
EAEC1919111SYN
EAEC1919111SYN-CEB
TABLE OF CONTENTS
INTRODUCTION • 1

Economic Model for an RA Program • 4

RA Lifecycle • 6

1. INITIATING A REFERENCE ARCHITECTURE PRACTICE • 7

Define RA Components • 10
Relate to Other EA Activities • 18
Quantify the Benefits • 20
Adopt a Program Management Approach • 22

2. BUILDING REFERENCE ARCHITECTURES • 25

Build Reference Implementations • 28

Treat RAs Like a Portfolio • 30
Federate RA Ownership • 31

3. DEPLOYING REFERENCE ARCHITECTURES • 33

Create Centralized, Collaborative Environments • 36

Overcome Resistance to RA Use • 40
Brand RAs for a Consistent Customer Experience • 42
Embed RAs in Developer Workflows • 47

4. GOVERNING REFERENCE ARCHITECTURES • 49

Fast-Track Governance • 52
Reduce Architecture Reviews • 53
“Lease” RAs • 55

5. MAINTAINING REFERENCE ARCHITECTURES • 57

Integrate RAs in Technology Roadmaps • 60

Use Event-Based Triggers • 61
Incorporate Project Feedback • 62

Please note that the CEB program names referenced

in this document have changed since the time of publication.
EAEC1919111SYN
EAEC1919111SYN-CEB
 iv

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Initiating a
Building Deploying Governing Maintaining
Reference
Introduction Reference Reference Reference Reference
Architecture
Architectures Architectures Architectures Architectures
Practice

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

1
 Reference Architecture 2

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Introduction

Enterprise Architecture (EA) groups recognize the potential benefits of reference architecture
(RA). Council polling results reveal that 72% of members consider an RA extremely or very
important to EA’s success—but few have been able to realize reference architecture’s full
potential. Fewer than 10% of EA groups rate themselves as mature in this area.
Leading EA groups manage reference architectures as a program by establishing the processes
to define, deliver, and manage them through their full lifecycle.
To help member organizations better manage their reference architectures, the Council has
collected artifacts from each stage of the lifecycle and highlighted the key takeaways:
1. Initiating: Ensure that all stakeholders define reference architecture consistently, promote
the associated benefits, and tailor stakeholder communications.
2. Building: Provide reference implementations that tangibly support solutions delivery teams
and develop an RA portfolio to ensure focus on high priority areas.
3. Deploying: Promote adoption by focusing on the customer experience, providing easy
access to resources and collaboration opportunities, and sharing ownership with subject
matter experts.
4. Governing: Fast-track governance for solutions teams using reference architectures and
lease RAs to ensure alignment with current standards.
5. Maintaining: Incorporate RAs into technology roadmaps and build in event-based triggers
to better anticipate and respond to change.
For more information, visit our Reference Architecture topic center on the Council website:
www.eaec.executiveboard.com.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

3
 Reference Architecture 4

A successfully run RA
program can deliver
Economic Model for an RA Implementation
annual savings equivalent
to 17% of the IT budget. Savings from a Single RA Compared to an RA Program1
Five Year Time-Horizon

■■ A single RA covering 5% of
the portfolio reduces the IT
0.4– 1.2–
budget by 2%. 1.9% 4.4%
100% 0.34–
0.15– 83–
1.8%
Maintenance cost ■■ Technology 5.4% 98%
■■
0.45–
procurement
■■ Prescriptive
reductions, which constitute ■■ Standardization 6.8%
patterns
approximately two-thirds of ■■ FTE costs for and reuse of infrastructure ■■ Reduction in
the savings, mount as the creation and
■■ Reduced number of
RA portfolio grows and the maintenance Standardization
solutions- trouble tickets ■■

practice matures. of infrastructure

delivery ■■ Reduced mean
time time to repair ■■ Reduction in
number of
■■ Standardization
trouble tickets
of supporting
infrastructure ■■ Reduced mean
time to repair
Pr dit l IT

m RA

m tio in

m tu in

en at in

en ct in

st itu IT
R e

en n

en re

an ion

an ure

-R re
op a s

st uc s

nt ic gs

nt u gs

Po nd ed
n ua

en

el lic g

ve tr ng
e- ur

op of
A

ts

ce

ce

A
ev p in

ai pl in

ai tr in

pe uc
pe nn

In ras avi
el t

D Ap Sav

M Ap av

M fras av
ev os

Ex ed
Ex A

In S

In S
D C

R
See EAEC’s Reference f
Architecture Cost Savings
Estimation Model to customize
to your organization. Efficient Solutions Delivery Simplified IT Operations

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
1 The cost savings ranges provided are based on the percentage of the project portfolio that uses
IT this
in PRACTICE
document have changed since the time of publication. a RA. We assume a minimum of 5% portfolio coverage and a maximum of 80%.
www.eaec.executiveboard.com
Source: American Express Company; Footloose, Inc. (pseudonym); CIO Executive Board Budget and Benchmarking Survey, 2011.
EAEC1919111SYN
EAEC1919111SYN-CEB
Economic Model for an RA Implementation (Continued)

Overall Assumptions
■■ A single RA implementation will cover 5% of the project portfolio in its first year of operation.
■■ A well-maintained RA program composed of multiple RAs will cover 80% of the IT portfolio after five years of operation and lead to the standardization of 70%
of the infrastructure and virtualization of approximately two-thirds of the servers.
■■ The use of an RA shortens solutions delivery time by at least 50%, reducing FTE costs incurred on development projects by approximately the same amount.

Specific Assumptions for a Single RA Implementation Specific Assumptions for an RA Program Implementation
■■ For the best ROI in application development, the first RA selected to ■■ Lessons learned from the first RA help streamline development of future
pilot the program is a technology used by at least 30% of the application RAs, lowering the cost of developing and maintaining subsequent RAs.
portfolio. ■■ With infrastructure standardization, project software costs decrease by 30%.
■■ Standardization of the infrastructure results in more effective vendor ■■ Project hardware costs are reduced by 50% due to commodity hardware,
negotiations, reducing project software costs by 5%. standardization, and virtualization.
■■ Standardization also allows projects to share hardware capacity, bringing ■■ Over a period of five years, the widespread adoption of RAs leads to a
down project hardware costs by 20%. 50% reduction in trouble tickets and an 80% reduction in mean time to
■■ The RA’s adoption by 10% of the platforms in the organization reduces the repair, which reduces FTE costs for application maintenance by 50% and
operating expenditure on hardware by 20%. infrastructure maintenance by 60%.
■■ Increased technology standardization results in a 30% reduction in problems
and a 20% reduction in the mean time to repair for those platforms using
the RA, lowering associated FTE costs for application and infrastructure
maintenance costs by about 40%.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Introduction 5
 Reference Architecture 6

RA Lifecycle

Initiate Build Deploy Govern Maintain

Partner with project Provide the

Establish oversight
Galvanize IT teams and developers communication,
mechanisms to monitor Ensure RAs are kept
stakeholders with a to select and develop education, and
the uptake and proper current and relevant.
formal RA initiative. the most useful support necessary for
use of RAs.
reference architectures. maximum adoption.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Initiating a
Building Deploying Governing Maintaining
Reference
Introduction Reference Reference Reference Reference
Architecture
Architectures Architectures Architectures Architectures
Practice

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

7
 Reference Architecture 8

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 1. Initiating a Reference Architecture Practice

EA groups looking to start an RA initiative struggle to build an effective business case

because they have trouble communicating what an RA is, the benefits it can bring, and the
investment necessary to manage the practice effectively.

To initiate a successful reference architecture practice, leading EA groups begin with

four steps:
A. Establish a common vocabulary to communicate effectively with stakeholders.
B. Relate reference architecture to other EA activities.
C. Quantify the benefits to make the case for investment.
D. Adopt a program management approach.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

9
 Reference Architecture 10

RAs are documented

best practices that help
1A. Define rA Components
solutions delivery teams
make effective design
and technology choices. Capability and Solution Business
Business and Project Design
Technology and Service Capability
IT Strategy and Delivery
Roadmaps Implementation Enablement
■■ The purpose of an RA
is increasing standards
adoption, speeding time Reference Architecture Toolkit
to market, and advancing
toward the target state Audience
architecture. To Govern and Ensure
Principles: Highest level Alignment with Strategy
■■ This toolkit includes all guidelines for governance
of the enterprise To Guide and Direct Solution
core deliverables needed to architecture
Design
successfully implement an Senior IT and
To Improve Solution Delivery
EA Leadership
RA.
Standards: Prescribed
Reference Models: or preferred technology,
A common design, data, and process
vocabulary and elements that conform to
taxonomy of architectural principles
accepted concepts
used to describe
an organization’s
capabilities Patterns: Prepackaged
Solutions and pretested design and
Architects technology combinations
and SMEs to build or modify a system

Decision Frameworks: Use

cases and decision trees
that recommend particular
patterns and standards

Solutions Implementation Guides: Working Prototypes: Practical Reusable Source Code:

Developers Detailed user manuals to instantiation of standards and Repository of code objects used
instruct solutions teams on patterns to provide a proof of by developers to accelerate
correct usage of standards and concept to solutions developers the building of frequently used
patterns functionality
Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com
Reference Adopt
EAEC1919111SYN
EAEC1919111SYN-CEB Purpose
 Principles are the
highest level of guidance
1A. RA Components: Principles
outlined for governance
of the overall enterprise
architecture.
1. Architecture will set the strategy for technology for three to five years into the future.

■■ They help retain consistency 2. Weighted consideration should be given to a vendor architecture that contributes to and strengthens
of the overall architecture, Johnson & Johnson EA.
while aligning IT 3. For IT investments, the project design process includes architectural review and design certification by an
implementations with the enterprise architect.
priorities of the organization.
4. A complete architecture includes the following five components: business process, information/data, applications,
integration, and infrastructure.

5. Global use will be a determining factor in design:

■■ Every application should be designed with the expectation to be global, scalable, and flexible.

■■ Applications must have a planned lifecycle and asset map.

■■ Architect applications as systems, and engineer them for supportability.

■■ The architecture frameworks for all components must be designed to support internal and external

customers and interfaces on a global level.

■■ Johnson & Johnson data standards will be established and globally used by all applications.

■■ Industry standards will be used wherever feasible.

6. Johnson & Johnson information is a valued asset and use must be designed and protected at the enterprise level,
not by a specific company or project.

7. Applications will be designed for the adoption of, not mapping to, data standards.

8. Data quality management and transparency will govern design to establish authoritative data sources and
ownership.

9. IT standards will be used; a nonstandard IT will require an exception waiver, and all required resources will be fully
funded by the owner.

10. Information Security services and solutions will be standards based.

11. Security decisions will be based on a risk management process: “a risk taken by one is a risk shared by all.”

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Initiating a Reference Architecture Practice 11

 Reference Architecture 12

A reference model is
a common vocabulary
1A. RA Components: Reference Model
and taxonomy of
unifying concepts Information Systems Reference Model
used to describe
an organization’s
capabilities. System Information Provider User

Network Layer
■■ Reference models are
MPLS Leased Line VPN (Internet) LAN/WAN
usually defined either at
the enterprise or BU level Channel Services Security Services
for a specific functional or Gateway Services User Interaction Services Access Management Directory Services
technology domain. Presentation Services
Service
File Gateway Service Internet Gateway Single Sign-On Identification Service
Service Composite User User Interface
Service
SFTP Interface Service Metadata Service
Identity and Access Entitlement Service
Management

Enterprise Service Bus Reporting Services Authorization Provisioning Service

Service
BI Report Delivery
Service Identity Management
Scheduling Service
Service
Report Management Service

Transformation Service Content Management Metadata Management

Service Service
Service Management Document Service Definition Service
Aggregation Service Repository Service

Information Services
Application Integration Information Integration
Service Service
Data
Extract-Transform-Load Warehouse
Routing Service Service
Business Process
Management
Process Definition Service Transactional Operational
Data Mart
Process Execution Service Database Data Store

Business Applications
Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
Chemicals Pharma Shared Group
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Standards are the
prescribed or preferred
1A. RA Components: Standards
technology, design, data,
and process elements List of Technology Standards
that help project teams Across 132 Products
conform to architectural
principles.

Server, Desktop, Network, and Edge Protection Application Security

SSL vPN—F5 L7 Firewall—F5 vulnerability Proxy—Bluecoat vulnerability Scanner—Cenzic Source Code Review—Fortify
Tool—Foundstone
L2 Firewall— NAC—Cisco ILP—vontu Av—McAfee Risk Assessment/ DB Compliance/
Juniper Management—RSAM Enforcement—Guardiam
Security
Authentication/Authorization Data Protection/Encryption Account Management
Active Directory CA ACF2 Oracle LDAP 6.x SecureFx voltage SecureData SecureCRT TIM 5.1
EMC RSA vintella vAS TAM 6.1 vshell 3.x Pointsec voltage Secure Tumbleweed TDI 7.0
Mail

Desktop Print Mobility Messaging Client Systems

End-User Computing Windows xP xerox Blackberry Exchange Microsoft Internet Microsoft Office Microsoft IM
Explorer

Portal/Web Content Collaboration BPM/Workflow/Process Management/Rules Engines

Management
Collaboration, vigenette Sharepoint FileNet BPM Blaze Guidewire
Presentation, and
Application Services Miscellaneous Application WebSphere
Servers Application Server
Jboss/Tomcat NET and II v6.1

Mainframe CICS Application Integration Application Messaging

Integration,
Messaging, and v4.1 AmberPoint (Service Bridje SOA IBM WebSphere MQ v6
Data Transport Gateway)

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Initiating a Reference Architecture Practice 13

 Reference Architecture 14

A pattern is a
prepackaged, pretested
1A. RA Components: Patterns
design and technology
combination that builds Types of Implementation Patterns Implementation Pattern Guide
or modifies a system. Illustrative Excerpt

Transaction Transaction Analytic Collaborative

■■ Patterns provide developers
Key Features Key Characteristics
with a suite of technologies E-Business Distribution
and tools certified for Logical overview of the Overview of the
implementation pattern pattern’s technology
compatibility and scalability
requirements
as well as architectural
compliance and alignment Recommended Use Technologies
to the most common Defines the information, Specifies technology
B2B Reporting Systems application, and infrastructure components that
development solutions.
characteristics suitable for make up each
this pattern, as well as the pattern at the release
deployment guidelines and level
other “how to” information

Digital Rights Document Management

Management
Transaction Pattern Components
Component Name Current Standard
Web Server IBM HTTP Server (HIS) 6.x
Application Server IBM WebSphere 6.x
Messaging Data Warehouse
Resource Tier (DB) Oracle 9i v.9.2.0.4
Connectors DB2 Connect v8.2, Teradata
JDBC 3.01, and IMS 2.1.0.4
Frameworks Ford Java Framework (FJF)

Enterprise Portals Business Intelligence Reporting Tool Oracle Reports 10g

Developer Tool Rational Application Developer
Enterprise System Tivoli Base Monitoring 5.1.2 and
Management Tivoli Web Monitoring 5.1.2
Scheduler Autosys 4.5
Collaborative Analytic

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication. Source: Infrastructure Executive Council research; Enterprise Architecture Executive Council research.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Decision frameworks
1A. RA Components: Decision Framework
1

are the use cases and

decision trees used to
recommend particular Architecture and Design Standards
patterns and standards. Excerpt

Core Standards Within the Use Case A1 Use Case Use Case A2 Use Case Use Case A3 Use Case Use Case C Use Case D
■■ They are used by project Component Component Groupings Simple Web B1 Complex Simple Web B2 Complex Simple Web B3 Complex Information Extended
teams to make design and Groupings Web Web Web Delivery Enterprise
App
implementation choices Sharepoint SAP .NET

given the options available Application SharePoint, 2010 .Net4.0, SharePoint SharePoint SAP SAP .Net4.0 .Net4.0 Bus SAP—Use
Platform SAP ECC v6.0, SAP 2010 (Out- 2010 Netweaver Netweaver Warehouse, Existing App
to them. Netweaver v7.0, Bus of-the-Box v7.0 (Out- v7.0 Bus Objects Functionality
Warehouse (BW), Bus Solution Set) of-the-Box v4.0 or
Objects v4.0, IIS v7.5 Solution Set) SharePoint
(Default), Apache v2.2.17x
(External)
Application .Netv4.0, visual Studio 2010, SharePoint SharePoint Web Dynpro Web Dynpro .Netv4.0, .Netv4.0, BW, BOBJ ABAP
Development SharePoint Designer 2010, Designer Designer visual Studio visual Studio BI v4.0,
ABAP, Web Dynpro 2010, 2010, visual 2010 2010 BOBJ Data
InfoPath Studio 2010, Services
2010 MS visio v3.2, Crystal
Reports 2011
Middleware SAP PI v7.1, .Net4.0 (xML N/A SAP PI v7.1, N/A SAP PI v7.1, N/A SAP PI v7.1 SAP PI v7.1, SAP PI v7.1
Web Services) xML Web xML Web .Net4.0
Services Services (xML Web
Services)
Database Oracle 11G, SQL2008 SQL2008 Oracle Oracle Oracle Oracle or Oracle Oracle or Oracle, DB2
SQL SQL
Operating Windows (64bit) xP SP2, Service Service Service Service Service Service Service Service
System Windows (32bit) xP SP3
(Client) Personal Computing Service
Operating Windows (64bit) 2008R2, Service Service Service Service Service Service Service Service
System Windows (32bit) 2008R2,
(Server) Redhat Linux AS/ES 5.x,
6.x Server and Storage
Server ExSServer 4.x (vMWare) Service Service Service Service Service Service Service Service
Virtualization Server and Storage
Physical Wintel x86/x64 Service Service Service Service Service Service Service Service
Servers
Storage v-Max SAN: Data Domain Service Service Service Service Service Service Service Service
(Block and vTL: Quantum Tape: TSM
File Level) Server and Storage
Network CISCO: DNS, Load Service Service Service Service Service Service Service Service
balancing, WAN Network
Services

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
1 Pseudonym.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Initiating a Reference Architecture Practice 15

 Reference Architecture 16

Implementation guides
are detailed user manuals
1A. RA Components: Implementation
to instruct developers Guides Chapter

1
on the correct usage of G U I D E T O T R A N S A C T I O N P A T T E R N 2 0 0 6

standards and patterns L A S T U P D A T E : M A R C H 31 , 2 0 0 5

when designing or Excerpt from Ford’s Guide to Transaction Pattern

implementing a solution.
Chapter

1
G U I D E T O T R A N S A C T I O N P A T T E R N 2 0 0 6

L A S T U P D A T E : M A R C H 31 , 2 0 0 5

What You Will Find in this Guide

• This Guide presents the overview of Transaction Pattern Strategy and more detailed
planning information, enabling high-level decision making regarding sizing, security
concerns, and architecture.
• References to application design and development documentation.
• Logical Overview of the Transaction Pattern
• Overview of the Transaction Pattern Infrastructure technology
What You Will Find in this Guide
What You Will Not Find in this Guide
• This Guide presents the overview of Transaction Pattern Strategy and more detailed
• planning
Overviewinformation, enabling
of the Architecture high-level decision
Management making
Initiative regarding
– please refer tosizing,
the security
concerns, and
Architecture architecture.Guidebook under the General Architecture Documentation
Management
• heading. to application design and development documentation.
References
•• Overview
Logical of Architecture
Overview Pattern concepts
of the Transaction Patternand strategy – please refer to the parent
document, Architecture Patterns under the Patterns heading.
• Overview of the Transaction Pattern Infrastructure technology
• Detailed application design guidelines, coding standards, and development best
practices. Please refer to the J2EE Center of Excellence website for this information.
What You Will Not Find in this Guide
• Overview of the Architecture Management Initiative – please refer to the
Architecture Management Guidebook under the General Architecture Documentation
Document
heading.
Roadmap
The• Guide to Transaction
Overview PatternPattern
of Architecture 2006 document is divided
concepts and into
strategy – three
pleasemajor sections:
refer to the parent
document,
SECTION Architecture Patterns under the Patterns heading.
I – Overview
Detailed
•SECTION IIapplication
– Pattern design guidelines,
Architecture coding standards, and development best
Details
practices. Please refer to the J2EE Center of Excellence website for this information.
SECTION III – Application Design and Development Guidelines
SECTION IV – Implementation & Operations
Each section introduces
Document Roadmapincreasingly detailed information for different target audiences. The
following table describes the intended audience for each major section of the Transaction
The Guide
Pattern to Transaction Pattern 2006 document is divided into three major sections:
document:
For more detail, please refer SECTION I – Overview
to Ford’s: Guide to Transaction SECTION II – Pattern Architecture Details
Pattern. Originator:SECTION III
Infrastructure – Application Design and Development Guidelines
Architecture/jbaxte23 Record Series: 25.01
Ford Motor Company Proprietary Page 2 of 57 Retention Period: S+5, O
SECTION IV – Implementation & Operations
Record Type: Official Printed Copies are Uncontrolled
Each section introduces increasingly detailed information for different target audiences. The
Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication. following table describes the intended audience for each major section of the Transaction
www.eaec.executiveboard.com Pattern document:

EAEC1919111SYN
EAEC1919111SYN-CEB

Originator: Infrastructure Architecture/jbaxte23 Record Series: 25.01

Ford Motor Company Proprietary Page 2 of 57 Retention Period: S+5, O
Record Type: Official Printed Copies are Uncontrolled
 Working prototypes are
practical instantiations
1A. RA Components: Working Prototype
of standards and patterns
that provide a proof of
concept of the solution. Proof of Concept Lab Production Environment

■■ Prototypes demonstrate to
1. Proof of 2. Feasibility 3. Operational
developers the usage and
Concept Scoping Testing Support Verification
benefits of a future system.

Objective ■■ Identify the critical learnings that ■■ Test the business value ■■ Evaluate the concept’s scalability.
would increase confidence in a and technical feasibility.
concept’s ability to meet business
needs.

Requirements ■■ Business area funding ■■ Concepts move forward based ■■ Subject to architecture scaling
on speed of implementation, exercise and performance testing
■■ Sign-off from business area lead
integration capabilities, and with fuller operational support
architect
technical feasibility ■■ Must pass both load testing and
■■ Alignment to known strategic
■■ Concepts evaluated for pressure testing
business need
enterprise-wide value ■■ Project team must report learnings
■■ Measurable success factors
to EA for cross-enterprise
knowledge sharing.

Duration ■■ 7 to 10 days ■■ 30 to 90 days ■■ 30 to 180 days

EA’s Role ■■ Business area lead architect ■■ Enterprise architects provide ■■ Board of architects is actively
scopes concept for risk and technology expertise during involved in progress tracking.
evaluates conformity to PoC testing and assess speed to ■■ Board conducts risk assessment
guidelines. implementation and integration
of technical support capabilities.
considerations.
■■ Enterprise architect with subject
matter expertise prioritizes test ■■ Enterprise architects assess
questions. results against key questions and
capture and share learnings.
■■ Board of architects provides input
on prioritized testing list.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Initiating a Reference Architecture Practice 17

 Reference Architecture 18

RAs are flexible and

adaptable tools that
1b. Relate to Other EA Activities
influence every EA
activity. Use of RAs in Core EA Activities

Architecture Governance IT Portfolio Planning

■■ RAs serve primarily as tools
to advance standards and Standard Setting EA Project Technology Roadmapping Technology
and Adherence Governance Portfolio Management and Planning Innovation
ease governance but also
Standards definition Project-level standards Documentation, Process for managing Assessment and
play an important role in IT and exception reviews compliance activities analysis, and retirement migration from introduction of emerging
portfolio planning and EA for applications, and stage-gate planning of applications, current to target state and new-to-organization
infrastructure, and architecture reviews infrastructure, data, and architecture technologies
functional management.
services links to business process

Service-Oriented
Architecture
Decomposition of
business functionality
into discrete,
interoperable services
EA Mandate and Use of RAs in EA Activity
Communication High
Awareness and support IT Strategic Planning
for EA’s mandate across Medium

Business Enablement
the organization Analysis of business
needs and translation to
Low IT action steps

None
Performance
Measurement Business Architecture
Metrics and practices
for measuring EA’s Linkage of strategic
value-added impact and objectives to business
support of business and operations and IT
IT performance initiatives

EA Artifacts and Tools Staff and Leadership Business Intelligence Data Governance Information
Development and Analytics Management Strategy
Selection, development, Recruitment, Collection, analysis, Planning, supervision, A longer-term plan to
and deployment of EA development, and presentation of and control of critical improve information
tools and artifacts management, and information for decision data assets management capabilities
retention of EA staff making

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com
EA Functional Management Information Management

EAEC1919111SYN
EAEC1919111SYN-CEB
 RAs connect up to
strategy through business
1b. Relate to Other EA Activities (CONTINUED)
architecture and down
to projects. A Cross-Stack View an RA

Vision and Objectives

BUSINESS
DRIVERS Business Strategy

Business Model

Business Capabilities
BUSINESS
ARCHITECTURE
Business Process

Information Architecture

DATA
Information Management Reference Architecture
ARCHITECTURE

APPLICATIONS
Applications Reference Architecture
ARCHITECTURE

INFRASTRUCTURE
Infrastructure Reference Architecture
ARCHITECTURE

Business Case/Initiation

Requirements
PROJECT-
LEVEL Design
ACTIVITIES
Develop/Test QA

Implementation/Support
Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com Source: Dols, Jeff, “Business Ownership of Business Architecture,”Cutter IT Journal, March 2008.

EAEC1919111SYN
EAEC1919111SYN-CEB

Initiating a Reference Architecture Practice 19

 Reference Architecture 20

Monitor implementation
1c. Quantify the benefits
1

metrics and track Footloose

improvements to system
maintenance, a significant
cost driver. Hardware Project Spend System Operations and Administration
Indexed to 100

Project 1 Project 3

100 Project 2 Project 4

Person Hours
31
17

Project 1 Project 2 Project 3 Project Months

Architecture and Design

Project 1

Project 2

Project 3a

Project 3b
Person Hours

Project 4

Project Months
Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com
1 Pseudonym.
EAEC1919111SYN
EAEC1919111SYN-CEB
 Share outcomes from the
program on an ongoing
1C. Quantify the Benefits (continued)
basis to demonstrate
progress over time.
Transformation program continues to drive improved time to market, quality, and reliability, resulting in lower costs
and fewer defects.

Standardization Self-Service
Standardization on track to meet or exceed our Marked increase in the proportion of standard
targets by year end server builds
Custom Linear (Standard)

100 Standard Linear (Custom)

80
2011 Goal
June 2011 60
January 2011
40
January 2011
20

Jan 2010
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Jan 2011
Feb
Mar
Apr
Virtualization Problem Management
Virtual Versus Physical Servers: All Environments Fewer problems and reduced resolution time
Over Time frames on standard server images
6x
6,000 1 Average Problems/Server Average Days to Closure
5x
5,000 1 Image Types: Windows, Image Types: Windows,
1 Linux, and AIX DB Rolling Linux, and AIX DB Rolling
4x
4,000 12 Months 12 Months
0
3x
3,000
0 2.24
2.05
2x
2,000
0
1x
1,000 0
00 0 0.77
1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 0.48
‘09 ‘09 ‘09 ‘09 ‘10 ‘10 ‘10 ‘10 ‘11 ‘11

Virtual Physical Percentage Virtual Standard Custom Standard Custom

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Initiating a Reference Architecture Practice 21

 Reference Architecture 22

RA configuration should
be considered holistically,
1D. Adopt a program management approach
including support
services that enhance RA Value Proposition
and promote delivery and
uptake.
1
Drive Business ■■ Time to market, standardization, lowest total cost of ownership
Time to Market Solutions ■■ Partnering with architecture governance (Architecture and
Delivery Team Information Uplift [AIU], project governance board)
Engagement ■■ Communications planning, customer focus, brand management

2
■■ RADF methods and business rule standardization—SDLC track
Brand ■■ Product naming, versioning, and lifecycle management
Total Cost Management processes
of Ownership ■■ Definition and characteristics of reference architectures

3
Develop ■■ RA product development plans and phase 1 project
and Drive requirements integration
Operational ■■ RA program planning, reporting, and scorecards
Quality of Delivery Plans ■■ Operational readiness and quality center

4
■■ Deliver new RAs and keep existing RAs current
Deliver RAs ■■ Quality, delivery, cost, performance, predictability
■■ Artifact definition and governance, KPIs, measures and metrics
Standardization

5
■■ RA standard and RA consultation
Drive Adoption ■■ Technologies roadmap and AIU roadmap
■■ Investment protection and lifecycle management

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 The program governance
structure ensures
1D. Adopt a program management approach
clear role definitions,
strategic alignment, and
(continued)
consistency across RAs.
RA Program Governance

Oversight: Governance: Program Office: Operations

Architecture and RA Board Practice Owner, RA
Engineering Board Owners, Constituents
and Service Delivery/
Operations

■■ Steering ■■ Early assessment, ■■ Quality of assets, ■■ Capacity

committee strategy, and timely delivery, planning and
for strategic roadmap consulting management
direction decision-making engagement, and ■■ Forecast
■■ Highest level body (brand practice/process ■■ SLA and KPI
decision and protection/ adherence (brand attainment
escalation point governance) management) ■■ Customer
Mandate to Approval of experience and
■■ Key approvals ■■ ■■

deliver RAs architecture and continuous

and evolution of
per approved design assets service
RA strategy
strategy and improvement
■■ Roadmap and ■■ First level
roadmap escalation point
practice
■■ RA and roadmap for both RA
change approval producers and
and second level consumers
escalation

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Initiating a Reference Architecture Practice 23

 Reference Architecture 24

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Initiating a
Building Deploying Governing Maintaining
Reference
Introduction Reference Reference Reference Reference
Architecture
Architectures Architectures Architectures Architectures
Practice

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Initiating a Reference Architecture Practice 25

 Reference Architecture 26

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 2. Building Reference Architectures

Due to EA groups’ inconsistent understanding of what goes into an RA, many EA groups
struggle to build effective RAs. Common failure paths include the following:
■■ EA creates an RA without first understanding what users would find valuable. More often
than not, these RAs fail to get adopted.
■■ If the initial RA pilot is successful, it often releases pent up demand in other parts of the
business. Limited EA resources can quickly become overwhelmed and reactionary.

Progressive EA groups address these challenges in three ways:

A. Build reference implementations, not just reference architectures.
B. Treat reference architectures like a portfolio, not a series of isolated decisions.
C. Federate reference architecture ownership to more effectively scale the effort.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

27
 Reference Architecture 28

Provide RA-driven
services that improve
2A. Build reference implementations
coding efficiency rather
than a governance Enable Collaborative Development Using RA
process that requires Elements of Infrastructure–Applications Performance Partnership
additional rework.

■■ Schlumberger offers the Requirements Detailed Code Testing Deployment

following services during Analysis Design Development and Q&A Support
design and development:
–– Proof-of-Concept
Evaluations: Helps
developers avoid
unforeseen performance Network 1. Proof-of-Concept 2. End-User Experience 3. B
 est Practice Other Services
issues early in design Performance Service Evaluations Demonstration Knowledge Notebook Offered
–– End-User Experience Description Performance Simulated transactions Living record of ■■ Quick
Demonstration: Illustrates predictions for key for select sites brought development best turnaround
how the intermediate transactions during to developer’s desks practices found to feedback
application design enhance application
builds will perform performance on the ■■ Application
–– Best Practice Knowledge network Performance
Profile
Notebook: Documents What They Do ■■ Applications ■■ Applications ■■ Applications
best practices for high- translates designs provides access to collaborates with
performing development into proof-of-concept intermediate build NAQP experts to
mock transactions ■■ Infrastructure improve performance
–– Quick Turnaround ■■ Infrastructure visits applications issues
Feedback: Provides provides diagnostic developers and plays ■■ Infrastructure updates
transaction analysis evaluations of WAN simulations a permanent record of
network impacts and of how their rules and guidelines,
within 48 hours predicts performance transactions will and shares with other
–– Application Performance for sites of interest perform project teams
Profile: Provides a Value Cultivates performance Imbues the applications Creates a body of
site-by-site view of aware design decisions development team with shared knowledge
performance on maturing and avoids known appreciation for the about how network
issues end-user experience characteristics should
application builds
impact development
decisions

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Reference
implementations make
2A. Build reference implementations
RAs consumable by
project teams.
(CONTINUED)
Network Application Qualification Process (NAQP) Lifecycle Overview
Elements of Infrastructure–Applications Performance Partnership

Requirements Detailed Code Testing Deployment

Analysis Design Development and Q&A Support

1. NAQP 2. Statement of Work 3. Proof of Concept 4. Network and 5. A

 pplication 6. NAQP
Request System Tests Performance Profile Approval
Overview Overview Overview Overview Overview Overview
Application Infrastructure designs Infrastructure Infrastructure Infrastructure provides The application
development high-level test plans prepares a mock-up performs multiple detailed application development
team submits for defined core proof of concept network and performance profile team seeks NAQP
NAQP transactions. (PoC) to test application profile reports with concrete approval prior to
initiation predictive application tests in a simulated improvement integration testing
Inputs
request and performance models. WAN setup. recommendations. and release.
Request for
coordinates
information (RFI) Inputs Inputs Inputs Inputs
with the
document from ■■ Key application ■■ Code for selected ■■ Predictive model ■■Application
infrastructure
application providing workflow scenarios transactions results profile report
group to
key transactions, ■■ Site-level real ■■ Simulation lab setup ■■ WAN simulation
understand Outputs
user profiles, and time network ■■ Select set of super results
process ■■ A green, yellow,
application type performance data users ■■ Aggregated set
requirements or red approval
information of code change
Outputs rating
Inputs recommendations
Outputs Outputs ■■ Accuracy maps ■■ Green indicates
■■ Request
Infrastructure’s Site-level transaction verifying predictive Outputs performance
for NAQP
■■ High-level
statement of work performance models with WAN Detailed packet, meeting
(SoW) including: predictions reveal simulation outputs network, and protocol standards
application ■■ Test plans and lab bottlenecks, and user perception analysis: ■■ Yellow indicates
description
setup, including: maps ■■ Transaction-level performance
Outputs ■■ Core workflow ■■ API-level code ■■ Targeted code performance profile warning
Infrastructure scenarios, issues, change suggestions, ■■ Post-deployment under certain
shares ■■ Key performance ■■ Network usability such as use of predictive analysis conditions
network metrics, and issues by site, and caching by site ■■ Red indicates

setup and ■■ Critical suggestions ■■ Technology ■■ High-level ■■ Post-deployment NAQP denial

performance for build versus buy standards infrastructure support and and further
criteria options. conflicts. investment reviews enhancement tests
recommendations
Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Building Reference Architectures 29

 Reference Architecture 30

Manage RAs as a
portfolio of assets to
2B. Treat RAs like a portfolio
maximize value to the
enterprise.
RA Asset Classes

■■ Pervasive RAs have the best

risk-return profile (relatively
easy to build and in high Capability Enabler
demand), and should,
therefore, dominate the
portfolio of an early-stage
RA program.
Emerging Strategic
■■ Over time, the portfolio can Consolidate technologies Define unique capabilities
be rebalanced to include and improve speed-to- for competitive advantage
other “asset classes,” market (e.g., mobile, cloud). (e.g., chip cards).
enabling RAs to provide a
wider set of benefits such
as speed to market and,
ultimately, competitive Specialized
High Volume
advantage.

Pervasive Best Practice

Drive cost savings Socialize project success
(e.g., development for common technologies
environments, utilities). (e.g., analytics, database).
“Once you have
developed reference
architectures for
cleaning house, you can more
confidently use them to execute
against higher order goals.” Efficiency Driver
David LaNoue
Director, Reference Architecture

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Federate ownership of
RAs to expand the scope
2C. Federate RA ownership
of the portfolio.

■■ RA owners benefit from

developing RAs by reducing
the complexity they must
manage.
Core RAs Federation Requires:
■■ EA benefits by investing ■■ Include two ■■ An RA Delivery Framework that outlines a development
in a scalable framework, primary RAs: Java, methodology and provides governance
building credibility and .NET ■■ A single delivery channel (i.e., IT Service Catalog)
buy-in through distributed ■■ Require 12–18
ownership. months for new Federated RAs
development ■■ Include 17 additional
■■ Consumers benefit from ■■ Cover the majority RAs (e.g., databases,
a broader array of RA of IT projects lower volume
resources, which provide ■■ Offer the most development
faster access to technology robust RA services environments, network/
Degree of “Professional RA Services”
and streamlined governance. telecom, etc.)
Consistency ■■ Are owned
■■ Require six to nine
■■ Include 37+ RA Services
by centers of
■■ RA owners are empowered excellence in EA months for new ■■ Require three months to
to define RAs that offer the development develop
greatest utility to consumers; ■■ Cover a smaller ■■ Support less commonly
some variation should be proportion of IT deployed technologies
tolerated based on the projects than core RAs (e.g., data warehouse)
needs of consumers as well ■■ Are a lighter ■■ Include templates and
as the demand volume for configuration than in implementation guidance
the RA (i.e., don’t over-invest core RAs without the full investment
in low-volume RAs). of an RA
■■ Are owned by COEs
and SMEs in IT ■■ Are owned by COEs and
and business units SMEs in IT and business
units

Breadth of Coverage

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Building Reference Architectures 31

 Reference Architecture 32

EA manages the RA
program, which includes
2C. Federate RA ownership (CONTINUED)
branding and delivery
through the IT service RA Ecosystem
catalog, but RA owners
manage the definition
and delivery of their RAs. 3. Build
RA Owner
RA Board
RA Owner
1. Propose
Subject Matter RA Program Management
RA Owner
Experts
Subject Matter 1. Manage RA portfolio
1.Experts
Subject
Propose Matter
RAs 2. Provide communication Producers
2.1.Experts
Make key technical
Propose RAs and branding
decisions.
2.1.Make
Propose technical
key RAs 3. Deliver the service
3. 2.
Manage lifecycle
decisions.
Make key technical catalog
3.through
Manage retirement
decisionslifecycle 4. Roadmap technology
3.through
Manageretirement
lifecycle lifecycle
through retirement
2. Approve

4. P
 roductize and Communicate

Consumers

Developer Business Unit Project Team

5. Fulfill Provides Feedback Provides Feedback Provides Feedback

■■ What problems arose in ■■ Does the delivered ■■ What was the net
“At the highest level, the development cycle? product satisfy the impact of using the
RAs are a delivery ■■ Were needed business requirements? standard on your
channel for global documentation or other project?
standards.” resources available to
David LaNoue you?
Director, Reference Architecture

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Initiating a
Building Deploying Governing Maintaining
Reference
Introduction Reference Reference Reference Reference
Architecture
Architectures Architectures Architectures Architectures
Practice

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Deploying Reference Architectures 33

 Reference Architecture 34

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 3. Deploying Reference Architectures

Despite significant investments by EA groups, RAs have not been widely adopted by solution
delivery teams, the primary consumers of RAs. Fifty-five percent of EA groups report that
fewer than one-half of solutions architectures in their organizations are based on their RAs.

Leading EA groups adopt four tactics to gain solution delivery team buy-in and participation.
A. Create centralized, collaborative environments where teams learn from each other.
B. Use organizational change management techniques to overcome resistance to RA use.
C. Brand RAs to ensure a consistent customer experience and extend the longevity of the
overall program.
D. Embed RAs in developer workflows to promote adoption.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

35
 Reference Architecture 36

Use robust, collaborative

environments to
3A. Create centralized, collaborative State Farm
Insurance
Companies
make behavioral and
management changes.
environments
Wikis for Work

Behavioral Shifts Management Practices Technology Enablers

■■ Require taxonomy tags but ■■ Start out with active moderation, ■■ Supply RSS feeds to provide
enable free definition of but expect to scale back over producers and consumers with
“folksonomy.” time. automatic alerts for new content.
■■ Encourage self-service by ■■ Provide classroom training ■■ Tie discussion pages to wiki
scaling back SLAs on service for beginners, intermediate entries for an integrated view.
desk response times. (contributors), and advanced ■■ Ensure that content could be
users (moderators) but
■■ Do not permit new content to reorganized easily.
transition to more just-in-time
be saved to the wiki without at
modalities over time.
■■ Make tagging extensible to
least one tag.
evolve with the lexicon.
■■ Ensure that resources
■■ Make content ownership and
are dedicated to ongoing
■■ Provide links directly to non-wiki
stewardship visible for all
maintenance, such as content where appropriate.
viewable content.
rationalizing user-generated
■■ Don’t let moderators or stewards tags (e.g., removing misspelled
do all the “talking.” Engage tags, combining single and plural
the community by creating a versions) and fixing broken links.
steward quiet period. Failure to do so will erode the
■■ Provide links for comments, quality and effectiveness of the
ratings, and feedback on every platform over time.
page and ensure that page ■■ Build confidence by ensuring
owners are set up to receive any that ultimate accountability lies
page changes immediately. with a senior leader.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Provide a collaborative
platform for solutions
3A. Create centralized, collaborative State Farm
Insurance
Companies
delivery and developer
teams to share
environments (Continued)
knowledge.

Use tree navigation In addition to static navigation on the left

■■ Providing social technologies to provide a site map and auto-generated word clouds on the right,
such as wikis and discussion for broad context. use widgets in the main panel to direct users
forums enables end-user to content and to reward desired behavior.
feedback loops and self-
service; 11% of State Farm
Systems Wiki users are also
contributors.
Enterprise Systems Wiki

Adapt the technologies Word clouds

■■
- Commercial Package Welcome show the
that staff use successfully Implementation Welcome to the enterprise systems wiki relative
at home to support greater + Transactional where you will find all the documentation importance
self-service at work. + Analytic
needed to answer your common questions. of content
+ Collaborative
The site owner is Daniel Lynn.
Java and enable
+ Custom Reference model navigation;
■■ While investment in
Development Top Rated Article “hover over”
moderation and site - Java
Development provides
maintenance is required By Melissa Smith metadata.
+ Training Integration
(State Farm devotes three By Satyajit Patel
+ Reference Model
Project plan
FTEs to run its systems wiki, + Reference Hot Discussion Topics
which has 11,000 users), that Implementation Bug fixes in SP1 of... 17 Responses BI RA
investment is more than + Legacy Which version sho... 2 Responses Reference
Implementation
offset by the knowledge Environments
What’s New Vizio
sharing the wiki engenders.
■■ State Farm Technical Architecture Updates
■■ Business Intelligence Reference
■■ Combine multiples types of
Implementation
navigation including search
and browse to suit common
use cases. Page owner: Al Jones
Last modified: December 17, 2011

Source: Enterprise Architecture Executive Council Research.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Deploying Reference Architectures 37

 Reference Architecture 38

Orient the resources

to key workflows and
3A. Create centralized, collaborative
demand patterns. environments (CONTINUED)

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Provide hubs for the most
commonly used RAs.
3A. Create centralized, collaborative
environments (Continued)

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Deploying Reference Architectures 39

 Reference Architecture 40

Build an evangelist
cohort by recruiting
3B. Overcome resistance to RA use
influential developers to
train as EA advocates and Development Process for EA Advocates
points of contact in the Illustrative
developer community.
Evangelist Candidate EA Evangelist: Developer
Knowledge Transfer
Selection Community Point of Contact

Candidate Profile Developer Knowledge Developer as EA Point of

Confirmation Contact
Illustrative

■■ Viewed as subject matter

expert Name: Jim Wont “How do I suggest a new
Business Unit: Finance standard?”
■■ Respected by peer developers
■■ Experienced in enterprise-wide BU Developer
Understanding of the value
application development
of enterprise solutions
■■ Familiar with industry “How can I take advantage
standards and best practices Knowledge of patterns of reuse opportunities?”
■■ Possesses a broad technical identification process
BU System Analyst
knowledge including some of Strong relationship with
the following: central EA
“Is there a template that could
–– J2EE, .NET, XPATH, SOAP, Knowledge of available help with this project?”
WSDL, object-oriented technology standards, tools,
concepts, agile development and templates BU Developer

Skills in use of technology

“Where can I find the pattern I
standards need?”

BU System Analyst

Enterprise
Please
IT this
in PRACTICE
Architecture
note that Executive
the CEB program Council
names referenced
document have changed since the time of publication.
Developer Evangelist
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Analyze stakeholders
to identify and plan
3b. Overcome Resistance to RA Use
for promoters of and
resisters to change.
(Continued)
Stakeholder Analysis

Stakeholder Role1 Explain Reactions to Change Reasons to Embrace or Resist Change

(Audience) Positive (P) and Negative (N) (Motivators and Concerns)
RA Customers: Target Positive: Motivators:
Business ■■ More product offerings ■■ Economic pressures forcing reduction
Solution ■■ Reduced time to market for in IT costs
Delivery (BSD)
environment provisioning ■■ Standardized RA products
Teams ■■ Greater flexibility contributing to decreased build time
■■ Reduced development, operational and decreased time to market
and maintenance costs with
standardization
■■ Guidance for standard development,
provisioning, and configuration
processes through RA Navigator
and IT service catalog (ITSC) service
overviews
■■ Better customer experience

Negative: Concerns:
■■ Loss of control over low-level ■■ Lack of ability to customize—must fit
architecture development and lack of within standards
ability to customize—must fit within ■■ RA product may not meet all design
standards needs.
■■ Reduction of PGB checkpoint, lower ■■ Knowledge on how to use RAs in
project risks/issues associated in solution development
project governance—need to validate ■■ Uncertainty—when to submit ITSC
request

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
1 Role in this change: The target is the person who has to change.
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Deploying Reference Architectures 41

 Reference Architecture 42

Execute a
communications plan
3C. Brand RAs for a consistent customer
that identifies the
medium, audience,
experience
and key message.
Drive RA Adoption
Communications
■■ For each RA release the
following:
Communicate, communicate, communicate, then communicate some more.
–– 1 employee news blurb
Channels
–– 1 help desk update
■■ RACI for end-to-end RA delivery
–– 1 or 2 announcement
messages ■■ SME knowledge from respective groups

–– 1 leaders briefing Stakeholders

–– 1 to 3 product guides ■■ RA Producers: architecture and engineering, governance, and systems engineering
–– 10 web pages (average) ■■ RA consumers/BSD teams including portfolio and project architects
–– 1 standard pricing sheet and technical contributor network

–– 2 training workshops ■■ BSD leaders

–– 1 presentation ■■ Architecture and engineering board members and reference architecture board members

–– 1 technology highlights Copy/Medium

blurb
■■ E-mail, web (intranet), conference calls, PowerPoint, person-to-person, online survey/feedback,
–– 1 “Bits and Bytes” customer focus groups, RA quarterly newsletter
–– 1 TechForum (technical
…and we will be doing more!
experts)
■■ More frequent outreach, road shows, leadership communications, and business and staff meetings

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Use guiding principles
for communicating to
3C. Brand RAs for a consistent customer
maintain consistency
and further reinforce
experience (Continued)
the brand.
Communications Guiding Principles
Purpose
■■ The communication plan describes the communication deliverables that build ownership for the change effort.
The overall purpose of the plan is to accomplish the following:
–– Educate project architects on new product features and enhancements to the ordering process.
–– Manage communications as the change effort itself.
–– Deliver the right message, from the right sender, to the right audience, through the right channel,
at the right time.
–– Monitor delivery results and adjust the plan as needed to achieve the behavioral objectives in each audience.

Effective Communications Principles Remain Constant

■■ Communicate what we know, when we know it.
■■ Keep messages clear and simple.
■■ Provide opportunities for as much personal contact as possible.
■■ Deliver the message by the most credible source for that particular message; prepare that person well.
■■ Sequence messages to audiences in logical order so that people who need to know first, hear first.
■■ Create a feedback loop.
■■ Be consistent: messages to different audiences may differ in emphasis and, to a degree, in tone, but they may not
differ in substance.
■■ Repeat important messages again and again.
■■ Develop a needs analysis for every communication.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Deploying Reference Architectures 43

 Reference Architecture 44

The ABCDE model

enables EA groups
3C. Brand RAs for a consistent customer
to anticipate and
develop a successful
experience (Continued)
communications plan.
Needs Analysis

Needs Analysis—Model based on Audience, Behavioral Objectives, Content, Design, Evaluation (ABCDE)

The needs analysis ABCDE Model is designed to help you think through the following:

■■ Audience you need to communicate with

■■ Behavioral objectives you want to achieve
■■ Content/key messages to include in your communication
■■ Design—the delivery channels you will use to communicate your message
■■ Evaluation of the effectiveness of your communication

Audience Behavioral Objectives

RA Customers/ ■■ Support continued understanding the role of using RA products in application development.
BSD Teams Use standard solutions—RAs and ITSC—for provisioning process.
including ■■ Order RA products through provisioning service in the IT service catalog.
Portfolio and
Project Architects
■■ Understand the new configuration request process, which offers greater flexibility.
■■ Follow American Express Development Center process for standard builds.
■■ Understand when to order environment in ITSC and when to submit a request for service (RFS).
■■ Know where to access RA Navigator for all product information

Architecture ■■ Coordinate development activities to launch coordinated products and services that enhance
and Engineering the customer experience.
Employees (RA ■■ Create education and training to ensure customers understand how to use products and tools.
Producers)
■■ Maintain awareness of “Voice of the Customer,” and develop an understanding of customer
needs within the application development process.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 The communications
plan identifies the owner,
3C. Brand RAs for a consistent customer
initial timing, and
follow-up frequency of
experience (Continued)
communications.
Excerpt from Communications Plan

Communication
Date Audience Channel Key Messages Responsibility Frequency
Pre-Launch Activities
5 Feb Architecture Monthly Board ■■ Provide update on RA launch Owner 1 Completed
and Engineering meeting
Board (Sponsor)
1 Mar RA Board Biweekly Board ■■ Provide update on RA launch Owner 2 Completed
(Governance) meeting

Launch—March 29
29 Mar ITSC (RA Web SS page is ■■ Present new RA product Owner 3 At launch
customers) live features
■■ Present new ordering services
29 Mar BSDs (RA Announcement ■■ Announce new release of RA Owner 4 At launch
customers) on RA Navigator products
Post Launch—April
Week of RA customers Provisioning and ■■ Introduce changes to the Owner 5 Once post-
5–9 April and agent configuration provisioning and configuration launch
training services
■■ Offer live demo of changes to
the ordering process
■■ Clarify how to submit a
configuration request.
9 April .Net RA Lunch-n-Learn ■■ Review .NET prescriptive Owner 6 Once post-
customers architecture v2.1 launch

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Deploying Reference Architectures 45

 Reference Architecture 46

Detail and document

the components of the
3C. Brand RAs for a consistent customer
RA program, including
information on the
experience (Continued)
respective stakeholders.
RA Brand and Configuration Management
Practice Dimensions

Development Methods
describe consistent
approaches for
developing content.

Development
Principles offer Methods
guideposts for
strategic and tactical Assets describe the
decision making. blueprint, templates,
Principles Assets and artifacts used in
They are a necessary
communication tool the environment.
to unite business
and technology
constituencies. Measures and
RA Delivery Metrics describe
Framework the quantitative and
Governance ensures qualitative goals to
proper, lightweight, yet Measures ensure that value
Governance
flexible review, approval, and Metrics is measured and
and controls. communicated.

Library details the Organization and

recommended tooling Skills describe the
and capabilities Organization structure, capabilities,
Library
to create, support, and Skills and skills needed to
collaborate, publish, build, maintain, and
and store content. implement the RA.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 EA maps patterns to
developer challenges
3D. Embed RAs in Developer Workflows
and automates developer
decision flows through an
intuitive self-service tool.
“Style-to-Stack” Mapping Developer “Style-to-Stack” Wizard

■■ Southwest Airlines integrates

architectural guidance
through its Style Wizard, Styles of Implementation Technology
The Style
Wizard enables
automating technology and Computing Patterns Stacks
Style Wizard
developers to
Step 1 - Select a Style of Computing
toolkit selection based on identify reliable,
N-Tier J2EE Choose the description that best fits your
the style of computing or Online J2EE Framework
requirements:
preapproved
Transactional N-Tier C++ solutions…
functionality that will deliver C++ Multithread Select Event Processing: The initiation of
EDI Transactions Framework system processes are depending on
the business solution. notification from another system. The
system generates events for systems
Event EDI Stack
Publish/Subscribe and processes events received from
Processing other systems.
■■ Through the Style Wizard, Point-to-Point Select
Style Indicators
EAI/Messaging Stack Online Transactional: The system
developers quickly Step 2 - Select an Implementation Pattern
needs to be interactive The a and wait
determine the appropriate Workflow Dedicated Workflow Task Management for aChoose
reply before they proceed
the description withbest fits your
that
Stack subsequent activities accessing the
requirements:
and approved set of tools to Embedded Workflow system simultaneously.
StyleSelect Publish/Subscribe:
Indicators
deliver the business solution, Open Workflow Content
Traditional Management Stack ■■ Processing initiated by an event
saving time and effort in the Project requires sharing of
Batch
■■

Batch Open Workflow information for core

Communication may be
requirements definition and
■■
Stack
ETL Data Movement broadcasted
Messaging
(system locateStack
one another)
solution design phases of Historical Job Scheduling Version 4.3 (Current)
Stack
the project lifecycle. Analytical Mining and Detailed Analytical
Example: Published Schedule Data
Component/ Vendor October November
store Element
(PSDS) Selection (v4.3)
Other OLAP Applications EDW/BI Stack

Near-Time Messaging OMS API 1.1 1.1

Decisioning System BUS/PUB/ TIBCO EMS 4.2.0 4.2.0
Decisioning Optimization SUB JMS Server
(DS) Stack
Style Wizard Monitoring and
Administration
TIBCO Hawk
TIBCO
4.2.0
5.0.1
4.2.0
5.0.1
Administrator
1. Developed by EA staff in E-Mail Microsoft 2003 2003
EA begins with the …and maps each computing
two weeks Notification Exchange
developer’s problem, “style” to a specific stack of Corporate Novell 8.7.3.6 8.7.3.6
2. Developers typically achieving the required standard sets of code and Directory a-Directory
functionality,… technical components.
consult the wizard in the
start-up and define phases. …and pattern-related
technology and toolkits
3. EA tracks usage to can be downloaded for
determine the trends in rapid implementation.

developer needs.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Deploying Reference Architectures 47

 Reference Architecture 48

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Initiating a
Building Deploying Governing Maintaining
Reference
Introduction Reference Reference Reference Reference
Architecture
Architectures Architectures Architectures Architectures
Practice

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

49
 Reference Architecture 50

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 4. Governing Reference Architectures

Developers and project teams often view centrally driven standards as limiting their ability
to meet solution objectives. Consequently, they frequently disregard standards and do what
they see as right for their projects. Many EA groups spend time and effort on governance to
find these non-compliant projects and drive them to the right standards.

Leading EA groups use RAs to move away from this heavy-handed approach, improve
compliance, and reduce governance costs.

When correctly managed, RAs can do the following:

A. Promote standards adoption.
B. Reduce the number of governance reviews.
C. Ensure adherence to the latest standards.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

51
 Reference Architecture 52

Projects that use RAs

save on governance
4A. Fast-Track Governance
efforts and related costs.
Project Lifecycle Stages

■■ Promote the governance

benefits to development
and project teams to further
encourage RA adoption. Start Up Define Design Build Test Deploy

Key Architecture Activities Key Architecture Activities Key Architecture Activities

■■ Identify project interdependencies. ■■ Ensure project design fulfills ■■ Document lessons learned.
business objectives and maintains
architectural integrity.
■■ Establish the appropriate level of ■■ Ensure existing solutions are used ■■ Update EA activities and planning
architecture oversight. effectively. to reflect project results.

Reduced Architectural Governance Effort for Projects Using Reference Architectures

Number of ARB Meetings Average Days Solution Architect Reviewing Standards
Project Rework Required
for Project Design Approval to Approve Project Oversight Person Hours Adherence in Project
After Compliance Review
During Design and Build Post-Mortem Reviews

3–5 1–2 20 Days 10 Days 100 40 Review All Review Only 100 30
Standards Exceptions
(Indexed to 100) (Indexed to 100)

Project Not Using RA

Project Using RA

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Embed governance in
4B. Reduce Architecture Reviews
1

the QA/test phase of

the SDLC rather than
instituting a formal
review to reduce overall
governance requirements.

App developers
SA maps
comply with
available RAs
RA patters and/
to detailed
or standards or
requirements and
seek exception
refines cost and
approval when
time estimates.
necessary.

Initiate Requirements Design Build Test/QA Deploy

Solutions SA and app

QA verifies use
architect (SA) developers
of approved
accounts roughly include RA
patterns and
for available RAs and applicable
standards and
in initial business components in
raises exception
case cost and overall solution
if non-compliant.
time estimates. design.

1 Pseudonym.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Governing Reference Architectures 53

 Reference Architecture 54

Analyze project requests

for exceptions to
4B. Reduce Architecture Reviews
architecture principles
based on a risk mitigation
(Continued)
and govern by exception
instead of reviewing all Architecture Waiver Risk Assessment
projects.
Risk Category Principle Waived Risk Description Impact/Cost to Risk Owner Mitigation Plan
Realign
Strategic Retain legacy Vendor Separate, one-off Bob Jones Risk owner
payroll system terminating implementation accepts
support required in responsibilities
Q3 2007 to plan
mitigation steps

Business Process

Operational

Customer

Project Delivery

Source: Enterprise Architecture Executive Council research.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Provide incentives
tailored to each stage
4C. “Lease” Ras
of an RA’s lifecycle
to induce the right
behaviors by consumers.

1. To maximize the useful

life of RAs, establish them
as “invest” technologies
within six to nine months
after product release
and prepare BSD teams
through technology Drive timely investment
Ensure that “divest”
lifecycle roadmaps so they in RAs by providing early
technologies are reclaimed 3. 1.
can plan to use RAs as visibility, faster provisioning,
by leasing—not selling— Divest Invest more dedicated support,
they become available. them to consumers.
and more favorable pricing.
2. Investment protection
ensures that BSDs will
not have to upgrade for
at least four quarters and
usually not for two and a
half to three years.
3. Structuring RAs as
12-month leases provides 2.
RA owners with a Maintain
mechanism to retire
unsupported technologies.

Provide “investment protection”

by guaranteeing a minimum
support timeframe for RAs.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Governing Reference Architectures 55

 Reference Architecture 56

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Initiating a
Building Deploying Governing Maintaining
Reference
Introduction Reference Reference Reference Reference
Architecture
Architectures Architectures Architectures Architectures
Practice

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

57
 Reference Architecture 58

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 5. Maintaining Reference Architectures

EA often invests heavily in building and deploying RAs but underinvests in their subsequent
upkeep. RA maintenance is challenging for two primary reasons.

First, EA does not have the resources required to maintain reference architectures and
struggles to get the necessary support. Second, updates are typically made
on a regular schedule and fail to take unplanned events into account.

Leading EA groups employ the following tactics to improve RA maintenance:

A. Integrate RAs into technology lifecycle roadmaps.
B. Define triggers to better anticipate unplanned events that could alter RA lifecycles, such
as an acquisition or change to a vendor roadmap.
C. Use project team feedback to improve quality and usability.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

59
 Reference Architecture 60

Including RAs in
roadmaps elevates their
5A. Integrate RAs in Technology
importance and visibility
to other stakeholders.
Roadmaps
Engineering Artifacts and Technologies Roadmap
■■ Point-in-time information is
contained in the engineering
models and repository once
roadmap line items are RA Product Offering Roadmap Technologies
Roadmap Tool
delivered.

Strategic
Outlook and
Planning Horizon Point-in-Time
Tactical Repository
Future Release
Influence

Artifact Provision
Models

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB
 Supplement basic
roadmap information
5B. Use Event-Based Triggers
with decision triggers to
keep roadmaps current. Illustrative

Customer Profile at the Teller

■■ Triggers describe economic, Roadmap Timeline
business, and IT events 2010 2011 2012
that require EA to revisit
Applications Project A (Introduce Application)
the roadmap and make
Middleware Project B (Introduce Project D (Upgrade Middleware)
adjustments.
Middleware)
Common EA
Servers Project E (Retire Server) Project F Roadmap
Hardware Project C (Retire Hardware) Information
and Telecom
Business Capability Common Tellers Cross-Sales Interactive Teller Solution
Technology Gap Customer Intelligence Customer Profile Predictive Modeling
at the Teller
Cost-to-Close Gap $5 M $3 M $10 M ($18 M Total)

Decisions and
Milestones

Projects Triggers Capabilities

Trigger Event Projects Affected Potential Impact Decision/Action Exemplar EA
1. Divest Business Line 1. Project A 1. Stop Project 1. Reassess and redefine Roadmap
needed capabilities. Information
2. New Product 2. Project C 2. Combine with 2. Search for alternative
Launch New Project technology vendors.

3. Large-Scale Retail 3. Project D 3. Delay Project 3. Specify or alter selected

Site Upgrade technology.

5. Project Tollgate 4. Project F 4. Go/No-Go 4. Delay or advance timing of

Review Decision technology introduction.

5. Consult architecture advisory

council.
6. Calibrate expectations with
end users.
Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB

Maintaining Reference Architectures 61

 Reference Architecture 62

At key decision points

in the project lifecycle,
5C. Incorporate Project Feedback
EA engages with project
teams to ensure that new Improving RA Using Project Feedback
solutions are aligned Project Steering Model
with, mapped to, and fed
into the RA. DP Decision Point

Steering DP DP DP DP DP DP DP DP

Project Project
Project Pre-Study
Planning Project Execution Phase Closing Evaluation
Management Phase
Phase Phase

IT Work
Model Requirements

Functional and Design and

Architectural Analysis Implementation

Testing

1
EA provides Deployment
starting kit
with link to Software
Engineering Software Configuration
reference 6 Update Central EA
Sub-Process Management
models. Repository with
maps to models.
2 3 4 5
Identify solution blocks, Approved solutions Analyze the Project teams provide
integration reference are mapped to the architecture feedback on reference
points, and approved reference model. according to the model inconsistencies
solutions. central template. and missing data.

Enterprise
Please Architecture
note that Executive
the CEB program Council
names referenced
IT this
in PRACTICE
document have changed since the time of publication.
www.eaec.executiveboard.com

EAEC1919111SYN
EAEC1919111SYN-CEB