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

In Step 2 of the 4C process, a scheme to classify an organiza- Once assets have been mapped to zones, new insights into
tion’s assets is devised, and the assets are mapped into that the IT portfolio will be evident. You may discover that you have
classification scheme. three applications providing account management functional-
ity, that customer information is stored in five different places,
Defining the Classification Scheme and that you have service bus functionality being provided in
The classification scheme defines the high-level city plan four disparate places.
zones relevant to your organization’s mission. This scheme, in
whole or in part, might come from accepted industry models Because IT assets were created without a blueprint in the
or leading vendors that focus upon your industry vertical. past, you shouldn’t be surprised to find many redundant func-
tional, data, and platform assets.
A simple scheme I’ve found useful is the function/data/plat-
form classification. This scheme defines the high-level func- In many cases, multiple assets within a zone can be quite ra-
tions, data, and platforms essential to an enterprise. Function- tional. There may be clear guidelines for using the workflow
al zones include the functions across the business value chain capabilities in a CRM versus an enterprise business process
such as account management, product management, and bill- management (BPM) tool. A division may require autonomy
ing. Data include all of the major subject areas such as cus- because it may be sold and it doesn’t want its IT assets en-
tomer and product. Platforms include all of the software and tangled with those of the enterprise. A merger may have just
infrastructure needed to run the business such as databases, occurred and the driver behind the blueprint is to assess the
application servers, operating systems, and hardware. assets of the new combined enterprise.

How does it all tie together? Consider the example of a finan- In other cases, multiple assets within a zone can be quite ir-
cial services firm. To run its business, it requires an account rational. Lack of an enterprise architecture function may have
management system (function) to maintain customer informa- led to decisions in the past that may have made sense given
tion (data). The account management system requires an ap- the myopic view of an individual project, but clearly not for the
plication server and a relational database (platform). enterprise as a whole.

Mapping Assets In enterprise architecture, application rationalization is the pro-

Once a classification scheme has been devised, the organiza- cess used to simplify the assets within a zone. In mathemat-
tion’s assets are mapped to the function, data, and platform ics, rationalization is about simplifying an expression so that
classification zones. This provides a useful picture of the or- it still produces the same result. Application rationalization is
ganizations IT assets. This data may be collected in a spread- similar in that it tries to simplify the assets with a zone while
sheet, or in an enterprise architecture tool. still providing the same business function and level of quality.

Note that many assets will map to multiple zones. A good ex- Assessing Adequacy
ample is a Customer Relationship Management (CRM) sys- Each asset should be assessed for business and technical
tem. The CRM maps to the account management functional adequacy. Adequacy can be assessed by interviewing busi-
zone. Its database maps to the customer data zone. The sys- ness and technical subject matter experts, through surveys,
tem-to-human workflow and integration capabilities inherent service level agreement reports, and through mapping the as-
in the CRM map to the business process and service bus set to the relevant reference architecture or building codes.
platform zones.
Business adequacy should be measured by parameters such
Step 3: Cluster as functions performed, cost effectiveness, and usability.
Step 3 of the 4C process examines the cluster of assets in Technical adequacy can be measured by a quality attribute
each classification zone in detail and determines the business assessment of how well an application is meeting its design
and technical adequacy of the assets. Coming out of Step 3, and runtime quality goals. Mapping an application to the rele-
each asset will be given a disposition of invest (green), hold vant reference architecture is useful in the assessment by pro-
(yellow), or sunset (red). 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

5 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

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 to assets by the execution of architecture transition plans
the consolidation approach for each cluster through an archi- • retired assets
tecture transition plan.
Putting the Architecture Blueprint to Work
Architecture Transition Plan An architecture blueprint is an invaluable tool to guide an en-
The architecture transition plan uses the reference architec- terprise in making its IT investments. The blueprint, like any
ture or building codes to determine the current state of the tool, does no good sitting in the toolbox. It needs to be taken
zone, the rationalized future state, and the series of steps re- out and used regularly.
quired realize the future state. Multiple options might be out-
lined to replace assets marked for sunset. If there were a 5th C in the blueprinting process, it would be
communicate. The facts learned and the insights gained from
The benefits of transitioning the architecture can easily be ar- the blueprint will be of interest to key business and IT stake-
ticulated due to the business and technical adequacy assess- holders. The blueprint will help guide the enterprise in making
ments done previously. However, execution of the architecture fact-based decisions about its future.
transition will be dependent upon investment in rationalization
projects or through funded business initiatives. If there were a 6th C, it would be commitment. Once under-
stood, the blueprint should be committed to by business and
Step 5: Repeat IT stakeholders to use it as a guide and to keep it up to date.
The city plan zones will stay stagnant in many enterprises. The thought put into the disposition of assets and architecture
However, the assets within them will vary. The blueprint must transition plans will make decisions easier going forward.
be refreshed on a regular basis to remain relevant.
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 governance performs a zoning function to guide its overall city
lower-cost future state. Proposed investments that are not in planning responsibility and to ensure newly developed assets
alignment with the blueprint will have a difficult time get- are created in accordance with defined building codes.
ting governance approval to proceed; for example, invest-
ments in assets marked for sunset. Investments in alignment The 4C process for creating an architecture blueprint collects
with the blueprint and architecture transition plans will be information about the IT portfolio, classifies it into relevant
accelerated. zones of assets, examines the cluster of assets in each zone,
and develops an architecture transition plan to consolidate the
An architecture blueprint is a deliverable that helps crystal- assets in each zone. This process is regularly repeated so that
lize the IT strategy. Investing the time and effort to create one the blueprint will continue to be relevant.
helps an IT organization to better serve the business that
is always looking for ways to improve quality, agility, and to Does your architecture team have an architecture blueprint
reduce costs. The blueprint helps IT to be a better steward to enable it to guide the evolution of the IT portfolio over
of the organization’s IT assets. With the architecture blue- time? Does it have a governance board to perform its city
print in hand, IT is well prepared to be a trusted partner when planning responsibility? Are relevant building codes for
business strategy efforts begin. new assets defined through reference architecture? If not,
consider creating an architecture blueprint using the 4C
Summary process as your guide.
You discovered that an architecture team can learn a lot from
References
urban planning. An architecture blueprint is essentially a 1. The term 4C was coined by my colleague and friend, Mike Stevens, who
city plan of an organization’s IT assets. Reference architec- is known for his books on Enterprise Architecture and SOA. Mike and I
ture represents building codes for new assets. Architecture co-developed the 4C blueprinting methodology and employed it at a major
financial services company.

7 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

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- solves a particular recurring problem. It is “pre-defined” so
ity with little relevance to software development that it can be used again the next time a project encounters a
projects? Or is it rather like a compass that similar problem. The solution patterns that may be captured
keeps projects on track and pointing toward their in a reference architecture includes the architecture patterns
destination? 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 Reference Guide

In the previous article on architecture standards, I discussed A reference guide provides an overview of a problem space
the benefits of architecture standards that define the prod- and a guide to proven solutions. The problem is described by
ucts, patterns, or practices to be used in developing or ac- a particular set of functional and non-functional requirements.
quiring software in an organization. You may be wondering, The solutions may be described by a conceptual diagram of
“What is the difference between architecture standards and how to architect a solution to meet those requirements. The
reference architecture?” solution also might leverage a set of organizational architec-
ture standards. The reference guide may contain a set of so-
Whereas standards identify enterprise “building blocks,” in- lutions and the criteria to choose among them. The primary
cluding vendor and open source products, reference archi- user of a reference guide is an architect. A reference guide is
tecture explains how the “building blocks” are constructed to not the only artifact used to describe a reference architecture.
solve a particular business problem. For example, the refer- However, it is probably the most important because it broadly
ence architecture for publishing content to a consumer portal defines the problem and proven solutions.
would show how the organization’s standard content man-
agement product, portal framework, and security standards Reference Models
would be used to solve this set of functional and non-function- Whereas the reference guide will tell you “what to build” giv-
al business requirements. en a set of requirements, reference models describe “how to
build” the solution. A reference guide may provide context for
Reference Architecture Artifacts multiple reference models.
A reference architecture may have several artifacts to docu-
ment what it is, when to use it, and how to use it. These arti- In Part 2, the article Achieving 20/20 Vision with Architecture

ArtiFACT Purpose description auDience

Reference Guide “what to build” Describes solutions which address sets of Architect
functional and non functional requirements.

Reference Models “how to build it” Specifies how to build a given solution chosen in Architect,
the reference guide Developer

Reference “working code” Working code that has been refined, tested and Developer,
Implementations validated and can be leveraged on a project. Architect

Factory Setup Guide “who does what” Outlines the development and production envi- Project Manager,
ronments. Roles and responsibilities are clearly Configuration
understood through the software development Manager
life cycle.

Planning Aids “plan the work” Provides templates for building a project using Project Manager
a particular reference architecture and includes
resource needs, timelines, training, estimating
guides, etc.

Table 1: Reference Architecture Artifacts

facts include the Reference Guide, Reference Models, Ref- Viewpoints, will discuss seven architecture viewpoints that
erence Implementations, Factory Setup Guide, and Project may be used to articulate a solution. A reference model may
Planning Aids. You will examine each type of artifact, its pur- use a number of viewpoints such as use cases, domain mod-
pose, and audience.

12 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

els, conceptual diagrams, sequence diagrams, or deployment Reference Architecture and

diagrams to describe the solution. A reference model is a de- Knowledge Management
sign asset that may be used on subsequent projects by archi- The field of knowledge management provides tremendous
tects and developers. insight into reference architecture.

Reference Implementations Knowledge management is the explicit and systematic man-

Reference models are much more valuable if they document agement of vital knowledge and its associated processes of
proven reference implementations. Reference implementa- creation, organization, diffusion, use, and exploitation. As you
tions are actual working code examples of the solution. A ref- did with the definition of reference architecture, you can exam-
erence implementation provides code assets that developers ine this definition in further detail.
may leverage on subsequent projects.
Explicit
Factory Setup Guide Knowledge management encompasses both tacit knowledge
People, processes, tools, and environments are needed to (in people’s heads) and explicit knowledge (codified and ex-
implement a solution. The factory setup guide artifact de- pressed in databases, documents, and the like). By making
scribes what is needed to develop and deliver a solution using knowledge explicit, it can be broadly communicated and lev-
the reference architecture. The factory setup describes the eraged. This is exactly what reference architecture does when
development, testing, staging, and production environments; it articulates proven solutions to common problems by using
how code is migrated through environments, the roles and the artifacts described above.
responsibilities of development and support personnel; and
so on. The primary users of the factory setup guide are the One of my colleagues coined the phrase “living architecture”
project manager and architect. to describe the reliance upon the experience and judgment of
certain key architects. Living architecture is not sustainable.
Project Planning Aids By codifying the knowledge of these individuals and making
Project planning aids are a key reference architecture artifact it explicit, a reference architecture can leverage their knowl-
because they assist project managers with successfully uti- edge more broadly.
lizing a reference architecture. Planning aids might include
project templates, resource allocation guides, estimating tem- Systematic
plates, staff training recommendations, and so forth. Leaving things to chance won’t achieve the benefits of knowl-
edge management. There must be a process to create, or-
Reference Architecture Artifacts ganize, communicate, use, and exploit knowledge. The same
Table 1 summarizes the reference architecture artifacts applies to reference architecture. A reference architecture
discussed above. Collectively, these artifacts create a meta shouldn’t be a one-time activity. There needs to be a process
model for documenting a reference architecture. to create, store, communicate, use, govern, and refine refer-
ence architecture artifacts.
Artifacts by Problem Domain
A set of reference architecture artifacts may be used to docu- Vital Knowledge
ment the reference architecture of a particular problem domain; Certain knowledge is essential to an organization’s mission.
for example, an n-tier transactional application architecture. Knowledge management focuses on capturing this vital knowl-
Note that a domain’s reference architecture need not include edge. In a similar way, a reference architecture focuses on the
all of the artifacts mentioned here. A reference guide is gen- common solutions that are leveraged on the greatest number
erally the best place to begin. Over time, additional artifacts of projects. There should be a justifiable benefit to capturing a
such as reference models, reference implementations, factory reference architecture for a given problem domain.
setup guides, and project planning aids can be used to mature
the reference architecture. By using a common meta model, all From the parallels, you can see that reference architecture is
relevant domains can be documented in a consistent manner. really a type of knowledge management. It makes vital archi-

13 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

tecture knowledge explicit, and requires a systematic process Phase 3: Project Delivery
to build and leverage this knowledge. Once the reference guide has been consulted, reference
models chosen, and the candidate architecture is approved,
Reference Architecture Lifecycle a project moves into the delivery phase. At this point, several
I call the systematic process to build and leverage vital archi- reference architecture artifacts are leveraged to accelerate
tecture knowledge the reference architecture lifecycle. This delivery. The project planning aids assist the project manag-
lifecycle occurs in three phases: reference architecture cre- er in identifying all the roles and responsibilities needed and
ation, project initiation, and project delivery. in estimating the work to be done. The factory setup guide
defines the environments that will be needed throughout the
Phase 1: Reference Architecture Creation software development lifecycle. Reference implementations
The process of reference architecture creation begins assist in the development of code.
with identifying problem domains that need well-articulated
solutions. There should be key projects dependent upon Repeat
vthis work. At the conclusion of a project, new IT assets are developed
and there are new lessons to be leveraged. This work is har-
The first place to look for reference architecture assets are vested to update the reference architecture and the reference
from existing projects that have successfully delivered IT as- architecture lifecycle repeats itself.
sets within a problem domain. When new technology is intro-
duced into a domain, existing assets may not exist. The initial Summary
reference architecture may be developed from industry mod- In this article, you reviewed an industry-accepted definition of
els. However, imposing externally developed reference archi- reference architecture. You expounded upon this definition,
tectures on an organization may not work. Ideally, a reference and reviewed the types of reference architecture artifacts
architecture should be customized to suit a particular organi- used by project stakeholders. These artifacts included refer-
zation’s culture, mission, existing assets, skill sets, principles, ence guides, reference models, reference implementations,
standards, vendor relationships, and other factors. factory setup guides, and planning aids.

A determination of what reference architecture assets are You learned how reference architecture is a type of knowl-
needed should be made and chosen from the set of artifacts edge management activity. Through reference architecture,
described in the reference architecture meta model. When vital knowledge is captured and leveraged. Like knowledge
these assets are created, they need to be validated and stored management, reference architecture requires a systematic
in a reference architecture repository. There should be a tax- process. You reviewed the reference architecture lifecycle
onomy for organizing the reference architecture artifacts of and a repeatable process for creating reference architecture
the relevant architecture domains. artifacts that are leveraged in project initiation and delivery.

Phase 2: Project Initiation Through your overview of reference architecture, you’ve

The project initiation phase assumes that reference architec- learned that it is not an ivory tower activity, but it is essential to
tures have been created and a general knowledge of them has delivering quality IT assets (better), more quickly (faster), and
been communicated. When a project is initiated, the appropri- with a lower total cost of ownership (cheaper).
ate domain reference guides are consulted to determine the
solutions appropriate to the project. The reference models to Has your organization identified the architecture domains vital
be used are identified. One of the benefits of reference archi- to its mission? Are these domains documented through refer-
tecture is a more robust solution delivered in a shorter time- ence architecture? Is there a standard set of reference archi-
frame. The knowledge stored in the reference architecture is tecture artifacts designed for project stakeholders? Is there a
leveraged. It is important that there be a governance mecha- systematic process for managing the reference architecture
nism to ensure that project architectures are in accordance lifecycle? If not, consider starting or maturing the reference
with and leverage the relevant reference architectures. 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

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