Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [epf-dev] Request for discussion: Redefining Architecture Content for OpenUP/Basic 1.0

Sorry Mark but I will not be habble to be at the call..

I agree with most of what you wrote.... just some comments:

* I would write "just enough words" after producing and testing the software ... just to remember key arch decisions that could be useful for the next iteration

* It also sounds that software is always being from scratch ... maybe the arch team could also make use of other software developed in the open source communities ... we could add some steps for it ?

Ana



Mark.Dickson@xxxxxxxxx wrote:

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
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev


Back to the top