Aug15

Written by:
8/15/2011 6:22 AM 

Project Introduction

Let’s start at ground zero.  Well pretend that VenusPro has contracted me to help build their system and we have the completely fictitious, and abbreviated, dialogue below:   
 

VenusPro: We need to create a Strategic Access system.

MDeVerno: Ok, what does it do?

VenusPro: It allows people in the community to borrow goods, free of charge, from an access centre.

MDeVerno: I see. So it is like a library then?

VenusPro: Yes, but the goods someone can borrow can be anything: books, tools, vehicles, etc.

 
In this short bout we have created the Metaphor.  A Metaphor is one of the design rules in eXtreme Programming (XP) .  It is a good way to communicate the overall system; it is something that people can relate to; and it is similar to the elevator speech you would give to anyone asking about what you are building.  In our case, the Metaphor is a library, or The Great Library to be more precise.  

 Why Was the Scenario Chosen?

The Great Library is an open source project that addresses one of the core pieces of the Resource-Based Economy narrated in Zeitgeist: Moving Forward.  This core piece, Strategic Access, is explained at roughly the 1:41:40 mark of the movie.  I makes for a near ideal project to illustrate enterprise development, because:

• It is something that almost all (hopefully!) people have used before.  Therefore, it can foster discussion and suggestions from the community.

• It is a system that needs to spans multiple layers.  As such, a wide range of technologies can be demonstrated, like: ASP.NET MVC, WCF, Entity Framework, SQL Server, SSIS, etc.

• It contains deep domain language and rules that people can understand, helping to illustrate Domain Driven Design (DDD) and Test Driven Development (TDD).  We can also get into the benefits of good design patterns.

• It is extensible and can be used in a distributed system.

• And finally, it is something that is not trivial.  We cannot get it right the first time.  We’ll have to revisit, refactor, and make compromises along the way.  All of this is daily life in developing for the enterprise.

Next Post

We'll keep this post concise, much ado to the Metaphor.  In the next part of the series we'll flesh out some of the functional and non-functional requirements, dive into some agile methodology, and commit something to source control.