[Anthill-pro] Thinking enterprise

[Maciej Zawadzki]

Curtis,

There are several ways to go about this, as the granularity level of a
project is really up to you -- AHP does not actually impose a
granularity level of its own.

The easy and more natural way to structure AHP project boundaries is to
align them with your source code boundaries.  So lets assume that you
have an application (Order Entry App) that produces an EAR file which in
turn contains Customer.jar and Order.jar and OrderEntry.war.

If the source code is structured like below
/OrderEntryApp
  /source
    /Order
    /Customer
    /web

where the source for Order.jar and Customer.jar and OrderEntry.war is
all part of one source project, then the simplest thing to do would be
to have a single AHP project for the entire source project --
OrderEntryApp above.

But, if the source is structured like:
/Order
  /source

/Customer
  /source

/OrderEntryWebUI
  /source

then it would make sense to have a separate AHP project for each source
project.  If you do this, then you could set up dependencies between the
project in AHP.

There are pretty big implications of the two different ways of laying
out project in source control.  In the first example above, since the
project is rather monolithic, this implies that the Order.jar or
Customer.jar that are part of that project could not be reused on their
own -- this is because they are not being built or released on their own
but rather as part of a larger app.

In the second example, each project (Order, Customer, OrderEntryWebUI)
could be reused on its own by other projects -- perhaps you have another
application that needs to make use of the Customer component.  In this
scenario, you would assemble all the pieces together using the
dependency management features of AHP.  So, in AHP, each one of the
component projects (Order, Customer, etc.) would have its own lifecycle
-- build, unit test, functional test.  Then, you would have an assembly
project that would use dependency management to assemble the components.
 The assembly project would have its own lifecycle -- integration build,
integration test, etc.

Another implication of having finer grained projects with dependencies
is that broken code bases have less disastrous consequences.  Take the
monolithic example above -- if we assume that each component has 10
developers working on it, then there are 30 developers working on the
monolithic project.  If one of the developers commits code that causes
the build to break, then all 30 developers are impacted.  But, if you
have fine grained project boundaries and you use dependencies, then
you'll have 3 project each with 10 developers.  A broken build would
then impact only 10 developers and not all 30.  Yes, there is still an
impact of a broken build, but it is not devastating.


When it comes to configuring user's visibility of projects, you're right
that currently you can use the security system to limit which projects
the user sees.  This does mean though that if you have 100's of projects
a user with visibility to all of them (such as the admin) will have a
lot of info to sift through.  We are adding some features in 3.2 to make
at least some of this easier.

Regards,

--Maciej