[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The current thinking on the next LedgerSMB architecture.


Great start on the goals document.

Beyond the currently ongoing bug-fixing and addition of minor features, you're 
basically saying, "let's make something entirely new." There's an existing 
code base, but once you make the decision to scrap it and re-implement the 
entire thing, the primary purpose of the existing code base becomes:

* Provide a list of features that are to be implemented (the new code should 
provide the same features as the existing code), and

* Serve as an initial validation test document (the new code should provide 
the user with the same abilities).

Of course, the above isn't entirely true: the existing code does a couple of 
things wrong, and should do a couple of things more. However, these 
modifications might be viewed as a separate task compared with the task of 
re-implementing the code.

So, I propose that now you've decided to re-architect and re-implement 
LedgerSMB, there are a few tasks that should be performed first in order to 
guarantee a successful re-implementation:

1. Identify and list all of the requirements for the new software. Obviously, 
most of the requirements can be gleaned from the current code, so this is (at 
least compared with requirements development in general) a reasonably trivial 
task. It may make sense to develop the features into technical requirements. 
(By "developing requirements" I mean turning statements such as "a heavy 
door" into technical specifications such as size and weight.) It might make 
sense to divide the features into "current" and "future" features.

2. Describe the architecture; more specifically, identify which major 
components the software should be split into. Also, make sure to identify 
major algorithms and major data structures. Agree on an interface strategy. 
Agree on a code strategy. (Your goals document already makes some initial 
thoughts.) When there are multiple solutions, make sure to list all of those 
that make sense and explain why you deselecte those options.

3. Allocate requirements to the components: for each requirement, determine 
which component is responsible for providing this particular requirement. 
This is basically where you start requirements traceability: for each 
requirement, it must be possible to show that the architecture will cause 
this requirement to eventually be implemented. It may sound like a difficult 
task, but a spreadsheet is really all it takes as long as you have version 
info in your requirements and architecture documents.

Next comes detailed component designs, but let's wait with that. :)

As an example of deselecting options, your vision statement states that you'll 
put lots of functionality into the database. It might be worthwhile 
explaining why this is such a good idea that it justifies the difficulties 
that will arise if LedgerSMB is to be used on servers running, say, MySQL, 
Oracle, or Microsoft SQL Server instead of PostGreSQL.

Another example would be the choice of programming language. Perl is powerful, 
but it's also very code monkey friendly (meaning any idiot can code in Perl, 
and many do). Choosing the same programming language as the poorly coded base 
application might tempt implementers to copy and past bad code sections, not 
realizing that the sections should be rewritten. It might be a good idea to 
summarize why you selected Perl for this particular application. You mention 
that Java and Python have been discussed, so it might be a good idea to 
summarize this discussion in the architecture document.

My two cents (debit LedgerSMB, credit time).


> Hi all;
> This is an attempt to summarize for the record our current architectural
> approach.  If there are no concerns, comments, are clarifications needed, I
> would like to put it on our web site.

Attachment: pgpotEPMVAsWP.pgp
Description: PGP signature