Re: [epf-dev] Request for discussion: Redefining Architecture Content fo

[Mark.Dickson@xxxxxxxxx]

Thanks for this Scott

I like the emphasis on storming the architecture on a JIT basis - it does a
good job of emphasising how the architecture is defined collaboratively and
iteratively.

Can we work with this idea to identify typical early goals for words,
pictures and code?

For example, in early iterations (typically in Inception and Elaboration)
we could;

a) Storm diagrams to agree
   architecture style
   technology choices
   identify the initial major components/subsystems and their interfaces
   principal abstractions / entities of the data model
   deployment across the network
   blah blah

b) write just enough words to
   make sure that the decisions made in above are understood by the team
   (and can be remembered)
   identify the most important mechanisms requiring a common solution and
   decide in which iteration they need to be made concrete

c) produce just enough software to
   satisfy the team that the approach is viable, with the view that if
   possible this software is evolved as part of the ongoing product
   development

I could see this kind of activity happening mostly around the whiteboard
with the team and taking anywhere between an hour and a couple of days,
depending on the complexity of the work and the maturity of the
organisation.

Just some thoughts

cheers

Mark

Mark Dickson
Executive Consultant
EAS Practice
m 0780 1917480
w www.xansa.com
e mark.dickson@xxxxxxxxx


                                                                           
             "Scott W. Ambler"                                             
             <swa@xxxxxxxxxxxx                                             
             >                                                          To 
             Sent by:                  "Eclipse Process Framework Project  
             epf-dev-bounces@e         Developers List"                    
             clipse.org                <epf-dev@xxxxxxxxxxx>               
                                                                        cc 
                                                                           
             22 January 2007                                       Subject 
             06:55 EST                 Re: [epf-dev] Request for           
                                       discussion: Redefining Architecture 
                                           Content for OpenUP/Basic 1.0    
             Please respond to                                             
              Eclipse Process                                              
             Framework Project                                             
              Developers List                                              
             <epf-dev@eclipse.                                             
                   org>                                                    
                                                                           
                                                                           





On Mon, January 22, 2007 6:18 am, Mark.Dickson@xxxxxxxxx said:
>
> 1. Emphasise the idea of "just enough architecture" so that a team using
> OpenUP/Basic can quickly start to deliver software in a consistent and
> coherent way

In AMDD, http://www.agilemodeling.com/essays/amdd.htm , we talk about how
you need to do just a bit of architectural modeling early in the project
to identify your architectural vision.  My December newsletter in DDJ
described just how much modeling needs to be done for various situations.
Perhaps we can take ideas from it?  See
http://www.ddj.com/dept/architect/196500031?cid=Ambysoft

The details should be model stormed JIT.


> 2. Integrate the concept of Architecture with the build-centric
philosophy
> of agile methods. OpenUP/Basic is already build-centric. We need to show
> that Architecture has value in evolving a good build.

Yes.  A bit of initial architecture modeling with JIT model storming seems
to work wonders.

> 3. We also need to clearly show how architecture tasks and products are
> *not* some sort of document-centric overhead that is somehow orthogonal
to
> the core objective of building software. Yes, the architecture work can
> generate documents and models. The point is that these are only created
> when they are necessary as steps on the path to getting a team working
> together.

Perhaps we should use terms such as "Architectural Sketches" and not
"Architecture Models"?

- Scott
Practice Leader Agile Development, IBM Rational
http://www-306.ibm.com/software/rational/bios/ambler.html

Refactoring Databases (
http://www.ambysoft.com/books/refactoringDatabases.html ) is now
available.

_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev



Whilst this email has been checked for all known viruses, recipients should undertake their own virus checking as Xansa will not accept any liability whatsoever.

This email and any files transmitted with it are confidential and protected by client privilege.  It is solely for the use of the intended recipient.
Please delete it and notify the sender if you have received it in
error. Unauthorised use is prohibited.

Any opinions expressed in this email are those of the individual and not
necessarily the organisation.
     Xansa, Registered Office: 420 Thames Valley Park Drive,
     Thames Valley Park, Reading, RG6 1PU, UK.
     Registered in England No.1000954.
     t  +44 (0)8702 416181
     w  www.xansa.com