Enterprise

Architecture:
The Journey Begins Here, Part 1
Where You Are, Where You Are Going,
How To Get There.

an Enterprise Architecture eBook

Contents…
Enterprise Architecture: The Journey Begins Here, Part 1

Jeff Ryan is an enterprise architect with 25 years experience architecting and implementing
thoughtful solutions to business problems. He has served as an enterprise architect for a
large financial services organization and this eBook reflects his experience in this position.

Jeff has written 30 articles for Internet.com on a variety of enterprise architecture, front end
architecture, portal, Java, and XML topics. Enterprise Architecture: The Journey Begins Here
is his first eBook.

Jeff is a natural teacher and thrives on sharing his knowledge and experience. Each of his
articles and books challenges the reader to do something practical with the knowledge
gained and to make a positive difference in some small way.

Jeff owes a debt to his wife Lori and children, Megan, Matthew, Michael and Grace for
allowing him the opportunity to share his inner geek through his writing.

2 Enterprise Architecture: The Journey Begins Here

4 8
4 The 4C Architecture Blueprinting Process

8 Maturity Through Standards

11 Providing a Clear Point of Reference

11
 Enterprise Architecture: The Journey Begins Here, Part 1

Enterprise Architecture:
The Journey Begins Here By Jeff Ryan

W
here you are. Where you are going. How to Roadmap for the Journey
get there. The plan for the journey begins with An architecture blueprint is an important enterprise architec-
enterprise architecture. ture deliverable that creates a city plan of an organization’s
IT assets. Chapter 2, The 4C Architecture Blueprinting
It is no longer possible to run a large organization without Process, introduces a method for creating an architecture
significant investments in technology. Thoughtful investment blueprint. The 4C method collects information about the IT
of IT dollars requires the practice portfolio, classifies it into zones,
and discipline of enterprise archi- assesses each cluster of assets
tecture. and creates a transition plan for
their consolidation.
In order to assess where you are,
enterprise architecture begins Architecture standards define
with a current state baseline of which products, patterns, and
the IT asset portfolio. These as- practices are to be used in de-
sets must be assessed for how veloping or acquiring software
well they support the organiza- within an organization. In Chapter
tional mission. 3, Maturity through Standards,
you’ll look at how standards can
To define where you are going, accelerate application develop-
a future state target architecture ment and lower the total cost of
outlines the capabilities required ownership of IT assets. You will
to support strategic business examine a process for defining,
goals. A gap analysis identifies maturing and leveraging archi-
the shortfalls of the current state. tecture standards across the or-
ganization.
A roadmap and sequencing plan
determine how you will reach your Reference architecture captures
destination through a series of pre-defined architecture pat-
strategic and tactical initiatives to transition from the current terns, proven for use in a particular business context, together
state baseline to the future state target. Underlying principles, with supporting artifacts that enable their use. Reference ar-
standards, and reference architecture are needed to guide chitectures serve as guideposts in your enterprise architec-
the journey. Solution architecture applies these models to ture journey. Providing a Clear Point of Reference, will outline
projects that incrementally bring the vision to reality. Technol- a repeatable process for capturing and leveraging organiza-
ogy governance is necessary to ensure organizational assets tional knowledge through reference architecture.
are leveraged and projects stay on course.
Enterprise architecture defines the future state vision and
This eBook will introduce you to many of the required elements principles guiding the journey. In Part 2, Front End Archi-
of an enterprise architecture practice. If you are already an en- tecture: Where Business Meets IT, describes the future state
terprise architect, you will find much familiar material here and vision and principles that guide how business capabilities are
some ideas for furthering your practice. If you are new to the exposed to employees, customers, and partners through the
field, you will find many practical ways to get started. Web, mobile, voice, and Web services interaction media. This

2 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
 Enterprise Architecture: The Journey Begins Here, Part 1
chapter serves as a sample enterprise architecture deliver-
able that would be used to communicate an architecture vi-
sion, in this case for the front end, to a broad set of business
and IT stakeholders.
It takes projects to bring the future state into reality. The ar-
ticle 20 / 20 Vision Through Architecture Viewpoints, also in
Part 2, describes a proven method for documenting solution
architectures. Viewpoints provide a holistic view of a project
and eliminate blind spots. Additionally, they help to success-
fully identify and partner with the stakeholders required to
execute it. By capturing these viewpoints in a standard way,
it is easier for architecture review boards to assess whether
projects have a sound architecture, and also whether they are
following blueprints and leveraging standards, reference ar-
chitectures and services as expected.
As new technologies are brought in to advance the future
state, there will be proof of concepts, prototypes, pilots, and
3 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
architecture baseline activities led by enterprise architects.
Enabling Project Success Through an Architecture Baseline,
describes the architecture baseline activity, which creates a
partial implementation of the system that validates the candi-
date architecture and serves as a basis for subsequent devel-
opment.
Your Journey Begins, at the end of Part 2, provides final
thoughts and inspiration before you embark on your enterprise
architecture journey.
If the topic of one of the articles grabs you, dive right in. These
eBooks are designed so that you can read it straight through,
or jump straight to a topic where you will find practical advice
you can put right to use.
Your journey begins here.
 Enterprise Architecture: The Journey Begins Here, Part 1

The 4C Architecture
Blueprinting Process
S
trange Bedfellows: Enterprise Introduction to the 4C Architecture
Architecture and Urban Planning Blueprinting Process
City plans and zoning boards. Building codes Collect. Classify. Cluster. Consolidate. Repeat. These are
and inspectors. These concepts are quite the steps of the 4C architecture blueprinting process. Let
familiar in the field of urban planning. Do they really apply to me briefly review these steps before you examine them in
enterprise architecture? more detail.

Surprisingly, the answer is yes. The 4C architecture blueprinting process begins with col-
lecting information about an IT portfolio. This information is
An architecture blueprint is an important enterprise classified into relevant zones of IT assets. The cluster of as-
architecture deliverable that cre- sets in each city plan zone is as-
ates a city plan for an organiza- sessed and given a disposition.
tion’s IT assets. The blueprint An architecture transition plan is
enables the architecture team to developed to consolidate the as-
perform architecture governance. sets in each zone. This process
The governance function is akin is repeated at regular intervals
to a zoning board, which deter- to refresh the blueprint and to
mines whether development or ensure it remains relevant to the
purchase of new IT assets is in enterprise mission.
accordance with the blueprint.
Step 1: Collect
Likewise, reference architecture Step 1 of the 4C architecture
defines the building codes for blueprinting process begins by
new assets. When architects use collecting information about your
the reference architecture to as- organization’s current IT port-
sess IT assets, this is akin to the folio assets. This step provides
role of a building inspector. Ref- the raw inputs to be analyzed in
erence architecture is also used the “classify, cluster, and consoli-
in an architecture blueprint as a date” steps that follow.
lens to understand the current
state of the architecture portfolio The collect step gathers infor-
of assets and to map the archi- mation, in whatever format is
tecture transition to a higher quality, simpler, and lower-cost available, regarding all applications critical to your enterprise
future state. mission. The content for each application should include the
user community, functions performed, service level agree-
In this article, you’ll learn about a four-step process for creat- ments, transaction volumes, architecture, environments, plat-
ing an architecture blueprint or city plan. Following this pro- forms, resources, recurring costs, in flight projects, and so
cess will enable you to create an invaluable tool to guide your forth. This information can be gathered from existing archi-
enterprise in making thoughtful architecture decisions regard- tecture documentation, budgets, and interviews with key staff
ing its IT investments. members.

4 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
 Enterprise Architecture: The Journey Begins Here, Part 1
Step 2: Classify
In Step 2 of the 4C process, a scheme to classify an organiza-
tion’s assets is devised, and the assets are mapped into that
classification scheme.
Defining the Classification Scheme
The classification scheme defines the high-level city plan
zones relevant to your organization’s mission. This scheme, in
whole or in part, might come from accepted industry models
or leading vendors that focus upon your industry vertical.
A simple scheme I’ve found useful is the function/data/plat-
form classification. This scheme defines the high-level func-
tions, data, and platforms essential to an enterprise. Function-
al zones include the functions across the business value chain
such as account management, product management, and bill-
ing. Data include all of the major subject areas such as cus-
tomer and product. Platforms include all of the software and
infrastructure needed to run the business such as databases,
application servers, operating systems, and hardware.
How does it all tie together? Consider the example of a finan-
cial services firm. To run its business, it requires an account
management system (function) to maintain customer informa-
tion (data). The account management system requires an ap-
plication server and a relational database (platform).
Mapping Assets
Once a classification scheme has been devised, the organiza-
tion’s assets are mapped to the function, data, and platform
classification zones. This provides a useful picture of the or-
ganizations IT assets. This data may be collected in a spread-
sheet, or in an enterprise architecture tool.
Note that many assets will map to multiple zones. A good ex-
ample is a Customer Relationship Management (CRM) sys-
tem. The CRM maps to the account management functional
zone. Its database maps to the customer data zone. The sys-
tem-to-human workflow and integration capabilities inherent
in the CRM map to the business process and service bus
platform zones.
Step 3: Cluster
Step 3 of the 4C process examines the cluster of assets in
each classification zone in detail and determines the business
and technical adequacy of the assets. Coming out of Step 3,
each asset will be given a disposition of invest (green), hold
(yellow), or sunset (red).
5 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
Assessing Redundancy
Once assets have been mapped to zones, new insights into
the IT portfolio will be evident. You may discover that you have
three applications providing account management functional-
ity, that customer information is stored in five different places,
and that you have service bus functionality being provided in
four disparate places.
Because IT assets were created without a blueprint in the
past, you shouldn’t be surprised to find many redundant func-
tional, data, and platform assets.
In many cases, multiple assets within a zone can be quite ra-
tional. There may be clear guidelines for using the workflow
capabilities in a CRM versus an enterprise business process
management (BPM) tool. A division may require autonomy
because it may be sold and it doesn’t want its IT assets en-
tangled with those of the enterprise. A merger may have just
occurred and the driver behind the blueprint is to assess the
assets of the new combined enterprise.
In other cases, multiple assets within a zone can be quite ir-
rational. Lack of an enterprise architecture function may have
led to decisions in the past that may have made sense given
the myopic view of an individual project, but clearly not for the
enterprise as a whole.
In enterprise architecture, application rationalization is the pro-
cess used to simplify the assets within a zone. In mathemat-
ics, rationalization is about simplifying an expression so that
it still produces the same result. Application rationalization is
similar in that it tries to simplify the assets with a zone while
still providing the same business function and level of quality.
Assessing Adequacy
Each asset should be assessed for business and technical
adequacy. Adequacy can be assessed by interviewing busi-
ness and technical subject matter experts, through surveys,
service level agreement reports, and through mapping the as-
set to the relevant reference architecture or building codes.
Business adequacy should be measured by parameters such
as functions performed, cost effectiveness, and usability.
Technical adequacy can be measured by a quality attribute
assessment of how well an application is meeting its design
and runtime quality goals. Mapping an application to the rele-
vant reference architecture is useful in the assessment by pro-
viding a pictorial view of the assets in layers. Certain qualities,
such as maintainability, can be understood by the underlying
architecture, budgets, and timeliness of changes.
Continued on Page 7
 Enterprise Architecture: The Journey Begins Here, Part 1

Determining Asset Disposition City plan zones will need to be

The final part of clustering is determining the disposition of updated to reflect:
each asset in the cluster. The disposition of each asset will
be invest, hold, or sunset. The table below provides some • newly acquired assets
guidelines for how assets should be rated.
• updated business and technical adequacy
assessments of current assets

IT Asset Disposition Disposition guidelines

Invest • Strategic assets
(Green) • Investment warranted to improve business or technical adequacy
• Rationalization target

Hold • Adequate from a business and technical perspective

(Yellow) • Investment not warranted at this time

Sunset • Non strategic assets

(Red) • Asset dependent upon end-of-life platforms
• Inadequate from a business or technical perspective and investment not warranted
• Application to be rationalized due to redundancy

Table 1: IT Asset Disposition Guidelines

Step 4: Consolidate • updated architectural diagrams reflecting the changes

Step 4 of the 4C architecture blueprinting process determines
the consolidation approach for each cluster through an archi-
tecture transition plan.
Architecture Transition Plan
The architecture transition plan uses the reference architec-
ture or building codes to determine the current state of the
zone, the rationalized future state, and the series of steps re-
quired realize the future state. Multiple options might be out-
lined to replace assets marked for sunset.
The benefits of transitioning the architecture can easily be ar-
ticulated due to the business and technical adequacy assess-
ments done previously. However, execution of the architecture
transition will be dependent upon investment in rationalization
projects or through funded business initiatives.
Step 5: Repeat
The city plan zones will stay stagnant in many enterprises.
However, the assets within them will vary. The blueprint must
be refreshed on a regular basis to remain relevant.
to assets by the execution of architecture transition plans
• retired assets
Putting the Architecture Blueprint to Work
An architecture blueprint is an invaluable tool to guide an en-
terprise in making its IT investments. The blueprint, like any
tool, does no good sitting in the toolbox. It needs to be taken
out and used regularly.
If there were a 5th C in the blueprinting process, it would be
communicate. The facts learned and the insights gained from
the blueprint will be of interest to key business and IT stake-
holders. The blueprint will help guide the enterprise in making
fact-based decisions about its future.
If there were a 6th C, it would be commitment. Once under-
stood, the blueprint should be committed to by business and
IT stakeholders to use it as a guide and to keep it up to date.
The thought put into the disposition of assets and architecture
transition plans will make decisions easier going forward.
The architecture governance board will perform its zoning
function using the blueprint or city plan to guide the evolu-

6 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
 Enterprise Architecture: The Journey Begins Here, Part 1
tion of the IT portfolio toward a higher quality, simpler, and
lower-cost future state. Proposed investments that are not in
alignment with the blueprint will have a difficult time get-
ting governance approval to proceed; for example, invest-
ments in assets marked for sunset. Investments in alignment
with the blueprint and architecture transition plans will be
accelerated.
An architecture blueprint is a deliverable that helps crystal-
lize the IT strategy. Investing the time and effort to create one
helps an IT organization to better serve the business that
is always looking for ways to improve quality, agility, and to
reduce costs. The blueprint helps IT to be a better steward
of the organization’s IT assets. With the architecture blue-
print in hand, IT is well prepared to be a trusted partner when
business strategy efforts begin.
Summary
You discovered that an architecture team can learn a lot from
urban planning. An architecture blueprint is essentially a
city plan of an organization’s IT assets. Reference architec-
ture represents building codes for new assets. Architecture
7 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
governance performs a zoning function to guide its overall city
planning responsibility and to ensure newly developed assets
are created in accordance with defined building codes.
The 4C process for creating an architecture blueprint collects
information about the IT portfolio, classifies it into relevant
zones of assets, examines the cluster of assets in each zone,
and develops an architecture transition plan to consolidate the
assets in each zone. This process is regularly repeated so that
the blueprint will continue to be relevant.
Does your architecture team have an architecture blueprint
to enable it to guide the evolution of the IT portfolio over
time? Does it have a governance board to perform its city
planning responsibility? Are relevant building codes for
new assets defined through reference architecture? If not,
consider creating an architecture blueprint using the 4C
process as your guide.
References
1. The term 4C was coined by my colleague and friend, Mike Stevens, who
is known for his books on Enterprise Architecture and SOA. Mike and I
co-developed the 4C blueprinting methodology and employed it at a major
financial services company.
 Enterprise Architecture: The Journey Begins Here, Part 1

Maturity Through
Standards
D
o architecture standards curtail the creativity plication, or business intelligence system. Boundaries may
of a developer or architect? Or rather, do stan- even include the practices used to build software such as
dards channel creativity into solving business an architecture baseline, as defined in the Rational Unified
problems? Process, or extreme programming.

Architecture standards define which products, patterns, and Because of these boundaries, the developer and applica-
practices are to be used in developing or acquiring software tion architect may feel that their creativity is being curtailed.
within an organization. In this article, you’ll look at how stan- What are the benefits of standards? Through the boundaries
dards can accelerate application development and lower they define, already solved problems are not revisited. Cre-
the total cost of ownership of IT ativity is not curtailed, but rather,
assets. channeled into solving business
problems.
Although having defined standards
is an indicator of maturity in an IT Project delivery can be acceler-
organization, having poorly defined ated through architecture stan-
standards may not be better than dards. For example, a product
not having any standards at all due selection thoughtfully done will
to the risks projects will incur by serve the needs of multiple proj-
using them. In this article you will ects, eliminating the need for
examine the characteristics of ma- subsequent teams to spend the
ture and well-defined standards upfront effort. Codifying stan-
and a classification scheme for dard practices within an orga-
recognizing them. nization results in working soft-
ware being delivered faster and
Architecture standards are sub- cheaper through tried and true
ject to change over time. I’ll con- repeatable processes.
clude this article by looking at a
thoughtful architecture standards By defining product standards,
process to define, catalogue, an organization can have fewer,
communicate, mature, and gov- deeper relationships with key
ern standards relevant to your product vendors or open source
organization. providers. This can result in more advantageous pricing
and/or support. Also, selected products are more fully lev-
The Benefits of Standards eraged, and internal expertise with using them is cultivated.
Architecture standards define certain boundaries. These This will ultimately result in IT assets that can be managed
boundaries may be what open source or vendor products are and maintained over time with a lower total cost of ownership,
to be used in software development. Some examples include or TCO.
the application server, portal framework, AJAX toolkit, content
continued
management system, database, or service bus that is man- Maturity Characteristics
dated or recommended in your organization. Other boundar- Not all standards are alike and will realize the promise of
ies may be the architecture patterns and solutions applicable accelerating delivery and lowering total cost of ownership.
to certain types of business problems such as a business to Please examine some characteristics of mature architecture
business (B2B) gateway, multi-user transactional n-tier ap- standards.

8 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
 Enterprise Architecture: The Journey Begins Here, Part 1

Subject matter expert (SME) recognition and approval: mentations exist. Production implementations are a true test
The first characteristic to consider in assessing standard ma- in assessing standard maturity.
turity is whether the proposed standard has passed the initial
approval of a subject matter expert in the relevant architecture Absence of one of these standard maturity characteristics
domain. Often, a proof of concept or product evaluation will puts a project using that product, pattern, or practice at risk:
be undertaken to prove the use of a product or approach to
meet a particular set of functional and non-functional require- • without the thorough evaluation of an SME, a standard
ments. De facto standards, on the other hand, can be harvest- may not support its intended use and may overlap
ed from existing production implementations. In either case, a unnecessarily with other standards, creating confusion
subject matter expert first must pass judgment on a proposed • without a reference model and implementation, a
standard and its wider use in an organization. Sometimes out- standard may not be used properly and may result in
side help may be enlisted in making this judgment. increased development time and cost
Reference Models and • without a clearly defined
Implementations: A prod- support model and organiza-
uct, pattern, or practice that tion to support it, gaps and
is documented through a ref- overlaps in roles and respon-
erence model is more likely sibilities may result;
to be used successfully to
solve a particular business • without planning aids, the
problem. A reference imple- benefits of past learning will
mentation increases the not be fully leveraged
chances further because it • and finally, without pro-
is a concrete example of the duction implementations, a
model to be followed. Refer- standard has not been prov-
ence models and implemen- en throughout the entire soft-
tations that are readily ac- ware development lifecycle.
cessible to the architecture Architecture Standards Clas-
and development community sification
provide a kick start to devel-
opment efforts. It is helpful to classify stan-
dards according to their
Support Model: A support maturity characteristics. The
model must be defined and Standards Maturity Pyramid,
put in place for a standard depicted in Figure 1, places
product, pattern, or practice. the least mature standards at
This often includes the devel- Figure 1: Standards Maturity Pyramid the bottom, and the most ma-
opment, testing, and produc- ture at the very top.
tion environments needed to
leverage it successfully. The roles and responsibilities of the A submission represents a product, pattern, or practice be-
application development teams and support personnel must ing considered for a standard. A candidate has passed the
be clearly defined across all environments. A standard with scrutiny of subject matter experts. A recommendation has a
a fully defined and operational support model is most likely a reference model and implementation in place. A practice has
very mature standard. a defined support model and at least one production imple-
mentation. A best practice has multiple production implemen-
Planning Aids: Planning aids help projects using a particular tations and a refined support model.
product, pattern, or practice prepare the environment, engage
support, and accurately estimate the work effort involved by The architecture standards classification scheme provides an
all partners, ensuring successes can be repeated and failures objective way to recognize and mature standards. It prevents
avoided. standards being set by politics, favoritism, or the influence of
vendors on business partners and executives.
Production Implementations: A project team would much Continued on Page 12
rather use a standard where one or more production imple- This classification loosely follows the W3C (World Wide

9 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
 Enterprise Architecture: The Journey Begins Here, Part 1

Web Consortium) standards classification, with the addition and developers to utilize these standards, and of the architec-
of practice and best practice for those organizational archi- ture governance board to ensure their use.
tecture standards which are the most mature. Note that, over
time, some best practices may be supplanted by newer can- This process for organizational architecture standards
didate standards being matured. ensures that standards are thoughtfully considered, and that
the benefits promised are ultimately achieved.
An Organizational Standards Process
A process for recognizing, developing, cataloguing, and com- Summary
municating architecture standards within an organization is In this article, you saw how architecture standards define the
needed to realize the benefits of standards. This process en- products, patterns, and practices to be used in developing
sures that standards or acquiring software
are relevant, that they in an organization. You
are defined with integ- also learned about the
rity, and that they are many benefits stan-
communicated well to dards provide, mainly
all stakeholders. accelerating delivery
and lowering the total
Figure 2, “How a Bill cost of ownership.
Becomes a Law,” il-
lustrates a process for All standards are not
defining architecture alike. Characteristics
standards that bor- of maturity include
rows from the W3C subject matter expert
process. approval, reference
models and imple-
The architecture stan- mentations, a support
dards process begins model, production
with a submission rep- implementations and
resenting a product, the time the product,
pattern, or practice to pattern, or practice
be considered for a has been used. These
standard. This submis- characteristics can be
Figure 2: How a Bill becomes Law
sion is first reviewed used to classify a stan-
by a subject matter ex- dard as a candidate, rec-
pert, and then by a Standards Committee that will determine ommendation, practice, and best practice.
whether this submission warrants further work. The main cri-
terion in evaluating a submission is relevance across multiple Finally, you reviewed a process, similar to the W3C standards
projects, and intersection with previously defined standards. process, that you might use in an organizational setting, to
recognize, define, catalog, and mature standards to realize
The Standards Committee may decide to charter a Working the benefits of accelerated delivery and lower total cost of
Group to mature the submission. The Working Group Char- ownership.
ter might include vendor or open source product evaluations;
creating reference guides, models, and implementations; Does your organization have defined architecture standards?
determining the support model; reviewing production Are they classified by their maturity? Is there a process
implementations; engaging outside help; and so forth. for recognizing, defining, communicating, and maturing
standards? Do you have examples of how defined stan-
The Working Group presents its deliverables to the dards have accelerated delivery and lowered total cost of
Standards Committee. When approved, the standard ownership? If not, consider putting into practice some of the
maturity is assessed (Candidate, Recommendation, Practice, concepts discussed in this chapter.
Best Practice) and added to the catalog of standards to be
leveraged throughout the organization. It is the responsibility Chapter References
1. W3C, World Wide Web Consortium Process Document, July 19, 2001
of the Standards Committee to communicate standards to all
stakeholders. It is then the responsibility of solution architects

10 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
 Enterprise Architecture: The Journey Begins Here, Part 1

Providing a Clear Point

of Reference
I
s reference architecture an ivory tower activ-
ity with little relevance to software development
projects? Or is it rather like a compass that
keeps projects on track and pointing toward their
destination?
solves a particular recurring problem. It is “pre-defined” so
that it can be used again the next time a project encounters a
similar problem. The solution patterns that may be captured
in a reference architecture includes the architecture patterns
to build:

To answer these questions, you’ll first ground yourself with • an n-tier transactional application for thousands of concur-
an industry accepted definition of reference architecture and rent users
understand how reference archi- • a business intelligence ap-
tecture builds upon architecture plication for a large data ware-
standards. Then, you’ll review the house
types of reference architecture • a business to business
artifacts used by different proj- transaction gateway which ex-
ect stakeholders. Finally, you’ll poses services to external part-
observe how reference architec- ners
ture is closely related to knowl- • a Web content manage-
edge management and outline a ment system which allows busi-
repeatable process for captur- ness users to publish content to
ing and leveraging organizational a business to consumer portal.
knowledge through reference ar-
chitecture. Proven for Use in a
Particular Business
Through this overview, you’ll find
that reference architecture pro- Context
vides a clear point of reference A reference architecture is not
for projects and that it helps them just “a” solution. It is a solution
improve quality, accelerate de- that has been “proven for use” to
livery, and lower the total cost of solve a particular business prob-
ownership of the IT assets being lem. It is important to remember
developed over time. that architecture patterns are not
invented, but rather recognized.
Together with Supporting Artifacts to Enable Its Use
Reference Architecture Defined For a reference architecture to be leveraged, artifacts that ex-
You should begin with an industry accepted definition of ref- plain what it is, when to use it, and how to use it, are essential.
erence architecture. The Rational Unified Process defines These artifacts must be tailored to the needs of the consum-
reference architecture as a pre-defined architecture pattern, ers of the reference architecture that include architects, de-
proven for use in a particular business context, together with velopers, and project managers.
supporting artifacts to enable its use. Often, these artifacts continued
are harvested from previous projects. A closer examination of
this definition is helpful. These Artifacts are Often Harvested
from Previous Projects
Pre-defined Architecture Pattern Because a reference architecture is proven for use before be-
A reference architecture captures a solution architecture that ing promoted, it is often harvested from a previous project’s
success.

11 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
 Enterprise Architecture: The Journey Begins Here, Part 1
Reference Architecture and Standards
In the previous article on architecture standards, I discussed
the benefits of architecture standards that define the prod-
ucts, patterns, or practices to be used in developing or ac-
quiring software in an organization. You may be wondering,
“What is the difference between architecture standards and
reference architecture?”
Whereas standards identify enterprise “building blocks,” in-
cluding vendor and open source products, reference archi-
tecture explains how the “building blocks” are constructed to
solve a particular business problem. For example, the refer-
ence architecture for publishing content to a consumer portal
would show how the organization’s standard content man-
agement product, portal framework, and security standards
would be used to solve this set of functional and non-function-
al business requirements.
Reference Architecture Artifacts
A reference architecture may have several artifacts to docu-
ment what it is, when to use it, and how to use it. These arti-
ArtiFACT Purpose
Reference Guide “what to build”
Reference Models “how to build it”
Reference “working code”
Implementations
Factory Setup Guide “who does what”
Planning Aids “plan the work”
Table 1: Reference Architecture Artifacts
facts include the Reference Guide, Reference Models, Ref-
erence Implementations, Factory Setup Guide, and Project
Planning Aids. You will examine each type of artifact, its pur-
pose, and audience.
12 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
Reference Guide
A reference guide provides an overview of a problem space
and a guide to proven solutions. The problem is described by
a particular set of functional and non-functional requirements.
The solutions may be described by a conceptual diagram of
how to architect a solution to meet those requirements. The
solution also might leverage a set of organizational architec-
ture standards. The reference guide may contain a set of so-
lutions and the criteria to choose among them. The primary
user of a reference guide is an architect. A reference guide is
not the only artifact used to describe a reference architecture.
However, it is probably the most important because it broadly
defines the problem and proven solutions.
Reference Models
Whereas the reference guide will tell you “what to build” giv-
en a set of requirements, reference models describe “how to
build” the solution. A reference guide may provide context for
multiple reference models.
In Part 2, the article Achieving 20/20 Vision with Architecture
description auDience
Describes solutions which address sets of Architect
functional and non functional requirements.
Specifies how to build a given solution chosen in Architect,
the reference guide Developer
Working code that has been refined, tested and Developer,
validated and can be leveraged on a project. Architect
Outlines the development and production envi- Project Manager,
ronments. Roles and responsibilities are clearly Configuration
understood through the software development Manager
life cycle.
Provides templates for building a project using Project Manager
a particular reference architecture and includes
resource needs, timelines, training, estimating
guides, etc.
Viewpoints, will discuss seven architecture viewpoints that
may be used to articulate a solution. A reference model may
use a number of viewpoints such as use cases, domain mod-
 Enterprise Architecture: The Journey Begins Here, Part 1
els, conceptual diagrams, sequence diagrams, or deployment
diagrams to describe the solution. A reference model is a de-
sign asset that may be used on subsequent projects by archi-
tects and developers.
Reference Implementations
Reference models are much more valuable if they document
proven reference implementations. Reference implementa-
tions are actual working code examples of the solution. A ref-
erence implementation provides code assets that developers
may leverage on subsequent projects.
Factory Setup Guide
People, processes, tools, and environments are needed to
implement a solution. The factory setup guide artifact de-
scribes what is needed to develop and deliver a solution using
the reference architecture. The factory setup describes the
development, testing, staging, and production environments;
how code is migrated through environments, the roles and
responsibilities of development and support personnel; and
so on. The primary users of the factory setup guide are the
project manager and architect.
Project Planning Aids
Project planning aids are a key reference architecture artifact
because they assist project managers with successfully uti-
lizing a reference architecture. Planning aids might include
project templates, resource allocation guides, estimating tem-
plates, staff training recommendations, and so forth.
Reference Architecture Artifacts
Table 1 summarizes the reference architecture artifacts
discussed above. Collectively, these artifacts create a meta
model for documenting a reference architecture.
Artifacts by Problem Domain
A set of reference architecture artifacts may be used to docu-
ment the reference architecture of a particular problem domain;
for example, an n-tier transactional application architecture.
Note that a domain’s reference architecture need not include
all of the artifacts mentioned here. A reference guide is gen-
erally the best place to begin. Over time, additional artifacts
such as reference models, reference implementations, factory
setup guides, and project planning aids can be used to mature
the reference architecture. By using a common meta model, all
relevant domains can be documented in a consistent manner.
13 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
Reference Architecture and
Knowledge Management
The field of knowledge management provides tremendous
insight into reference architecture.
Knowledge management is the explicit and systematic man-
agement of vital knowledge and its associated processes of
creation, organization, diffusion, use, and exploitation. As you
did with the definition of reference architecture, you can exam-
ine this definition in further detail.
Explicit
Knowledge management encompasses both tacit knowledge
(in people’s heads) and explicit knowledge (codified and ex-
pressed in databases, documents, and the like). By making
knowledge explicit, it can be broadly communicated and lev-
eraged. This is exactly what reference architecture does when
it articulates proven solutions to common problems by using
the artifacts described above.
One of my colleagues coined the phrase “living architecture”
to describe the reliance upon the experience and judgment of
certain key architects. Living architecture is not sustainable.
By codifying the knowledge of these individuals and making
it explicit, a reference architecture can leverage their knowl-
edge more broadly.
Systematic
Leaving things to chance won’t achieve the benefits of knowl-
edge management. There must be a process to create, or-
ganize, communicate, use, and exploit knowledge. The same
applies to reference architecture. A reference architecture
shouldn’t be a one-time activity. There needs to be a process
to create, store, communicate, use, govern, and refine refer-
ence architecture artifacts.
Vital Knowledge
Certain knowledge is essential to an organization’s mission.
Knowledge management focuses on capturing this vital knowl-
edge. In a similar way, a reference architecture focuses on the
common solutions that are leveraged on the greatest number
of projects. There should be a justifiable benefit to capturing a
reference architecture for a given problem domain.
From the parallels, you can see that reference architecture is
really a type of knowledge management. It makes vital archi-
 Enterprise Architecture: The Journey Begins Here, Part 1
tecture knowledge explicit, and requires a systematic process
to build and leverage this knowledge.
Reference Architecture Lifecycle
I call the systematic process to build and leverage vital archi-
tecture knowledge the reference architecture lifecycle. This
lifecycle occurs in three phases: reference architecture cre-
ation, project initiation, and project delivery.
Phase 1: Reference Architecture Creation
The process of reference architecture creation begins
with identifying problem domains that need well-articulated
solutions. There should be key projects dependent upon
vthis work.
The first place to look for reference architecture assets are
from existing projects that have successfully delivered IT as-
sets within a problem domain. When new technology is intro-
duced into a domain, existing assets may not exist. The initial
reference architecture may be developed from industry mod-
els. However, imposing externally developed reference archi-
tectures on an organization may not work. Ideally, a reference
architecture should be customized to suit a particular organi-
zation’s culture, mission, existing assets, skill sets, principles,
standards, vendor relationships, and other factors.
A determination of what reference architecture assets are
needed should be made and chosen from the set of artifacts
described in the reference architecture meta model. When
these assets are created, they need to be validated and stored
in a reference architecture repository. There should be a tax-
onomy for organizing the reference architecture artifacts of
the relevant architecture domains.
Phase 2: Project Initiation
The project initiation phase assumes that reference architec-
tures have been created and a general knowledge of them has
been communicated. When a project is initiated, the appropri-
ate domain reference guides are consulted to determine the
solutions appropriate to the project. The reference models to
be used are identified. One of the benefits of reference archi-
tecture is a more robust solution delivered in a shorter time-
frame. The knowledge stored in the reference architecture is
leveraged. It is important that there be a governance mecha-
nism to ensure that project architectures are in accordance
with and leverage the relevant reference architectures.
14 Back to Contents Enterprise Architecture: The Journey Begins Here. An Internet.com Enterprise Architecture eBook. © 2009, WebMediaBrands Inc.
Phase 3: Project Delivery
Once the reference guide has been consulted, reference
models chosen, and the candidate architecture is approved,
a project moves into the delivery phase. At this point, several
reference architecture artifacts are leveraged to accelerate
delivery. The project planning aids assist the project manag-
er in identifying all the roles and responsibilities needed and
in estimating the work to be done. The factory setup guide
defines the environments that will be needed throughout the
software development lifecycle. Reference implementations
assist in the development of code.
Repeat
At the conclusion of a project, new IT assets are developed
and there are new lessons to be leveraged. This work is har-
vested to update the reference architecture and the reference
architecture lifecycle repeats itself.
Summary
In this article, you reviewed an industry-accepted definition of
reference architecture. You expounded upon this definition,
and reviewed the types of reference architecture artifacts
used by project stakeholders. These artifacts included refer-
ence guides, reference models, reference implementations,
factory setup guides, and planning aids.
You learned how reference architecture is a type of knowl-
edge management activity. Through reference architecture,
vital knowledge is captured and leveraged. Like knowledge
management, reference architecture requires a systematic
process. You reviewed the reference architecture lifecycle
and a repeatable process for creating reference architecture
artifacts that are leveraged in project initiation and delivery.
Through your overview of reference architecture, you’ve
learned that it is not an ivory tower activity, but it is essential to
delivering quality IT assets (better), more quickly (faster), and
with a lower total cost of ownership (cheaper).
Has your organization identified the architecture domains vital
to its mission? Are these domains documented through refer-
ence architecture? Is there a standard set of reference archi-
tecture artifacts designed for project stakeholders? Is there a
systematic process for managing the reference architecture
lifecycle? If not, consider starting or maturing the reference
architecture practice in your organization.
References
1. Reference Architecture: The Best of Best Practices, Paul Reed,
September 15, 2002
2. Knowledge Management – The Basics, Dr. David J. Skyrme, 1999