There is no "right" or "wrong" way to build composite applications. SharePoint offers many different tools and techniques that may be used to achieve the same result. It is often difficult to know which technologies to choose, or where to start.
Regardless of the specific details of the particular composite application that you wish to build, you should seek to apply a consistent methodology and approach. This section describes my recommended approach to building composite applications. Before attempting to build a composite application, ask yourself the following questions:
Is the problem simple and well defined?
What are the risks if my application goes wrong?
Who will use my solution and what roles will they play?
Has somebody else already built a solution to my problem?
Do I have the necessary time, skills, and resources required?
Should this solution really be built without code?
How can I test my application to be sure that it works?
The answers to these questions will help you decide if and how you should build your application. When building your application, don't expect (or even try) to get it right the first time. Create prototypes, test them, and get feedback until you have created a composite application that does just enough to solve the problem.
No one has ever successfully built a composite application for a business problem that they didn't understand. If there are bits of business process, rules, and logic that are unclear, then try to resolve those questions before you proceed. If there are a number of suitable options, then build simple prototypes to refine your ideas as you proceed.
The most successful composite applications are the ones that really don't do very much. Simple, well-defined business problems lead to successful composite applications. Complicated business processes with many variants are impossible to build. Simplify processes before trying to automate them and don't try to cater for every possible scenario.
Before embarking on any composite application development, consider the importance of the application to the business, particularly the risk and impact on the business should it all go wrong. Complex, high profile, high-risk projects are not suitable candidates for composite application development. Don't try to build them this way; you are just setting yourself and business up for failure.
Always think about who will use your solution and what roles they will play. For example, will everyone be allowed to see all the documents in a site? The answers to these questions will enable you to create the right functionality and inform the security model that you will need to apply to make sure people can do only what they are supposed to do in your application.
The best composite applications are the ones that you never build. Why reinvent the wheel if someone else already has already created a solution to your problem? Start by opening your favorite search engine. Look for blogs, articles, and forum posts that might help. Check if someone has created a Sandbox Solution that you can download and install. Do some research to see how others have tackled your problem and consider purchasing third-party products or toolkits before trying to build your own.
Note
SharePoint 2010 allows Power Users to upload custom applications without having to ask permission from SharePoint administrator. These applications run in a sandbox that restricts what they can and can't to do on the server, making sure they can't do any damage, hence their name Sandbox Solutions.
This book is all about giving you the skills to build composite applications, but do you have access to SharePoint and the power to make the changes you need? Are the right licenses in place to give you electronic forms and business intelligence capabilities? Do you have the necessary time to devote to creating the solution? If the answers to these questions are no, then you are probably on the road to failure.
No-code applications are an attractive proposition, but it is important not to make the mistake of rigidly applying a "one size fits all" approach. There are some applications that should not be built on SharePoint and others that should not be built without code. It is like cutting the grass with a pair of scissors; you can do it but you really shouldn't. Some problems that are very hard to achieve in the "no code" world are very simple to solve with the introduction of a little code. If you have SharePoint administrators, designers, and code developers at your disposal, then use them. You will invariably come out with a better solution.
One of the biggest mistakes I see Power Users make is that they fail to test their applications adequately. When you build a composite application, you are still developing software (albeit without writing any code). You must plan to test your application thoroughly. Of course, you should test that your application does what you intend it to do. Ensure you test all the roles that you have identified and make sure you log in as different users to ensure that the security model you have implemented is working correctly.
Beyond this, you should expect that you will have made mistakes when building your application. Create different scenarios that test your logic thoroughly. Never underestimate the ability of your users to throw rubbish data into your application and to use it in ways that you don't expect. You need to repeat your testing each time you make major changes. Each time you add new functionality into your application; ask yourself "how will I test this?"
Composite applications are never "right first time" nor are they meant to be inflexible unchanging beasts. Composite applications can be expected to change over time, being constantly changed and tweaked as business rules change and processes evolve. The "no code" rapid development tools that SharePoint provides help us in changing our composite applications as we go, providing a level of flexibility that is impossible to achieve with traditional code-based applications.