1

An Agile Approach to Enterprise Business Architecture: Part I - Introduction to the Series and the Conceptual

Data Modeling Technique By Moira Forbes

Introduction

The ability to adapt to market pressures is a huge asset for a business that wants to remain

competitive. When a business applies the Agile Value System to its Business

Architecture practices, a business is well positioned to react to market change quickly and

with minimum disruption.

While software development methodologists generally agree that Agile practices provide

a pragmatic approach for modern software development projects, Agile Values are rarely

applied on Enterprise Business Architecture initiatives. The intention of Enterprise

Business Architecture is to facilitate the communication of business ideas in support of

business improvements and potentially business automation. Business Architects improve

the effectiveness and efficiency of communication when they enable ongoing and

focused discussion of the business need and facilitate the gradual, shared understanding

of the business stakeholders. This efficiency is the key benefit that the Agile Value

System can bring to Enterprise Business Architecture.

This is the first in a series of articles that will explore some modern and traditional

Business Architecture techniques and suggest ways that the techniques can be used or

altered to take advantage of the benefits of Agile. The articles are intended to help

Business Architects to enhance their toolkits in order to become more effective conduits

for communication.

… but first let’s establish a common vocabulary so that we are all on the same

page!!!

What is Agile?

In the late 1990’s, new software development methodologies were emerging as

alternatives to the document-driven, heavy-weight software development processes of the

early 90’s. In 2001, 17 of the world’s leading methodologists got together in Utah to

discuss these new methodologies, and to develop a manifesto that described their

common values and principles, i.e., the Agile Manifesto. Agile is not a methodology but

rather, a value system that is shared by, but not limited to, a number of software

development methodologies (e.g. SCRUM, XP, Crystal Family of methodologies, Agile

Unified Process).

2

The Agile web site (http://agilemanifesto.org/) provides more information about the

Values and Principles of the Agile Manifesto. Perhaps after reading this, you too will

become a signatory to the Manifesto!

Business Analysis vs. Business Architecture

Business Analysis is the act of analyzing a business situation. An (Enterprise) Business

Architecture is a representation of a business enterprise that is intended to facilitate

discussions towards optimal business transformation and/or automation. Using models to

describe the architecture of a business enterprise enables the business by effectively

articulating its characteristics and needs so that the process of improvement is made more

efficient.

The Business Analyst and Business Architect role both perform Business Analysis and

act as conduits for communication between the various business players and between

business and IT. The roles can both be responsible for describing the business’s structure

and behavior or for creating specifications for systems. However, the Business Architect

has a more specialized and global role.

“The Business Architect must work with the business to understand the business’s

mission, goals, objectives and strategies, and its products and services, and supporting

organizational and technological infrastructure, in order to succinctly describe the

business architecture in a "structured picture", or model. The business architecture

includes the information, processes, people and technology required to produce and

manage the products and services. The Business Architect works with management and

subject matter experts to analyze and optimally transform the business architecture, or

model, to meet the organization's strategic business plans.” – Cheryl Lawrence

This series of articles will use the acronym BA to represent both the Business Analyst

and the Business Architect role.

BAs are most commonly engaged to specify requirements for systems. Being sensitive to

the Business Architecture shifts a BAs focus of attention from describing the

characteristics of a particular target system to enabling the business. Here is an example

of how the difference in focus between a BA (focused on describing the Business

Architecture) and BA (chiefly concerned with specifying requirements for a particular

system) impacts system development. My team just finished a business architecture

project that described money transfer operations for a major bank. Our initial thought was

that a single system would support the business. Over the course of the initiative, because

the Business Architecture was captured and structured into functionally independent

components that were related yet had evolving informational inter-dependencies, the

Business and IT came to the conclusion that modifying an existing system and

developing two new systems would be more efficient, economical and effective. The

three systems were aligned to the Business Architecture and a gap and overlap analysis

verified that the new and existing systems would work in concert to support the business

need. An unanticipated outcome of collaborating with IT on the initiative was the

3

realization that the business operations and the previously existing system were doing

some things that were inefficient, unnecessary or just plain wrong.

What is Enterprise Architecture?

The term Enterprise Architecture refers to a practice of describing the structure and

behavior of an enterprise (usually a business enterprise) using rigorous, methodical

models and techniques. Enterprise Architecture encompasses four domains:

information modeling, i.e., what information

business modeling, i.e., what processes

organizational modeling, i.e., what skills and human resources, and

technology modeling, i.e., what technology resources, both machinery and

automated systems are required to deliver and manage the products and services

of the business.

Although many organizations focus their Enterprise Architecture efforts only on

technology modeling, the basis of an Enterprise Architecture should be on the

(Enterprise) Business Architecture.

While the underlying framework of a Business Architecture is relatively stable, some

elements of the business are more likely to change than others, i.e.

Information requirements and their related processes are relatively stable and only

change when new products and services are added or eliminated;

Business Rules that constrain the way that process steps are executed are subject

to change (e.g. when new regulations are introduced)

Organizational requirements are more dynamic as they can be impacted both by

the people and technologies doing the work;

Technology changes frequently as new automations are introduced.

Changes in any of an enterprise architecture’s domains should be traceable to a business

need i.e. How can a change further the business’s purpose more efficiently or effectively?

Current State of “Agile” Adoption in Business Architecture

Occasionally, Business Architects claim to comply with Agile principles by developing

high level or “light” business architecture documents that provide little or no value for IT.

Conversely, Business Architects may create comprehensive architectural descriptions of

the business that the business itself hasn’t the time or inclination to review and confirm.

The volume of information in comprehensive documentation can result in key ideas being

lost in the details, lessening the artifacts’ value as communication tools. IT roles that are

focused on looming deadlines are not likely to think that wading through the (possibly

inaccurate) details of such documents is an effective and efficient use of their time.

4

Adopting an Agile approach to Business Architecture accepts that the business is

constantly evolving to meet the changing market needs. The discussion with IT is an

ongoing one that enables it to gradually gain understanding of the problem domain and

ensure that the artifacts being produced are useful. Gaining early understanding provides

IT with the time to mull over the problem and experiment with implementation

possibilities. This collaboration also gives the business the opportunity to concurrently

consider various automation scenarios and technology opportunities.

Businesses should be wary of big investments in low hanging fruit! It is important to find

the “sweet spot” in software design where business agility is not compromised. The

Business Architecture informs the decision as to where that “sweet spot” should be.

Focusing on the design of systems without carefully considering where the business

needs flexibility can greatly limit the agility of the business. While many Agile

enthusiasts will say that the idea of Agile Business Architecture is counter intuitive to

Agile’s focus on “developing functioning software quickly”, adopting Agile Business

Architecture will bring value for the business by shifting the focus on Agile projects to

“enabling the business quickly”.

Some Agile ideas that should be applied to Business Architecture:

Put control over IT initiatives into the hands of the business by giving them the

tools to control what IT develops

Encourage face-to-face communications between business and IT. Provide an

environment where this can occur efficiently. Set up collaborative stakeholder

teams that span the traditional boundaries of the organization (business and

technology) and have the team work in the same location as much as possible.

Recognize that businesses are dynamic. A low level of detail in documentation of

processes and workflow suggests that they are static and makes an organization

less likely to embrace change and be ready to adapt to the changing market needs.

Comprehensive documentation may be required for manufacturing where ISO

standards must be adhered to in order to ensure variations in process do not cause

product defaults; this approach is not of benefit to most other types of businesses.

A Business Architect’s primary focus should be on communication rather than on

the production of particular artifacts. Limit documentation to what is useful and

essential for understanding and communication rather than what is required by

outdated bureaucratic policy. If you work for a large organization that has rigid

bureaucratic policies for Business Architecture, focus on communication first and

satisfying bureaucratic policy later. The eloquent descriptions that come from

clear understanding are worth waiting for.

Understand the business in small increments. Obtain rapid feedback from

business and IT stakeholders and document what is essential for understanding

and discussion.

Model the business visually (process and information). Refine models over time;

don’t be afraid to throw out a model and replace it with a better one!

Describe things in broad stokes so that they can be understood in a short time.

Develop high level generalizations that avoid precision but not accuracy. This

5

means that you may have to (eventually!) understand the problem in depth and

then raise the level of abstraction in your description.

Embrace change. Don’t be afraid to throw away early work as you gain greater or

new understanding of the problem. Architectures evolve from the understanding

of the current requirements to identifying the needs of the future. Always look for

ways to simplify and refine your descriptions of the business.

Consider simple tools that focus on communication (e.g. Excel spreadsheets,

Visio, MS Word). There are huge benefits to using more sophisticated Case tools

(e.g. Enterprise Architect) and tools that facilitate traceability between the

Business Architecture, System Architecture and Test Architecture (e.g. the IBM

Rational Tools) but if access to the tool is limited, the learning curve is too high,

or the features of the tool do not provide high value immediately, sophisticated

tools can actually inhibit communication.

Reflect on how things are going on the initiative and look for ways to fine-tune

the process.

Conceptual Data Modeling

A Business Architect must be able to help the business to discuss, assess and

communicate the information requirements for day-to-day business operations and for

systems. For example, for a business that processes “Orders”, it’s very important for the

business and IT to agree on:

what constitutes an Order, i.e., what information, or attributes are required for

each type of order

what management information is required for an Order, e.g., what are the

transition states of an “Order”, e.g., open, released for fulfillment, on hold,

fulfilled, dispatched to customer, closed, etc.

The remainder of this article will focus on a technique for capturing the business’s

information needs called “Conceptual Data Modeling”.

A Conceptual Data Model (CDM) is a technology independent information model that

provides value to the stakeholders by formalizing the semantics of the business and

demonstrating how various business concepts relate to one another.

Conceptual Data Modeling is not the most obvious first step in a Business Architecture

initiative but there are three reasons for selecting to start the series with Conceptual Data

Modeling:

1. To demonstrate that Agile Business Architecture techniques can be used at any

point in an initiative (i.e. whenever the BA thinks that the technique will enhance

communications or understanding with the stakeholders!).

2. Accurate articulation of information concepts that are important to the business

and the relationships between those business concepts are crucial for

understanding and communicating a business’s needs.

6

3. Entity Relationship diagrams (part of a Conceptual Data Model) can be used as a

short hand during meetings with a business person or to develop an agreement

between the members of a cross-functional working group. For example,

preliminary, informal models captured on paper or a whiteboard can be shared

with business experts so that they can confirm that business concepts have been

understood properly. You’d be amazed at how quickly a business person can

correct mistakes when they see what they’ve just finished saying captured in a

picture!!

A Business Architect develops a CDM:

• To capture a common vocabulary (semantics of the business) that can be used by

everyone on the current project and on subsequent projects when discussing the

business and its needs

• To identify and document the business’s information needs

• To discover, describe and document business rules that relate to the business’s

information

• To ensure that data is stored and made available to the business in the appropriate

format

A traditional Conceptual Data Model includes:

Entity Relationship Diagrams (ERD) that provide visual representations of

“information” business rules. The ERD shows:

1. Entities, i.e., and Entity represents a general set of information or “thing”

that the business needs to track or access information on

2. Relationships between the various entities (e.g. an Account might have

multiple Account Owners but must have at least one)

A Data Dictionary that provides a textual description of each Entity along with a

description of each Attribute that the business needs to track or access for the

Entity. For example: Entity = “Account”; Attributes = “Account Number”,

“Account Type”, “Account Creation Date”, “State of the Account”, etc

7

Entity Relationship Diagrams

The following sample Entity Relationship Diagram (ERD) shows a Bank account and its

related Business Entities (a.k.a. Business Concepts):

Transaction

Credit

Debit

AccountAccount Owner

Product Type

The diagram represents a number of business rules:

• An Account is defined by one and only one Product Type

• A Product Type may define multiple Accounts

• An Account Owner must have one or more Accounts

• An Account must have an Account Owner

• An Account may have more than one Account Owner

• An Account may have zero to many Transactions

• Each Transaction must be associated with one and only one Account

• Each Transaction must be either a Debit or a Credit (can’t be both)

• An Account can have both types of transactions (Credits and Debits).

NOTES:

BAs discover Business Entities in the course of discussing various business

scenarios or eliciting or elaborating System Requirements (e.g. graphical

user interfaces, etc.)

An ERD diagram is much easier to create, review and modify than the

verbal version of the business rules.

8

Although it is prudent to provide the business and the IT team with a short

explanation of the ERD notations, most business people find the technique

intuitive, useful, and much easier to review and confirm than the verbal

descriptions. Drawing a small, informal ERD on a whiteboard and allowing

stakeholders to modify it or negotiate changes to it is a wonderful way to

engage the stakeholder group and gain agreement quickly. The ERD

facilitates conversations and helps resolve issues. It also provides the

business with a vehicle to ensure Business/IT alignment with respect to the

(inevitable) database design.

Benefits of sketching an ERD on paper or a whiteboard as the discussion

takes place:

o Helps the business to describe their business in a rigorous way

o Helps the everyone to understand the problem domain

o Helps the BA confirm that they have accurately understood the

business need

o Provides clear, efficient short-hand for capturing business

descriptions (e.g. rules)

o Helps Business and IT capture a common vocabulary that everyone

can share

Visio is an adequate tool for formally capturing the ERD fragments.

ERDs provide a good jumping off point for understanding the benefits of

business entity services that form the back-bone of Service Oriented

Architecture.

(Business) Entities

The Rectangular boxes in a Conceptual Data Model’s ERD are called (Business) Entities;

in a CDM, they represent Business Concepts. A Business Entity represents a general set

of information or “thing” that the business needs to track or access information on.

• Examples: Account, Transaction, Product Type, Account Owner, Account Status

In the ERD, the Entity name should be a singular Noun. Use the business language to

name the Entity. Remember that the reason that you are creating a Conceptual Data

Model ERD is to establish the vocabulary that should be used on an ongoing basis. In

traditional Conceptual Data Modeling, each Entity will have a related entry in the Data

Dictionary that describes the entity and its associated attributes (i.e. information pieces).

9

Cardinality Relationships

The ERD representation for relationships between Entities is a “line” connecting the two

Entities with a “cardinality” symbol at each end. “Cardinality” identifies the number of

allowed instances of an Entity in relation to a single instance of the related Entity. For

example: An Account can have one to many (related) Transactions. A Transaction is

related to one and only one Account. There are various notation styles that can be used to

represent cardinality; this article uses the “Information Engineering Style” (available in

Microsoft Visio).

Relationship Endpoint Cardinality examples:

One-to-many

Zero-to-many

One-and-only-one

Zero-or-one

Cardinality Example:

The following diagram shows:

• A Person may have zero or more Accounts

• Every Account must be associated with at least one Person

• An Account might be associated with more than one Person

Person Account

NOTES:

You read the relationship line first in one direction and then in the other.

10

Type Relationship

A “Type” Relationship is used to show specializations of an Entity where different data

needs or business rules apply according to “Type”. The notation that is used to identify a

Type is an empty arrow head

For example, this diagram shows:

• There are two types of Accounts

• It is likely that different information needs to be collected according to the

Account Type (different Business Rules as well)

Account

Personal

Business

NOTES:

”Business” and “Personal” Account Types are mutually exclusive. Mutually

Exclusive means that the Account Type is either a Business Account or a

Personal Account but not both. There are situations where a “Type”

relationship is not mutually exclusive; in other words, the entity can be the

two types at one time. For example, a Person might be a Doctor and a

Lawyer. Various CDM notations provide symbols to represent that a set of

“types” is mutually exclusive or not mutually exclusive. If you don’t have

access to a tool that provides specialized symbols to identify whether a type

is mutually exclusive of not, you can use a note on the diagram to specify

that a “type” is NOT mutually exclusive (NOT Mutually Exclusive is much

less common than Mutually Exclusive).

11

Data Dictionary

A Data Dictionary provides textual descriptions of the business’s information needs. An

entry in the Data Dictionary can map to a business entity described in an ERD or to a

Data Nickname that is used in Business Rules or process descriptions to describe a set of

data. Data Nicknames will be discussed in a later article.

The following is an example of a Data Dictionary entry for the Account Entity:

ACCOUNT

Definition: A formal business arrangement providing for regular service involving the

establishment and maintenance of the account and its transactions. The type of Account

is determined when the Account is created.

Attributes:

Name Description Data Type

Account

Number

A numeric identifier of the

account

Characters

(7)

Product Type Holds a code that indicates the

type: Powerchequing, Basic

Banking, etc.

Characters

(6)

Account Open

Date

Holds the date that the account

was created

Date

Account Close

Date

Holds the date that the account

was closed (NULL until closed)

Date

Attributes

An Attribute represents one piece of information in an Entity’s information set. Example:

Attributes of Account are: Account_number, Account_Open Date, Account_Close Date,

Account_Product Type.

Rules:

Use the language of the business where possible when naming an attribute

Each Attribute must be attributed to one and only one Entity

The Attribute Name should be a singular noun preceded by the Entity name

separated by “_”

Data Dictionary entry for an Attribute includes the Attribute Name, Description

and Data Type – more rigorous constraints on the allowed values are described in

Business Rules

NOTES:

12

Sometimes an attribute can be mistaken for an entity. If you find that there

is a one-to-one relationship between two entities, then one of the entities is

probably an attribute of the other entity.

GUI mockups are a good place to find the attributes of entities. Also

consider electronic messages that need to be sent to or from the business to

other businesses or systems.

Conceptual Data Models and Tables

Entity Relationship Diagrams were originally introduced to model the contents of

relational databases. The entities in the ERD represent the database tables. Each table has

a name (the name of the entity) and each attribute of the table can be thought of as a

column in the table. The rows in the table hold the data. The Conceptual Data Model

entities can also be thought of as tables. You could build a model of a database (including

data) in an Excel workbook such that each table would have a dedicated spreadsheet.

Example:

ACCOUNT Table

Account

Number

Product

Type

Account Open

Date

Account Close

Date

1352564 000002 Jan-3-2000 Dec-20-2005

0546878 000001 Nov-22-1998 NULL

8765390 000001 Jan-29-2006 NULL

13

Managing Relationship Attributes (at the conceptual level)

Relationships between entities are managed in databases using special attributes called

“Primary Keys” and “Foreign Keys”. The Primary Key is a unique identifier for an entry

in a table; a Foreign Key is a reference to a Primary Key of an entry in another table, i.e.,

it cross-references an entry in another table. Following is a demonstration of how that

works (conceptually only!):

ACCOUNT Table

Account

Primary

Key

Account

Number

Account

Type

Foreign

Key

Account Open

Date

Account Close

Date

1 1352564 000002 Jan-3-2000 Dec-20-2005

2 0546878 000001 Nov-22-1998 NULL

3 8765390 000001 Jan-29-2006 NULL

ACCOUNT TYPE Table

Account

Type

Primary

Key

Account

Type Short

Name

Account Type Long Description

000001 Basic

Chequing

Basic Chequing Accounts provide customers

with the ability to write cheques without

having to pay a high transaction cost per

cheque. However, the interest accrued on

money in this account is at a lower rate than

Savings Accounts offer.

000002 Basic

Savings

Basic Savings accounts provide a

moderately high rate of accrued interest for

customers. However, transaction costs are

higher than those applied to Basic Savings

accounts.

000003 Super

Savings

Super Savings accounts provide the highest

of accrued interest but transactions are also

the highest.

Notes:

The Account “Primary Key” is a unique identifier for the Account.

The Account Type “Primary Key” is a unique identifier for the Account Type.

14

In the Account attributes, the Account Type Foreign Key identifies the type of

Account by referencing the Primary Key of the Account Type table.

NOTES:

The Conceptual Data Model ERD makes relationships between entities

obvious for the Database Designer.

Primary and Foreign Keys are attributes that are intended to be solely used

(by a computer) to track relationships; they are not codes that human beings

will use in everyday business conversation. If a unique identifier is something

that the business uses in everyday business language, such as account

number, then create an Attribute for it. This is not a Primary Key as it is not

the code that is intended solely for a computer’s use to keep track

relationships between tables.

Relationship Entities

Occasionally, an entity is required to track information on relationships between entities

when the relationship itself is something that is an important concept for the business.

Example:

The following ERD states:

An NHL Team can have one to many Hockey Players

A Hockey Player could play on one or more Hockey Teams (over the course of

their career in hockey)

NHL Team Hockey Player

For various reasons, it is important to know which player played on which team and

when. There are attributes of the NHL Team / Hockey Player relationship that are

important to capture i.e. the dates the Hockey Player played on the team, whether the

relationship was severed and the reason (e.g. poor conduct), whether the Hockey Player

was the captain, right-wing, etc…

To bring out the importance of the NHL Team / Hockey Player Relationship, the

Business Architect would create the following:

NHL Team

NHL Team /

Hockey Player

Relationship

Hockey Player

15

The following is a small sample of the data that might be tracked in the Entity related

tables:

NHL Team Table

Team

Primary

Key

Team Name City

1 Oilers Edmonton

2 Canadiens Montreal

3 Red Wings Detroit

4 Kings Los Angeles

Hockey Player Table

Hockey

Player

Primary

Key

Last Name First Name

A Gretzky Wayne

B LaFleur Guy

C Howe Gordie

NHL Team / Hockey Player Relationship Table

NHL

Team

Hockey

Player

Start

Season

End Season Jersey

Number

1 A 1979 1988 99

4 A 1988 1996 99

2 B 1971 1985 10

3 C 1946 1971 9

16

Agile Conceptual Data Models

Unlike traditional Conceptual Data Models that provide a comprehensive description of

the business’s information needs and are frequently intended to form the first draft of a

database, Agile Conceptual Data Models are intended to support efficient communication

by capturing the semantics of the business and documenting important or complex

conceptual ideas. The Agile Business Architect stimulates stakeholder communication by

producing ERD fragments that are uncluttered by details and highly coupled to the

current discussion. Even a discussion as to which data should be included in a report

revolves around the processes that use the report (e.g. what knowledge is required to

inform a particular decision?). Just enough information is captured by the Business

Architect to support critical understanding and agreement between the stakeholders.

Detailed data needs are worked out when and if a database is developed.

If a decision is made to evaluate a Commercial Off-the-shelf solution (COTS), a more

comprehensive Conceptual Data Model may be useful in order to measure the gaps

between the COTS solution and the business need.

Some organizations require a high level of formality in the model (e.g. entity and

attribute naming convention usually regulated by IT). In addition, some modeling tools

constrain the formality of the model. Enforcing this type of rigor early in the Architecture

process inhibits communications with the business and affects the business’s ability to

adopt and own the CDM. In an effective Agile ERD, the Entity names are in the language

of the business rather than in “computer speak” (e.g. constrained Entity name length, use

of underscores, codes, acronyms, etc.). The Agile Business Architect is more concerned

with helping the business to articulate their needs in an unambiguous and rigorous way

than they are with creating a CDM that is compliant with code implementation standards.

When an Agile approach is taken to Business Architecture, the Data Architect

responsible for creating the logical and physical database models should be engaged

early. The Data Architect can suggest improvements to the ERD fragments, or point out

short-comings, but the business should ultimately own the CDM. The business is

empowered to do this when it feels comfortable that it understands and agrees with the

model(s).

An Agile Business Architect needs to be skilled enough at Data Modeling to be able to

ensure that the Conceptual Data Model and the database design are aligned. However, the

Data Architect would be responsible for demonstrating alignment and documenting the

mapping of the Conceptual Data Model to the Logical database model entities and

attributes. Data discussions with the stakeholder group should use language in the

Conceptual Data Model and avoid using implementation language (i.e. Logical or

Physical Database Entity names).

17

Summary

ERDs are one of the most powerful and useful tools in a Business Architect’s toolkit.

They provide a wonderful short-hand for capturing business concepts and are a powerful

tool for communication!! The focused view that Agile Conceptual Data Modeling

provides improves the efficiency of communications and facilitates early understanding

by IT so that software development is expedited and business gains benefits quickly.

NEXT ARTICLE: An Agile Approach to Business Architecture: Part II – Developing a Business Vision

“Enterprise Business Architecture … a blueprint of the enterprise that provides a

common understanding of the organization and is used to align strategic objectives and

tactical demands.” - Object Management Group’s Business Architecture Working Group

The effectiveness of a Business Enterprise is measured by the business’s ability to meet

the needs of its Stakeholders. Each Stakeholder objective should be mapped to

quantifiable measures that are indicators of the Enterprise’s effectiveness at meeting its

goals. The next article will discuss ways that a Business Architect can understand and

describe the business context to ensure that changes to the business or its systems help

the Business Stakeholders to achieve their goals. In addition to teaching the Business

Architecture Context Diagram technique, the article will teach Business Architects how

to help develop the Business Vision by considering:

Stakeholders

Stakeholder Needs

Business Strategy

Business Strategic Objectives

Indicators of Business Success

Business Outcomes

Acknowledgements

I would sincerely like to thank Cheryl Lawrence for her feedback and advice on an early

draft of this article and also for the many enjoyable, late-night discussions we had on

Enterprise Architecture in the real world. I must also thank Scott Ambler, Alistair

Cockburn, Sanjiv Augustine and Kent Beck for the wonderful ideas that you’ve

introduced me to in your books and papers. Last but not least… I’d like to thank Rob

Beckmann for encouraging me to write!!

18

Bibliography

Scott W. Ambler, (2002) Agile Modeling: Effective Practices for eXtreme Programming

and the Unified Process, Wiley Computer Publishing

Scott W. Ambler, John Nalbone, and Michael J. Vizdos, (2005) The Enterprise Unified

Process: Extending the Rational Unified Process, Prentice Hall

Kent Beck, Cynthia Andres: (2005) Extreme Programming Explained: Embrace Change,

Addison-Wesley

Sanjiv Augustine, (2005) Managing Agile Projects. Prentice Hall

Steve Hoberman, Data modeling made simple: a practical guide for business &

information technology professionals 2nd

Edition, New Jersey, Technics Publications

Cockburn, A. (2000) Agile Software Development: The Cooperative Game(2nd

Edition).

Reading, MA: Addison-Wesley.

Cockburn, A. (2000) Writing Effective Use Cases. Reading, MA: Addison-Wesley.

About the Author

Moira Forbes is an Enterprise Architect and Methodologist who has been practicing

in the Toronto area since the late seventies. In addition to leading many highly

successful software development projects, Moira has helped a number of large

organizations develop software development principles, standards and guidelines

that are practical and align to industry best practices.