Many planning considerations will impact your decision to create one or multiple Microsoft Office PerformancePoint Server 2007 applications. The primary consideration is determining how much of your metadata and business object definitions will be shared. While multiple applications are more scalable, each application can be thought of as an independent container for your data and data cannot be shared across applications.
PerformancePoint Server also only allows one calendar per application, so if your company has multiple businesses on different calendars, two applications must be built to accommodate this organizational structure.
Use care to ensure your application calendar will accurately match your business processes, as the calendar cannot be modified later without creating a new application. Note that custom calendar views can be created to display only certain time frequencies included in your calendar, such as month and year.
The following calendar formats are commonly used in PerformancePoint Server applications:
Gregorian calendar or variation All months follow calendar months.
Gregorian calendar Months end on same day every month, but the end day differs from the last day of the calendar month.
445 pattern Months in a year contain weeks as follows: 4 weeks, 4 week, 5 weeks, and then pattern is repeated. Fixed or variable year end.
454 pattern Months in a year contain weeks as follows: 4 weeks, 5 week, 4 weeks, and then pattern is repeated. Fixed or variable year end.
544 pattern Months in a year contain weeks as follows: 5 weeks, 4 week, 4 weeks, and then pattern is repeated. Fixed or variable year end.
13 A year contains 13 equal periods. Fixed or variable year end.
Related questions to consider when planning your application's model sites is whether your organization has centralized processes and data and if you have several divisions with very different business types within your organization.
If your organization is centralized, multiple model sites may not be necessary. However, if your organization is decentralized, but processes are consistent and data reported to corporate is normalized across the businesses, you could have multiple model sites that summarize data at the corporate level.
However, if your organization is not centralized and data is not consistent across divisions, you may need different model structures for the dissimilar parts of your organization. To accomplish this, you may need to create multiple applications.
Separating the corporate root model site from divisional or business unit model sites also enables user- and role-based access to data. This is important in maintaining corporate control over assumption models used in the planning process.
Security considerations can also impact site planning decisions. If you would like to specify varying permissions for members of the Modeler role, this can be accomplished by creating model subsites and setting permissions at the model site level.