Lately, there has been a lot of hubub around the Federated Portal. As NetWeaver has evolved the landscape considerations have changed in order to support rapdily changing IT atmospheres and to resolve system dependencies. Therefore, SAP introduced the Federated Portal to solve a lot of challenges. There is a PDF presentation Ron Silberstein did on this topic located here: System Landscapes. The podcast to go along with this presentation is located: Podcast.
Should I Federate?
You may think this is a very difficult question. Lots of customers have different IT landscapes and different requirements. Ultimately, when making landscape decisions, I think a Federated Portal environment makes the most sense. For the BI guys, you probably know that reporting on a multiprovider makes the most sense. This is because this provides an abstraction layer and allows you to be flexible with your data models. Federated Portal does this with landscapes. You now have an abstraction layer (your consumer portal) which allows users to access all their information needs. From a technical layer, there can be multiple Portal environments underneath that support different applications (ie CRM, BI, etc...). This will decouple the dependencies from all these different systems. Also, you can be flexible on where the content resides.
Can I Federate Later?
You can, but it'll cost you. If you federate before you build a lot of content, the migration is a lot easier to a federated portal environment. You may have content from multiple BI systems on your Portal and you may need to split this out to multiple portals and then create a consumer portal and user assignment to roles on your producer. If you continue developing now without federating, you're just making more work for yourself later on...
Here's a scenario. You have one BI system, one ERP system, and one Portal today. You decide not to federate. You start building content, and this content from BI is deployed via the Portal. You are also using MSS/ESS which is deployed to this same Portal. Now you have a CRM system and need to deploy content to this Portal. You are going to run into system limitations on versions of the software that are supported for CRM (particular BI and Portal releases).
Now, let us suppose you federate today. You have one BI System, one ERP system, and two Portals (one consumer and one producer). All your users access content through the consumer portal. If you decide to add CRM, it can have it's own portal system which you can just attach to the consumer. You don't need to worry about migrating content or system dependencies. Having this now allows the least disruption because the consumer will always be the entry point for the business, and this will always be there.
What about TCO?
You may think that adding this additional NetWeaver box increases TCO, but in reality, it does not. If you think about total TCO, this abstraction layer allows you flexibility and saves you time when making changes. Thus the investment in hardware for this one box will be far cheaper than the manhours spent building, re-building, migrating, and integrating content.
Ok, I'm federating. Where do I put what?
My philosophy on this is pretty simple. Basically, when designing your landscape, I try to keep ALL application processing off the consumer portal. The consumer portal provides a single point of entry as well as a unified UI for your end users. These are the only things I run on the consumer. Each producer environment is pretty much a java application processor. The producers are where the work gets done. This way, if you have many xApps analytics that require lots of java processing power, you can have a producer java runtime just for those applications.
Therefore, I do not recommend uploading content to the consumer and running it there. This will create application processing on the consumer and kills the advantage of having this abstraction layer to separate out application processing. Federated Portals offer many different options such as remote role assignment, content copy, etc... I suggest using remote role assignment whenever possible as this will ensure you are integrating with your producers by keeping the content on the producers.
What about Knowledgement Management, Collaboration, and Universal Worklist?
See OSS NOTE 969040.
Summary
Tried to keep it short and simple. Sometimes these discussions get long. Just remember, federate for abstraction and application processing on producers whenever possible. That's the key to a good federated portal network.
