[FoRK] Re: Software architecture in the real world

Ken Meltsner meltsner
Mon Sep 19 13:24:14 PDT 2005


On 9/19/05, Corinna <schultz at harlingen.isd.tenet.edu> wrote:
> This is interesting... I've only ever been involved in small projects, where
> the process is pretty informal.
> 
> At what point do the IT/builder/implementer people become involved? Would
> you say that the process is more of the traditional, do-it-all-in-advance
> kind of approach, or more of the iterative/refine-as-we-go kind of approach?
> (Somewhere in-between, I would guess :) )   How much documentation do you
> end up with?  Is maintaining the documentation through the project a
> challenge?

n practice, we put together the entire "solution architecture"
document twice (thank goodness for word processors!) -- once with
relatively limited detail as a proposal and once with "complete enough
to install" detail after the proposal has been accepted and the
project started.  After the complete spec is finished, we track change
requests and resulting revisions throughout the life of the project. 
The goal is to have the specification match what was actually
implemented, along with a history of design and deployment changes.

The architect first  gets involved when the sales rep and the customer
need to figure out which pieces of the problem should be tackled with
our software (and which software -- last count had us with ~1400
products, although nowhere near that in terms of commonly used
products).

We've trained some of our pre-sales staff to gather the initial
business requirements so that the architect can concentrate on the
mapping of business reqs to specific solution requirements.

He or she stays involved through the sales process -- determining how
many licenses are needed, for example, and the solution architecture
overview (SAO) document becomes part of the formal proposal made to
the customer.  If the proposal is accepted, the same architect, we
hope, fleshes out the document with details, including test plans and
implementation instructions.

After the specification is accepted, the architect keeps an eye on the
implementation effort, keep track of and responds to customer
requests, and probably performs dry runs of the test plan before the
customer starts final acceptance testing.

This is mostly the direct opposite of eXtreme Programming techniques,
where you concentrate on framing the entire application and then you
go back and fill in the gaps and refine the structure.  Given our
heavy use of packaged software, this makes more sense, I think.

 In my opinion, you also need a more formal structure when you're
working with customers rather than fellow employees;  you have to
trust one another or the project is doomed, of course, but the
contracts and documentation are there in case something goes wrong
like the customer being acquired.  You hope for the best, but plan for
the worst.  Iterative techniques like XP are great for facilitating
communication while reducing risks that you'll get the requirements
wrong, but there's always the fear that something big will go wrong
and someone will get in trouble.

Since we're also interested in using non-CA staff in many projects, we
now have at least 3 organizations involved, and the need for formal
project documentation increases geometrically.



More information about the FoRK mailing list