Question about component dependency related to the BI (Business Intelligence)

[Jacopo Cappellato-3]

Hi all,

I am reviewing the stuff I did some time ago in the "bi" component  
(Business Intelligence, in specialpurpose) and I would like to start  
to clean up/enhance a few that prototype.

As a first step I would like to separate the lower level services  
(like the generic ones that are used to translate operational keys  
into olap keys) for BI from the ones related to specific applications:  
all the artifacts that are application specific (entities, services  
and ecas) will be moved to the proper component.

The doubt I have is this: since the higher level component will use  
the lower level services defined in the specialpurpose/bi component,  
this will create a bad dependency from applications to specialpurpose...

What is the best way to fix this? Move part of the bi services into  
the framework? move the bi component into the framework? or for now,  
since the code there is since a prototype, keep everything into bi (as  
is now) and postpone this re-factoring?

Thanks,

Jacopo

[BJ Freeman]

when I did olap for some other software, we used libraries as you suggest.
it has been a decade or so since I did anything like this so I will have
 go over the code i wrote in another language to see exactly what I did :)
My "off the top response" would be to put it the datafile folder since
it has to do with data warehousing or interfacing to data.


Jacopo Cappellato sent the following on 7/16/2008 5:45 AM:

> Hi all,
>
> I am reviewing the stuff I did some time ago in the "bi" component
> (Business Intelligence, in specialpurpose) and I would like to start to
> clean up/enhance a few that prototype.
>
> As a first step I would like to separate the lower level services (like
> the generic ones that are used to translate operational keys into olap
> keys) for BI from the ones related to specific applications: all the
> artifacts that are application specific (entities, services and ecas)
> will be moved to the proper component.
>
> The doubt I have is this: since the higher level component will use the
> lower level services defined in the specialpurpose/bi component, this
> will create a bad dependency from applications to specialpurpose...
>
> What is the best way to fix this? Move part of the bi services into the
> framework? move the bi component into the framework? or for now, since
> the code there is since a prototype, keep everything into bi (as is now)
> and postpone this re-factoring?
>
> Thanks,
>
> Jacopo
>
>
>
>
>
>
>

[David E Jones]

On Jul 16, 2008, at 6:45 AM, Jacopo Cappellato wrote:

> Hi all,
>
> I am reviewing the stuff I did some time ago in the "bi" component  
> (Business Intelligence, in specialpurpose) and I would like to start  
> to clean up/enhance a few that prototype.
>
> As a first step I would like to separate the lower level services  
> (like the generic ones that are used to translate operational keys  
> into olap keys) for BI from the ones related to specific  
> applications: all the artifacts that are application specific  
> (entities, services and ecas) will be moved to the proper component.
>
> The doubt I have is this: since the higher level component will use  
> the lower level services defined in the specialpurpose/bi component,  
> this will create a bad dependency from applications to  
> specialpurpose...
>
> What is the best way to fix this? Move part of the bi services into  
> the framework? move the bi component into the framework? or for now,  
> since the code there is since a prototype, keep everything into bi  
> (as is now) and postpone this re-factoring?

I'm a big fan of having BI stuff in the framework, like general ETL  
tools (as much as that applies, and I know those are based on other  
framework tools) and the ad-hoc reporting web pages based on the star  
schema tables desired (which is really cool).

The only think I can think of that might be funny is in the ad-hoc  
reporting tool if it was in the framework we wouldn't want application  
specific stuff in it. We may end up wanting to have the BI tools in  
the framework, the ETL implementations per applications component in  
that component, and a big ad-hoc reporting app that builds on all of  
that stuff. Of course, maybe that could be data driven too and like in  
the framework and it wouldn't be a problem.

Anyway, just some thoughts. I do like the framework idea though.

-David

[Jacopo Cappellato-3]

On Jul 16, 2008, at 10:57 PM, David E Jones wrote:

>
> On Jul 16, 2008, at 6:45 AM, Jacopo Cappellato wrote:
>
>> Hi all,
>>
>> I am reviewing the stuff I did some time ago in the "bi" component  
>> (Business Intelligence, in specialpurpose) and I would like to  
>> start to clean up/enhance a few that prototype.
>>
>> As a first step I would like to separate the lower level services  
>> (like the generic ones that are used to translate operational keys  
>> into olap keys) for BI from the ones related to specific  
>> applications: all the artifacts that are application specific  
>> (entities, services and ecas) will be moved to the proper component.
>>
>> The doubt I have is this: since the higher level component will use  
>> the lower level services defined in the specialpurpose/bi  
>> component, this will create a bad dependency from applications to  
>> specialpurpose...
>>
>> What is the best way to fix this? Move part of the bi services into  
>> the framework? move the bi component into the framework? or for  
>> now, since the code there is since a prototype, keep everything  
>> into bi (as is now) and postpone this re-factoring?
>
> I'm a big fan of having BI stuff in the framework, like general ETL  
> tools (as much as that applies, and I know those are based on other  
> framework tools) and the ad-hoc reporting web pages based on the  
> star schema tables desired (which is really cool).
>
> The only think I can think of that might be funny is in the ad-hoc  
> reporting tool if it was in the framework we wouldn't want  
> application specific stuff in it. We may end up wanting to have the  
> BI tools in the framework, the ETL implementations per applications  
> component in that component, and a big ad-hoc reporting app that  
> builds on all of that stuff. Of course, maybe that could be data  
> driven too and like in the framework and it wouldn't be a problem.
>

David, I can confirm that the existing simple reporting application in  
the BI component is meta-data driven, no application specific stuff is  
in it. so that wouldn't be an issue.
Or maybe we could just move the screens from the BI application to the  
Webtools, and move the bi component (without webapp) to the framework.

What do you think?

Jacopo


> Anyway, just some thoughts. I do like the framework idea though.
>
> -David
>

[Enrique Ruibal]

+1 I think it should be in the framework too..

-Enrique Ruibal

David E Jones wrote

On Jul 16, 2008, at 6:45 AM, Jacopo Cappellato wrote:

> Hi all,
>
> I am reviewing the stuff I did some time ago in the "bi" component  
> (Business Intelligence, in specialpurpose) and I would like to start  
> to clean up/enhance a few that prototype.
>
> As a first step I would like to separate the lower level services  
> (like the generic ones that are used to translate operational keys  
> into olap keys) for BI from the ones related to specific  
> applications: all the artifacts that are application specific  
> (entities, services and ecas) will be moved to the proper component.
>
> The doubt I have is this: since the higher level component will use  
> the lower level services defined in the specialpurpose/bi component,  
> this will create a bad dependency from applications to  
> specialpurpose...
>
> What is the best way to fix this? Move part of the bi services into  
> the framework? move the bi component into the framework? or for now,  
> since the code there is since a prototype, keep everything into bi  
> (as is now) and postpone this re-factoring?

I'm a big fan of having BI stuff in the framework, like general ETL  
tools (as much as that applies, and I know those are based on other  
framework tools) and the ad-hoc reporting web pages based on the star  
schema tables desired (which is really cool).

The only think I can think of that might be funny is in the ad-hoc  
reporting tool if it was in the framework we wouldn't want application  
specific stuff in it. We may end up wanting to have the BI tools in  
the framework, the ETL implementations per applications component in  
that component, and a big ad-hoc reporting app that builds on all of  
that stuff. Of course, maybe that could be data driven too and like in  
the framework and it wouldn't be a problem.

Anyway, just some thoughts. I do like the framework idea though.

-David

[David E Jones]

On Jul 16, 2008, at 3:21 PM, Jacopo Cappellato wrote:

>
> On Jul 16, 2008, at 10:57 PM, David E Jones wrote:
>
>>
>> On Jul 16, 2008, at 6:45 AM, Jacopo Cappellato wrote:
>>
>>> Hi all,
>>>
>>> I am reviewing the stuff I did some time ago in the "bi" component  
>>> (Business Intelligence, in specialpurpose) and I would like to  
>>> start to clean up/enhance a few that prototype.
>>>
>>> As a first step I would like to separate the lower level services  
>>> (like the generic ones that are used to translate operational keys  
>>> into olap keys) for BI from the ones related to specific  
>>> applications: all the artifacts that are application specific  
>>> (entities, services and ecas) will be moved to the proper component.
>>>
>>> The doubt I have is this: since the higher level component will  
>>> use the lower level services defined in the specialpurpose/bi  
>>> component, this will create a bad dependency from applications to  
>>> specialpurpose...
>>>
>>> What is the best way to fix this? Move part of the bi services  
>>> into the framework? move the bi component into the framework? or  
>>> for now, since the code there is since a prototype, keep  
>>> everything into bi (as is now) and postpone this re-factoring?
>>
>> I'm a big fan of having BI stuff in the framework, like general ETL  
>> tools (as much as that applies, and I know those are based on other  
>> framework tools) and the ad-hoc reporting web pages based on the  
>> star schema tables desired (which is really cool).
>>
>> The only think I can think of that might be funny is in the ad-hoc  
>> reporting tool if it was in the framework we wouldn't want  
>> application specific stuff in it. We may end up wanting to have the  
>> BI tools in the framework, the ETL implementations per applications  
>> component in that component, and a big ad-hoc reporting app that  
>> builds on all of that stuff. Of course, maybe that could be data  
>> driven too and like in the framework and it wouldn't be a problem.
>>
>
> David, I can confirm that the existing simple reporting application  
> in the BI component is meta-data driven, no application specific  
> stuff is in it. so that wouldn't be an issue.
> Or maybe we could just move the screens from the BI application to  
> the Webtools, and move the bi component (without webapp) to the  
> framework.
>
> What do you think?

It might be nice to have a separate app... we may eventually want to  
add lots of cool stuff to this, like a fancy AJAX report builder where  
you can create view-entities and forms on the fly and such... ;)

-David

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>
[big snip]

>> David, I can confirm that the existing simple reporting application  
>> in the BI component is meta-data driven, no application specific  
>> stuff is in it. so that wouldn't be an issue.
>> Or maybe we could just move the screens from the BI application to  
>> the Webtools, and move the bi component (without webapp) to the  
>> framework.
>>
>> What do you think?
>
> It might be nice to have a separate app... we may eventually want to  
> add lots of cool stuff to this, like a fancy AJAX report builder where  
> you can create view-entities and forms on the fly and such... ;)
>
> -David

+1 :D

Jacques