Hi,

who has hands-on experiences with migrating old HOLOS applications to the
Business Objects platform?
Are there some lessons learnt to share? Typical problems which have emerged?
Or does anybody have strong preferences to migrate to MS Analysis Services
instead?

Any serios feedback is welcome!

Michael

Michael,
Holos to BO? to me its wrong choice. What kind of application is
running on Holos? How complex the calculation and the data size?
Currently I'm evaluating
MS Analysis Services, Cognos and Essbase.

MS Analysis Services - is cost effective & powerful but lack of
multiple hierarchies, unbalanced hierarchy (I believe not efficient),
measures in hierarchy, reporting tool (client)(we are not favor of
3rd party tools as its difficult to coordinate with many vendor
products).

Cognos Powerplay- Has a complete suit of products, including reporting
tool. OLAP functionality better than MSAS but still lack of
hierarchical measures, complex calculation support.

Essbase - Has an excellent OLAP functionality, the dimensions almost
treated as like Holos (there is no measure dimension, Accounts
dimension is an option). Has excellent calculation and aggregation
functionalities. But expensive, I'm still not convinced with Analyzer.

Any suggetion on my comments.

SKS

"Michael Weimar" <miki_wei2000 (AT) yahoo (DOT) de> wrote

I think you should also evaluate a few other things

- how do you think these products would be in three years time ahead?
Have a look at Microsofts next generation of MSAS in SQL
Server 2005. Their Analysis services is now a nearly 4 year old
product. There are very many improvements, enhancements and changes
in this edition.
What have the vendors been doing og further development for the
past years? It is not a good idea to buy another Holos product that
is close to the end of the product life-cycle.

- Application size/type. This is often a very neglected evaluation
criteria, as some of the products around does not fit very
well into all types of applications. as an example Hyperion
Essbase is particularly strong on financial types of applications
with often moderate amounts of data. MSAS does integrate better
with a more general datawarehouse architecture, and is often
used in more general datawarehouse applications
BO is in my opinion not a very well suited product for
financial type of applications as it has quite limited calulation
functionality, however it work well as a database
reporting tool.

- Enduser committment.
Microsofts MSAS is a great product for IT-professionals
however more diffecult to program for many endusers than Essbase.
Who is supposed to maintain your solution?

MSAS can handle multiple hierarchies, and unbalanced hierarchies
in a number of different ways:


Both unbalanced and multiple hierarchies:

1) Use balaced hierarchies and create a (star-type of scheme)
of a multiple hierarchy. If you want it to be un-balanced
there is an option to hide members with the same name as
their parent in the set-up of the hierarcy.
Many end-user tools wil recognise this and show the dimensions
as they were unbalanced. It works nice -
I tried it on a large organization structure
over several countries with separate side-calculations
of specific type of organization units. In order
to create the side hierachy create two or more leaf-members of
the units you want to create a multiple hieracy on, and
make the side hierarchy as you like.

2) Another method that works is to create several alternative
dimensions where each represent your alternatve consolidation.
MSAS is quite machine/storage efficient so creating many dimensions
in a model does not affect performance in the same manner as
Holos/Essbase does.

Unbalanced hierachies only:
Use the recursive (parent-child) option to create unbalanced
hierachies
It works nice.

Measure dimension in Essbase:
Essbase does not store data in database-format type of tables - and
subsequently does not need the measure dimension.

Re
Bjørn T





skalyan (AT) singnet (DOT) com.sg (SKS) wrote in message news:<50f9a5fe.0405230751.5e9114e1 (AT) posting (DOT) google.com>...

BO is not a real OLAP tool, but more a database reporting-tool with
som OLAP capabilities, and is very different from HOLOS.

In order to use BO you need to program your SQL database as
a star-scheme model and index it for maximum query performace. The
OLAP fuctionality works best if you download a part of that database
to what is refered as a BO micro-cube, or a report-file. When I used
the product some years ago it worked best with report files less than
about 10 MB in size, so this may indicate the maximum size of the OLAP
database.

The reports can be furter changed by slice-and dice functionality,
filtering etc by endusers, in both a WEB and a client tool
environment. The Client version of BO does not support any real
drill-down functionality. BO works best with reports with a quite
fixed format end little ad-hoc end-user capabilities.

BO can do some calculations, however these are more like typical
database functions and do not expect the same rich functionality as
Holos have.

In some cases BO can substitute HOLOS, while in more advanced type of
applications such as financial reporting BO will probably not work
wery well.

RE
Bjørn T


"Michael Weimar" <miki_wei2000 (AT) yahoo (DOT) de> wrote

"SKS" <skalyan (AT) singnet (DOT) com.sg> wrote

I definitely wouldn't get too hung up on wanting to buy the whole
solution from one vendor. This was necessary with Holos, as no other
vendors could or would build front-end tools for it, but both Analysis
Services and Essbase are designed with open APIs that are well supported
by third parties. This means that you really can freely choose to use
third party products with these servers, and the best of these products
will exploit the server better than the server vendor's own tools.

This openness is one of these reasons that these servers are around
today and doing well, whereas Holos, despite being more functional than
either, is dead. When Holistic Systems/Seagte did a poor job of
supporting Web deployment, all Holos users were prevented from
exploiting the Web; conversely, though Microsoft Office is not
(natively) a good Analysis Services client, plenty of third party
vendors have filled any holes left by Microsoft.

That's why you can choose from good front-end products from
IntelligentApps, MIS, Panorama, ProClarity, Temtec, XLCubed and many
others. Even though Microsoft may, in time, fill some of these holes
(eg, with its new free Excel add-in), the third party products are
likely to stay in front.

Bjørn,
Thanks for your comments.

I don't believe that Essbase, Powerplay or BO will follow Holos in the
near future. In my opinion Holos is a good product (so flexible but
needs extensive programing) it could survive if it didn't undergo many
M&As. Moreover, the marketshare for Holos is less than 2% but Cognos,
Essbase, and BO has a reasonable marketshare.

I do agree with you MSAS is doing well and the market share is growing
very fast. Its strenght is the price, its DTS and data storage not the
OLAP. I'm still not convinced with its OLAP.

1. creating several alternative dimensions/more leaf members doesn't
affect the storage as MSAS has a efficiant storage. But definitely has
an impact when I bring the cube into memory for a full calculation or
retrieval.

2. Parent Child dimension doesn't work when I want to go for ROLAP.

Where as Essbase/Cognos are constantly adding new features such as
Web, XML, MDX, ETL etc.

I really like Essbase's member properties such as UDA, Attribute,
Expense reporting, Time Balance, Implied shared members, shared
members etc. Multiple, Ragged, Balanced or Unbalanced hierarchies are
natural sopport dont need WORK-AROUNDS. Member properties can be
created/modified during dynamic dimension creation. Well supported
calculation and consolidation functionalities.

Its very easy to sell the Essbase application to Finance Users. But
Essbase is expensive, needs extra programing for automation and
administration. Web is not as colorful as Cognos.

BTW I MSSQL 2005 looks promising on the DTS but OLAP looks same. Hope
in four years time we all work for MSAS.

SKS



bti (AT) ementor (DOT) no (Bj?rn Tingstadengen) wrote in message news:<f07399d2.0405240149.36df155e (AT) posting (DOT) google.com>...

Hi,
your comment will be appreciated.
My accounts dimension(Holos there is no measures) is as follows

Margin = Total Revenue - Total Expense

Rev/Exp Ratio = Total Revenue/Total Expense

I know in Essbase this is not a problem to bring them in to a
hierarchy, drill-down. In Holos we use Margin in Hierarchy, the Ratio
as rule. Drill-Down has been achieved by hierarcy or based on rule.

If I want to bring this to MSAS or Powerplay, Firstly I need to bring
the Accounts Dimension out of the measures dimension have a new
dimension called Accounts. Then put my
Senario(Actual,Budget)dimension. Isn't something odd? How the
Intelligent Time trend (YTD,PTD) is going to work? Is it possible
for a Rule Based drill-down.

Please help.
Thanks.
SKS



bti (AT) ementor (DOT) no (Bj?rn Tingstadengen) wrote in message news:<f07399d2.0405240149.36df155e (AT) posting (DOT) google.com>...

Hi,
your comment will be appreciated.
My accounts dimension(Holos there is no measures) is as follows

Margin = Total Revenue - Total Expense

Rev/Exp Ratio = Total Revenue/Total Expense

I know in Essbase this is not a problem to bring them in to a
hierarchy, drill-down. In Holos we use Margin in Hierarchy, the Ratio
as rule. Drill-Down has been achieved by hierarcy or based on rule.

If I want to bring this to MSAS or Powerplay, Firstly I need to bring
the Accounts Dimension out of the measures dimension have a new
dimension called Accounts. Then put my
Senario(Actual,Budget)dimension. Isn't something odd? How the
Intelligent Time trend (YTD,PTD) is going to work? Is it possible
for a Rule Based drill-down.

Please help.
Thanks.
SKS



bti (AT) ementor (DOT) no (Bj?rn Tingstadengen) wrote in message news:<f07399d2.0405240149.36df155e (AT) posting (DOT) google.com>...

skalyan (AT) singnet (DOT) com.sg (SKS) wrote in message news:<50f9a5fe.0405240755.3af07d7d (AT) posting (DOT) google.com>...
As the different OLAP products behave somewhat different I think it is
important to "de-program" yourself in order to make the solutions
optimized
for the particular OLAP database you are currently using - and do not
try converting your old database as an exact copy in the new
environment which
does not always give a good solution (I tried that once converting the
old System-W to Holos).

As an example I think it is better to use the MOLAP option in MSAS
rather than ROLAP which is more Holos-like.

In MSAS and Essbase you definately need the accounts dimension.
In MSAS I would not recommend you to use the measures "dimension" as
accounts as more then an input value (member or column) or scaling
factor($, 1/1000 etc) to your database for several reasons.

One reason is that a "stretch-table" database layout with one column
for each account is not very elegant. Other reasons for using the
account dimension is that, the measures dimension has limited
drill-down functionality, and third; the measures dimension is (I
believe) limited to 1024 members.

In MSAS there are two different versions; Enterprise and standard
adition. If you are supposed to create more advanced applications like
financal reporting I think you definately need the Enterprise edition
for two reasons:

- Calulated members
- Partitioning your database

When you create a hierarhy in in MSAS Enterprise Ed you can apply
rules to any member of the hierarchy using the calulated cells option
(rater then calulated members), so if you have (as an example)
"Rev/Exp Ratio" as the topmost member of the accounts dimension you
can easily drill down into the next two members revenue and expences
if you design your hierarchy to look like that.

One nice featuere in Essbase is the predefined account types and
options such as currency/non-currency, balance vs profit type of
accounts etc. In MSAS 2000 you need to consider these things manually,
by defining additional colums in your database dimension table. When
you create your account dimension you can add in these columns as
member properties (which is quite important..) These can be used later
in calulations in order to automatically handle features like
currency-conversions vs statistics, year-to-date calculations etc.
Here is a typical sample account dimension table to make it all work:

- AccountNo Accountnumber
- AccountParent The next Account level
- AccountDesc Acccount Text Description
- AccountDesc2 Alternative Text Description, You can have several
of these
if you need the text in several languages.
- AccountSort The Default Sort order for your accounts. It is
most
useful in aggregated account-levels like "total
expence" where you have no natural account key
order.
- IsCurrency To sort out statistics accounts when recalulating
to different currencies
- AccountType To differ betwen cost/income and balance items
during
year-to-date, total year calulations
- AccountType2 Alternative calulations...
- AccountRollUp Roll-Up formula (+, -, ~ (none))
Using the ~ key you can create empty folders to
stack in
groups of accounts, for example statistics/metrics
in
a similar way like Essbase
- AccountMDX Alternative advanced MDX Calcs

You need of course also a Scenario dimension usually with the members
Actual, Budget, Variance (If you use Calculated Cells) and Forecast.
I usually split the fact table into three partitions (one Budget,
another Actual and a third for Statistics/Metrics). Regarding MSAS in
SQL Server 2000 the only predefined statistics method for forecasts is
linear regression. In SQL Server 2005 you will have serval other
options.

I also split the time dimension into 2 or preferably 3 dimensions; One
representing Months or periods, a seccond representing years and a 3rd
representing time-length (period, year-to-date, full year). This
approach usually fits most reports, and goes fairly well with
Reporting-services, office OWC klients and Proclarity as front-end
solutions.

Hope this helps
RE
Bjørn T

Hi Michael

Something else you could consider, ofcourse, should be the Oracle
Database OLAP Option. You can use this with BO as the front-end UI if
you like to use BO tools, and/or with tools from Oracle if you like to
get everything from one vendor, and/or from a growing list of other BI
tools and applications available for Oracle OLAP.

The multidimensional capabilities of Oracle's integrated OLAP engine are
a superset of those from Oracle Express Server - for many years one of
the more credible competitors to Holos which, like Express, had a good
reputation for its calculation sophistication and flexibility.

To pick up on some of the features/characteristics 'SKS' mentioned
below, I think you'll find that Oracle OLAP can handle things that you
expect including :
* multiple hierarchies
* unbalanced/ragged hierarchies
* measures either as members of a dimension or as seperately dimensioned
objects
* complex calcultion support across multidimensional objects and along
dimension axes - including sophisticated modelling within dimensions,
hierarchical and time series calculations and so on
* very flexible aggregation and allocation capabilities
* and all the security and scalability/manageablity/availability etc
features available as a direct result of being part of Oracle Database.

Hope it helps, Kevin (@ Oracle).

SKS wrote: