Some tips on using WC-SF with existing web applications.

• To minimize the amount of code re-writing and modification, try to wrap existing business logic in CWAB (Composite Web Application Block) services and store them in business modules. This will not only save you some time, but it will also increase the testability surface of your solution because you will be able to replace the services with mock implementations.
• Encapsulate shared components like security and data access providers in global services (you can place them in foundational modules).
• Don’t try to migrate the whole solution to use the patterns suggested by the factory at once, do baby steps. Start implementing small new areas with the WC-SF approach first, one at a time, and analyze the results. Once you and your team feel comfortable with the factory, start migrating existing items if needed.
• If your application contains areas that mainly perform simple CRUD operations, you might want to move them to one or more business modules and to avoid using the module controller for them. Module controllers follow the Application Controller pattern (see the WC-SF docs for more information), which might not be the best solution in these scenarios because usually there is little or no page flow / business logic in them. In these cases, you could wrap the existing business-specific data access logic in module services and consume them directly from your presenters.
• Customize the guidance package according to your needs. One change you will find useful for existing solutions is to update the view’s template to use your own master page instead of the default one that you get when using the Web Client Solution template. You can find the template in WebClientFactoryPackage\Templates\T4\View\View.aspx.t4.

Ashwin Mallur Parthasarathy Software Factory WCSF Web Client Software Factory

Everytime I sit to document an architecture, I am confused and take some time to start off. This time I sat to figure out why I was doing this everytime though I had done it N times before. The answer I got was that I was pondering about the target audience, the representation to be used etc. Finally I think I have the answer - “Don’t worry about it”�
�
When you start documenting the architecture, consider both technical and non-technical audience into consideration.  The first 1-2 sections of the document should address the non-technical group. Rest of it can be hard-core technical terms/concepts.  Now you may ask me why the non-technical group should be considered. This group consists of senior level managers, program managers etc who would like to validate if all their requirements have been met. Once they give a go-ahead, the tech team takes over to inspect the thought process under a microscope.
�
So here is the structure I found and liked:
1. Target audience for the document
2. Terminologies used
3. References - (Mainly your requirements/functional specification). If you are integrating with any external systems, refer to their architecture/design documents.
4. Non-functional requirements - Read through the requirements document and extract the non-functional requirements such as security, performance etc and list it here.
5. SAD structure (SAD - System Architecture Document)
6. Conceptual Architecture
7. Logical Architecture
8. Execution Architecture
9. Architecture Validation

Ashwin Mallur Parthasarathy Architecture & Design