There are many different ways to architect a Microsoft EPM solution based on Project Server 2003. When architecting such a solution many factors will have a significant impact on your EPM system performance that you must consider, such as hardware and software, as well as user-related issues.
When considering the final hardware architecture for your EPM solution, you also need to address questions related to scalability and reliability. Based on the answers to your questions you can start designing your EPM system hardware architecture.
When designing your EPM solution architecture, consider the factors discussed in the following sections.
Number of Users and Their Roles in Your Organization
Per user, your project managers will place the greatest load on your EPM system and the team members the lowest. However, as the number of team members increases, the load and impact of this team members group increases as well.
The reasons for these different load characteristics are explained by different roles project managers and team members play in an organization. Project managers need to create, edit, and monitor their project plans. For that they use the Project Professional client. On the other hand, a typical role of a team member involves some team collaboration on issues, risks, and documents, as well as actual task assignment progress submissions. To do that, team members use the web-based PWA client.
A typical team member's EPM system usage tends to be concentrated within particular time periods, creating sometimes significant usage peaks. The example of such a peak created by team members is Friday afternoon timesheet submission. If your process for timesheet submission defines that all timesheets must be submitted between 2:00 p.m. and 4:00 p.m. and you have 8,000 timesheet users to process, the peak EPM system load during that time can be significant.
On the other hand, typical executives and resource managers place a relatively low load on your EPM system. The reason is because their activities are generally spread across different times. It would be highly unusual to see a large number of executives or resource managers trying to access the system at the same time to do the same things.
Also, you need to distinguish between the number of total system users and the number of concurrent users. When you need to deal with system usage peaks, you need to determine the number of "concurrent" users and design your system architecture to be able to handle the usage peaks and not the average load. After all, ultimately it will be your EPM system users from the whole organizationproject managers, team members, resources managers, and executiveswho will determine through their personal experience whether the system performance is acceptable.
The Microsoft Configuration Planning Guide, Chapter 3, has a detailed discussion about identifying organizational requirements, including a discussion about estimating the number of concurrent users, project characteristics, and usage patterns. The Microsoft Configuration Planning Guide is available for download from http://www.microsoft.com/technet/prodtechnol/office/proj2003/reskit/default.mspx.
The collective experience of many EPM system implementers shows that you definitely do not want to be too mistaken when it comes to assumptions made about usage patterns, average size of your projects, current number of EPM system users, and future growth of your organization when designing the architecture of your EPM system. The EPM solution is a complex and sophisticated system, and the last thing you need to be concerned about on top of this technological complexity is having to deal with unfulfilled user performance expectations.
Your Projects and Their Characteristics
It is important to also consider the impact of your projects. Think about not just the number of tasks in your projects but also, perhaps more importantly, the total number of resource task assignments in your projects.
Many big projects stored in your EPM database may increase the processor load of the EPM solution servers.
When defining what a large project is, do not think only in terms of total number of tasks per project. Also consider the number of resources assigned to all tasks, the number of custom fields with formulas, and other task attributes such as baselines used.
Many active enterprise projects also require many EPM system database user accesses as well as many and frequent views publishing requests. Publishing projects takes up processor time on the server where you run the View Processing service.
Business rules and processes you design may often cause traffic jams. A classic example is when timesheets are due by 5:00 p.m. Thursday afternoon for everybody in your organization. What is the result of this business process? Most of your resources who are required to submit their timesheets hit the EPM system servers between 2:00 p.m. and 5:00 p.m. on Thursday.
Another example might be all enterprise project updates are due by 1:00 p.m. on Monday. Again, think about the impact of that business requirement.
All your project managers will need to update and publish changes for their projects between 8:00 a.m. and 1:00 p.m. Monday morning.
The most sensible way to deal with these peaks created by your business processes is to design the system for peak loads created by these business requirements and not average loads.
Feature Usage Across Your Organization
Some features available for your EPM solution users create big loads on the EPM system servers.
For example, OLAP cube generation creates a large processing load on the server running SQL Server 2000 and Analysis Services. Also, many timesheet users may create big peak loads.
Microsoft holds annual Project Technical Briefings. These technical briefings are usually held in Seattle during May or June each year. It is worth considering attending the next Project Technical Briefing for any IT professional or business analyst involved in designing, architecting, planning, or implementing a Microsoft EPM solution. Microsoft also produces a DVD from each Project Technical Briefing that is loaded with useful information, such as all presentations and keynotes from this three-day conference. It is strongly recommended that you get your hands on the DVD produced from the Project Technical Briefing 2004. You can review the last Project Technical Briefing agenda at http://www.projecttechnicalbriefing.com.