Widely awaiten (by me 
) Analyst refactoring did not happen. The problem of having a non-scalable yet very comfortable tool for creating calculation models and analyzing was solved not by enhancing the tool. It was solved by marketing, not R&D.
Now Analyst is a “developer tool” and all budgeting process should go through a list of Contributor Applications (APs i’ll call them, tribute to James). Those AP’s are connected via Administration Links, which are scaled using Contributor apps servers, and that’s great. And using ASP-macro(see previous posts) calls we can achieve totally Analyst-free budgeting process. All model changes are, of course, made in Analyst, but there is no need for it in day-to-day budgeting. We’ve recently created a test model for pre-sale purposes based on these ideas. It works.
Yet some problems arise.
Planning consists of two processes:
1. Data Input
2. Data Analysis
Contributor is very good for data Input.
1 formulas are hidden to end-user
2 links are executed automatically and hidden also
But when it comes to Analysis are these attributes good? A rather rhetorical question.
Moreover — no Drill-Down in Contributor! So, looking at P&L we cannot define where this or that data came from. Export data to Analyst and do your drill-down there? Not a chance in our non-Analyst future models.
Analysis in Contributor is currently reduced to OLAP-style slicing&dicing, data reorientation and break-back.
It is crucial for Cognos to somehow introduce drill-down into Contributor.