Dividing up your team

One major problem with most projects I've seen is we divide Java development work per use case. This is not ideal especially with Curam (though you can apply the same with other projects). It also hinders reuse and commonality because everyone is doing one use case at a time rather than seeing a broader picture by working as many use cases as possible. It also allows them to refactor mercilessly as needed. Here are the development teams that should be formed for Curam development. Please note that these teams are very dynamic, so people move between them as need (or want arises). This only specifies the application development group, you still need BAs, DBAs, Change Management, Infrastructure groups as well. I have broken apart this blog entry into different entries so this one won't get too long. User Interface These people are overly responsible for the general look and feel of the application. They need to work closely with the BAs to ensure things work correctly. They work with the HTML guys to help tweak the CSS files. This group is the user interface expert team of the application, rather than an outside group, because someone outside may want to tweak Curam in a way that is different from the core application and would involve a lot of tedious work trying to make the core Curam application conform to some other person's view. They also know what fields are mandatory and how they should be rendered. They are also responsible for automated integration tests with tools such as Selenium or Rational Robot. Entities They are the meat of the application (where all the persistence gets done). They work with the BAs that know how things are supposed to be logically represented in the system. They also work with the DBAs to make sure that what they are doing is sane and efficient. These people are responsible for providing the necessary interfaces to the entities. Although they teach you how to write Service Layer code and Entities as separate things in the Curam development courses, I do not recommend that approach wholeheartedly as it will cause your developers to write tedious transport code. You should move as much of the entity logic within the entity (this can be seen with some of Curam's core code) and move higher level functions that involve multiple entities into the service layer. Since these people know the low level entities well, they would define the necessary interfaces on the service layer as well. I thought about putting this responsibility separately, but it didn't really make sense to have a separate group that does this since all the experts in the domain are already in the group. They also deal with DMX and code tables as well. Some people in the team also work with or ideally work in the BA team to transcribe the code tables as well. Service layer There responsible for unifing the layers (connect facade implementations to service layer or entity interfaces). They are basically pushing data around. But since we moved a lot of logic to the entities they don't have to do much tedious work. They are also responsible for creating deep or business level validations for the data that is retrieved from the facades since they would be creating the InformationExceptions for the system. These validations were not part of the Entities group to make things easier for the entities group to focus on their own work, but the entities do perform the business level validations, they just throw AppExceptions directly rather than going through the motion of setting up the informational messages. Workflow They deal with creating the automated activity code and work with the BA team who knows how things are supposed to flow. There are people in the group that are closely tied with or ideally work in the BA team that codify the workflow into Curam. Rules They deal with creating the RDO loaders code and work with the BA team who knows how things are supposed to be decided. There are people in the group that are closely tied with or ideally work in the BA team that codify the rules and rate tables into Curam. Although ideally the rules engine can be used to perform business level validations, hold off on it. Setting up rules is not trivial and takes a lot of effort. But stub the validations to a separate method so you can invoke the rules engine as needed later on.