-----Original Message-----
From: Charles T. Betz [mailto:charb@...]
Sent: Thursday, November 06, 2003 9:24 PM
To: erp4it@yahoogroups.com
Subject: RE: [erp4it] DCML may use RDF (!?)

Thanks David. For those who haven't encountered him previously, David is the author of Model Driven Architecture: Applying MDA to Enterprise Computing:

 

http://www.amazon.com/exec/obidos/tg/detail/-/0471319201/qid=1068181789/sr=1-1/ref=sr_1_1/002-9238714-6612821?v=glance&s=books

 

a very cogent summary of the core OMG semantic standards efforts, and the first book I have my developers read.

 

David,

 

My concern in all this is practical. Even if the concerns of each is different, is it not true that each essentially provides a formalism capable of describing modeling languages?

 

Say for the sake of argument I have a MOF-compliant repository which I have surrounded with process and a software engineering capability. We can model UML, down to deployments at the server/component level. Then RDF-based DCML comes along requiring interoperability, say for example at the point of deployment. What does my solution look like? I can't even begin to envision what my target architecture would be at that point. If it were all XMI, then I think I know what to do.

 

As you point out there is momentum to supporting RDF as an M2 metamodel. But it seems DCML will be using it at M3. (I realize the 4-level paradigm is problematic). Having DCML layered on top of RDF on top of MOF seems like insanity. I'd rather see a standard mapping from MOF-RDF directly (which is I gather what you are working on). I assume that standardization is required here, as I suspect there would be more than one way to possibly map between MOF and RDF.

 

There's also the issue of how does the DCML effort re-use *any* OMG semantics if they are in RDF-land, another practical concern - as I discuss in

 

http://erp4it.typepad.com/erp4it/2003/10/data_center_mar.html

 

there are significant overlaps with their vision and the OMG's.

 

Regards,

 

Charlie

 

 

-----Original Message-----
From: David S. Frankel [mailto:df@...]
Sent: Thursday, November 06, 2003 8:56 PM
To: erp4it@yahoogroups.com
Subject: RE: [erp4it] DCML may use RDF (!?)

I'd like to offer some additional thoughts on RDF/Semantic Web vs. MOF.  Basically the Semantic Web and MOF address two different concerns.  Both concerns have to do with metadata, and they are potentially complementary.

 

The Semantic Web seeks to use metadata about resources to make intelligent, computable inferences about those resources.  MOF seeks to streamline the mechanical management of metadata in repositories, XML files, and whatever other kind of conveyance and storage technologies come along.  The Semantic Web does not address the mechanical management concern and MOF does not address the intelligent inference concern.  For example, MOF QVT will tell us how to express a model of a transformation and how to encode that model in XML documents, Java objects, etc., but MOF tells us nothing about how to decide what the transformation should be in a given context.  Semantic Web technology and its foundations in ontologies and knowledge representation could potentially make it possible to at least partially automate the reasoning about what transformation is appropriate in a given context. 

 

Bottom line: If you're going to have lots of metadata that you want to reason about, you have to have some way of managing it.  Therein lies the potential synergy.  I'm involved in a funded project that is looking in to this, and it is not academic money, although I do agree that the Semantic Web has largely been restricted to the academics up to now.

 

As mentioned in this thread, MOF models of RDF are a possibility as are MOF mappings to RDF.  There is a standards definition process in progress in the OMG for defining a MOF metamodel for ontology definition.  There will be mappings from this metamodel to metamodels for some of the higher level stuff built on top of RDF, particularly OWL and to other knowledge management languages such as KIF.  This is a higher-granularity approach to integration than having a MOF metamodel of RDF and then generating a MOF encoding of RDF using XMI's MOF-XML mapping rules.  Some key people in the Semantic Web community are involved in the ontology definition metamodel work. 

 

Regarding the lower granularity approach: Interestingly, the first time I read one of the official RDF documents I discovered that RDF is actually described in the abstract, using English and tables, and the XML format is positioned as just one of many possible encoding formats.

 

It's possible that the problem can be addressed at both levels of granularity.  More thinking on this is needed.  Assuming $ continues to flow to support the effort, we should see some progress.

 

--Dave

 

=================================================================
David S. Frankel
David Frankel Consulting
Email: df@...
Web: www.DavidFrankelConsulting.com
Tel: +1 530 893-1100
Fax: +1 530 893-1153
David Frankel's MDA book: www.DavidFrankelConsulting.com/book.htm
=================================================================

-----Original Message-----
From: Stefan Tilkov [mailto:stefan.tilkov@...]
Sent: Thursday, November 06, 2003 2:10 PM
To: erp4it@yahoogroups.com
Subject: Re: [erp4it] DCML may use RDF (!?)

"Charles T. Betz" <charb@...> wrote on 06.11.2003 17:02:37:

> I have heard from a reliable source that the current thinking in the
> Data Center Markup Language effort (www.dcml.org) is not to use XML
> schemas, but rather RDF (the Semantic Web standard).
>
> Does anyone have any insight into the pros/cons of this? I am not
> aware that there is a standard visual formalism. Can MOF be mapped
> isometrically into RDF?
>

I'm not that knowledgeable in RDF, but as far as I can tell, you can map pretty much everything in MOF to either 'pure' XML or RDF without major problems. The question, IMO, is more political or religious - i.e., how sure can one be that RDF is going to be an accepted mainstream technology like XML (and to a far lesser degree, MOF).

Personally, I believe that there are not enough people who share the RDF/Semantic Web vision for it to escape the academic circles it's currently popular in any time soon.

Stefan

--
Stefan Tilkov, stefan.tilkov@..., http://www.innoq.com/blog/st
innoQ Deutschland GmbH, Harkortstraße 21-23, D-40880 Ratingen, Germany
Phone: +49 2102 77162-100  Mobile: +49 170 471 2624  Fax: +49 2102 77160-1



To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----Original Message-----
From: David S. Frankel [mailto:df@...]
Sent: Thursday, November 06, 2003 8:56 PM
To: erp4it@yahoogroups.com
Subject: RE: [erp4it] DCML may use RDF (!?)

I'd like to offer some additional thoughts on RDF/Semantic Web vs. MOF.  Basically the Semantic Web and MOF address two different concerns.  Both concerns have to do with metadata, and they are potentially complementary.

 

The Semantic Web seeks to use metadata about resources to make intelligent, computable inferences about those resources.  MOF seeks to streamline the mechanical management of metadata in repositories, XML files, and whatever other kind of conveyance and storage technologies come along.  The Semantic Web does not address the mechanical management concern and MOF does not address the intelligent inference concern.  For example, MOF QVT will tell us how to express a model of a transformation and how to encode that model in XML documents, Java objects, etc., but MOF tells us nothing about how to decide what the transformation should be in a given context.  Semantic Web technology and its foundations in ontologies and knowledge representation could potentially make it possible to at least partially automate the reasoning about what transformation is appropriate in a given context. 

 

Bottom line: If you're going to have lots of metadata that you want to reason about, you have to have some way of managing it.  Therein lies the potential synergy.  I'm involved in a funded project that is looking in to this, and it is not academic money, although I do agree that the Semantic Web has largely been restricted to the academics up to now.

 

As mentioned in this thread, MOF models of RDF are a possibility as are MOF mappings to RDF.  There is a standards definition process in progress in the OMG for defining a MOF metamodel for ontology definition.  There will be mappings from this metamodel to metamodels for some of the higher level stuff built on top of RDF, particularly OWL and to other knowledge management languages such as KIF.  This is a higher-granularity approach to integration than having a MOF metamodel of RDF and then generating a MOF encoding of RDF using XMI's MOF-XML mapping rules.  Some key people in the Semantic Web community are involved in the ontology definition metamodel work. 

 

Regarding the lower granularity approach: Interestingly, the first time I read one of the official RDF documents I discovered that RDF is actually described in the abstract, using English and tables, and the XML format is positioned as just one of many possible encoding formats.

 

It's possible that the problem can be addressed at both levels of granularity.  More thinking on this is needed.  Assuming $ continues to flow to support the effort, we should see some progress.

 

--Dave

 

=================================================================
David S. Frankel
David Frankel Consulting
Email: df@...
Web: www.DavidFrankelConsulting.com
Tel: +1 530 893-1100
Fax: +1 530 893-1153
David Frankel's MDA book: www.DavidFrankelConsulting.com/book.htm
=================================================================

-----Original Message-----
From: Stefan Tilkov [mailto:stefan.tilkov@...]
Sent: Thursday, November 06, 2003 2:10 PM
To: erp4it@yahoogroups.com
Subject: Re: [erp4it] DCML may use RDF (!?)

"Charles T. Betz" <charb@...> wrote on 06.11.2003 17:02:37:

> I have heard from a reliable source that the current thinking in the
> Data Center Markup Language effort (www.dcml.org) is not to use XML
> schemas, but rather RDF (the Semantic Web standard).
>
> Does anyone have any insight into the pros/cons of this? I am not
> aware that there is a standard visual formalism. Can MOF be mapped
> isometrically into RDF?
>

I'm not that knowledgeable in RDF, but as far as I can tell, you can map pretty much everything in MOF to either 'pure' XML or RDF without major problems. The question, IMO, is more political or religious - i.e., how sure can one be that RDF is going to be an accepted mainstream technology like XML (and to a far lesser degree, MOF).

Personally, I believe that there are not enough people who share the RDF/Semantic Web vision for it to escape the academic circles it's currently popular in any time soon.

Stefan

--
Stefan Tilkov, stefan.tilkov@..., http://www.innoq.com/blog/st
innoQ Deutschland GmbH, Harkortstraße 21-23, D-40880 Ratingen, Germany
Phone: +49 2102 77162-100  Mobile: +49 170 471 2624  Fax: +49 2102 77160-1



To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----Original Message-----
From: Stefan Tilkov [mailto:stefan.tilkov@...]
Sent: Thursday, November 06, 2003 2:10 PM
To: erp4it@yahoogroups.com
Subject: Re: [erp4it] DCML may use RDF (!?)

"Charles T. Betz" <charb@...> wrote on 06.11.2003 17:02:37:

> I have heard from a reliable source that the current thinking in the
> Data Center Markup Language effort (www.dcml.org) is not to use XML
> schemas, but rather RDF (the Semantic Web standard).
>
> Does anyone have any insight into the pros/cons of this? I am not
> aware that there is a standard visual formalism. Can MOF be mapped
> isometrically into RDF?
>

I'm not that knowledgeable in RDF, but as far as I can tell, you can map pretty much everything in MOF to either 'pure' XML or RDF without major problems. The question, IMO, is more political or religious - i.e., how sure can one be that RDF is going to be an accepted mainstream technology like XML (and to a far lesser degree, MOF).

Personally, I believe that there are not enough people who share the RDF/Semantic Web vision for it to escape the academic circles it's currently popular in any time soon.

Stefan

--
Stefan Tilkov, stefan.tilkov@..., http://www.innoq.com/blog/st
innoQ Deutschland GmbH, Harkortstraße 21-23, D-40880 Ratingen, Germany
Phone: +49 2102 77162-100  Mobile: +49 170 471 2624  Fax: +49 2102 77160-1



To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

David,

Would you expand on your reasoning a little?

I can see how an object model might be more appropriate for data modelling,
whilst a relational model more efficient for processing large volumes of
transactional data, but I do not know enough about how easy it would be to
integrate the two (and this, after all, is what we are all about here, isn't
it?)

-Robert Falkowitz

-----Original Message-----
From: datamangler2003 [mailto:dbe@...]
Sent: Thursday, November 06, 2003 22:12
To: erp4it@yahoogroups.com
Subject: [erp4it] Re: SQL is wrong engine


--- In erp4it@yahoogroups.com, "Charles T. Betz" <charb@v...>
wrote:

>
> Absolutely agree, except for the flat file part. See
>

Actually I agree with your objection...

Not sure how precisely to say it positively, but my intent is to state
that while RDBMS engines are excellent for DATA work, the
"data" in Repositories is the many, many relationships between
the (hopefully if someone's doing the work right) relatively few
thingamees in your enterprise.

Another way... just because RDBMS engines are robust,
available & lots of people have been educated in their use, is not
to say that enterprise repositories should also be based on
RDBMS engines.

- David



------------------------ Yahoo! Groups Sponsor ---------------------~--> Buy
Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark Printer
at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/dpFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

-----Original Message-----
From: Robert S. Falkowitz [mailto:robert@...]
Sent: Thursday, November 06, 2003 11:44 AM
To: erp4it@yahoogroups.com
Subject: [erp4it] Enterprise masters

Let's split off this question into a separate thread.

 

I  get the impression from your remarks that the "enterprise masters"  are not so "well-established" after all. Put yourself in the place of a software vendor selling into a market where the data model for personnel is either some HR system (is it PeopleSoft, SAP, Oracle, some outsourced ASP, or one of a thousand different applications that local requirements mandate), or LDAP, or Active Directory (or maybe the customer is still using NetWare), etc. The data about sites could also be in an ERP, or could be in a proprietary operational tool that gives the company a competitive advantage (pace Harvard), and so forth. Are calendars in the project planning tool, or the manufacturing scheduling tool, or....)

 

Which vendor would be willing to take the first step? As far as I can tell, only the vendor pretending to offer the master version. So there is no basis for agreement.

 

The fact that the vendor receives a sort of "white letter" from some customers is great and may show a market for that type of solution, but that does not really make it any easier to take the first step. Put yourself in the vendor's shoes. What are the practical steps you can take to meet the need to establish "enterprise masters"?

1. Service Management tools tend to use data models that overlap with "well-established enterprise masters" and thereby create integration headaches. What are these established masters, and what are the strategies of IT organizations to deal with these headaches (other than what is mentioned below).
[ctb] The established master for personnel is usually the HR system, in tandem with the provisioning (security) systems such as LDAP or Active Directory. Depending on industry, the master for locations would either be in operational or facilities areas. Some kind of calendar master can usually be found since the beginning of automated data processing in any shop; the data warehouse time dimension might be a place to start, or again operations. It's hard generalizing across industries. 

 

 

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

I won't be able to be in London. For those wondering, Oliver is
referring to the upcoming Object Management Group session:

http://www.omg.org/registration/registration-info.htm

Agree with the constituent parts - but I think we need to give a nod to
IT Service Management and/or ITIL as we start to conceptualize this
whole problem domain. (I know some ITSM advocates who would say that
their paradigm is inclusive over all, but there is a reality of
disparate discourses we're trying to resolve here - so totalizing
visions must be handled with care.)

-Charlie

> -----Original Message-----
> From: oliver_sims [mailto:oliver.sims@...]
> Sent: Thursday, November 06, 2003 9:19 AM
> To: erp4it@yahoogroups.com
> Subject: [erp4it] Meeting of erp4it at OMG London?
>
>
> How many of us will be at OMG London? If a quorum, then it would be
> great to meet up sometime - maybe in an evening. If I could suggest
> one agenda item, it's my short presi on the necessary constituents
> for effective ERP4IT. Imho, the constituent parts highly
> synergistic, and no one of them alone will do it all. They are (in
> no particular order):
>
> - Architecture (in fact, several architectures), with design
> following a specified architectural style (as Hubert uses the
> phrase)
> - Business Modeling
> - MDA
> - CBD (with focus on the provision part - assembly follows this
> rather than precedes it)
> - Product Line approach (see SEI) (implies specific IT organization)
> - Processes that support the erp4it vision of which the above are
> parts
>
> Regards,
> Oliver
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~--> Buy Ink Cartridges or Refill Kits
> for your HP, Epson, Canon or Lexmark Printer at MyInks.com.
> Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/dpFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

--- In erp4it@yahoogroups.com, "Charles T. Betz" <charb@v...>
wrote:

>
> Absolutely agree, except for the flat file part. See
>

Actually I agree with your objection...

Not sure how precisely to say it positively, but my intent is to state
that while RDBMS engines are excellent for DATA work, the
"data" in Repositories is the many, many relationships between
the (hopefully if someone's doing the work right) relatively few
thingamees in your enterprise.

Another way... just because RDBMS engines are robust,
available & lots of people have been educated in their use, is not
to say that enterprise repositories should also be based on
RDBMS engines.

- David

1. Service Management tools tend to use data models that overlap with "well-established enterprise masters" and thereby create integration headaches. What are these established masters, and what are the strategies of IT organizations to deal with these headaches (other than what is mentioned below).
[ctb] The established master for personnel is usually the HR system, in tandem with the provisioning (security) systems such as LDAP or Active Directory. Depending on industry, the master for locations would either be in operational or facilities areas. Some kind of calendar master can usually be found since the beginning of automated data processing in any shop; the data warehouse time dimension might be a place to start, or again operations. It's hard generalizing across industries. 

 

 

I have heard from a reliable source that the current thinking in the
Data Center Markup Language effort (www.dcml.org) is not to use XML
schemas, but rather RDF (the Semantic Web standard).

Does anyone have any insight into the pros/cons of this? I am not
aware that there is a standard visual formalism. Can MOF be mapped
isometrically into RDF?

I have suggested to my source that the DCML look seriously at MOF,
because of the infrastructure services (e.g. QVT) that will be
immediately available, but this MOF/RDF comparison is a bit beyond my
expertise :-)

(I know there's a few of you recently joined who could speak to this!)

Regards,

Charlie

Further to my last:

The relevant SEI page is http://www.sei.cmu.edu/plp/plp_init.html.

Also, I would have included SOA in my list - except that service
orientation is endemic - systemic even - across the various items in
the list.

Rgds,
Oliver

In the COMBINE project (an EU 5th Framework project that finished
last year), we constructed a business model of an IT organization
(actually an ODP Enterprise Viewpoint model, with some info model
thrown in).

The question then was how to implement the system(s) that would make
IT very much more productive. Some said it couldn't be done.
However, using our approach to maker a one-to-one transformation
from (parts of) the business model to design-level PIM modules, it
became apparent that it was eminently do-able.

Then we found that the tools available were not well-aligned with
the (first-cut) PIM; nor were they any good at all at
interoperability (other than primitive file transfer) - even through
a MOF-based repository product!

Successful ERP4IT will, I hope, drive tools developments.

Rgds,
Oliver

How many of us will be at OMG London? If a quorum, then it would be
great to meet up sometime - maybe in an evening. If I could suggest
one agenda item, it's my short presi on the necessary constituents
for effective ERP4IT. Imho, the constituent parts highly
synergistic, and no one of them alone will do it all. They are (in
no particular order):

- Architecture (in fact, several architectures), with design
following a specified architectural style (as Hubert uses the
phrase)
- Business Modeling
- MDA
- CBD (with focus on the provision part - assembly follows this
rather than precedes it)
- Product Line approach (see SEI) (implies specific IT organization)
- Processes that support the erp4it vision of which the above are
parts

Regards,
Oliver

----- Original Message -----

From: datamangler2003

To: erp4it@yahoogroups.com

Sent: Thursday, November 06, 2003 3:31 AM

Subject: [erp4it] Re: Repository proliferation: time for a freeze

John -

>
> Business ERP was about 'one enterprise wide database', 'one
>enterprise wide work environment' and  'one set of integrated
>processes'.
>

Sorry to be blunt, but that's simply NEVER going to work.

There are simply too many datasinks (VSAM, DB2, IMS, Supra,
VMS, dBaseIII, Oracle, etc., etc.) for that dream to ever happen.

Applications are point-solutions, typically paid for by the line
managment. 

Yes the humongous ERP/CRM scale "solutions" are allegedly
corporate wide... but then look at their success rates.

If I had 10 cents for every shop where I've heard... "We're an SAP
shop... but those old legacy systems still keep running..."


Remember IBM's infamous RepoMan (AD/Cycle, Repository
Manager)?  What was it... 1700 DB2 tables in the repository
model.  Natually it collapsed under it's own complexity.


What I'd like to see is relatively lightweight federated repositories
that can be easily & cheaply placed alongside, or woven into the
exisiting change management process of existing systems.

- David






To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Absolutely agree, except for the flat file part. See

http://erp4it.typepad.com/erp4it/2003/10/how_to_model_th.html
and
http://erp4it.typepad.com/erp4it/2003/11/more_on_the_rep.html

-Charlie

> -----Original Message-----
> From: datamangler2003 [mailto:dbe@...]
> Sent: Wednesday, November 05, 2003 9:37 PM
> To: erp4it@yahoogroups.com
> Subject: [erp4it] SQL is wrong engine
>
>
> All -
>
> Just to toss a hopefully provocative thought on the table...
>
> Relational database engines (DB2, Oracle, etc.) are excellent for
> DATA.
>
> But meta data databases don't contain much data... they contain
> lots & lots & lots of relationships, with minimal actual data.
>
> I would posit that a flat file engine is more appropriate... with
> super, duper indexing abilities.
>
> - David
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~--> Buy Ink Cartridges or Refill Kits
> for your HP, Epson, Canon or Lexmark Printer at MyInks.com.
> Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/dpFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Hi David,

The "mother of all databases" theory is justly and long since
discredited. Even ERP vendors have pulled back from this; they partition
their solutions by function and/or process area.

However AD/Cycle was a different animal, being a vendor-driven metadata
standard based on relational technology. From what I understand (and
finding source material on it is exceedingly difficult) it did fail for
the reasons you cite.

The lessons of AD/Cycle have not been lost on the OMG. That's why they
pay such close attention to packaging/partitioning the metamodels --
packaging semantics being part of the core MOF -- and being very clear
on the dependencies between the packages. There are far more than 1700
classes in the OMG world, but you can pick and choose the functionality
you need to a great extent.

-Charlie

> -----Original Message-----
> From: datamangler2003 [mailto:dbe@...]
> Sent: Wednesday, November 05, 2003 9:31 PM
> To: erp4it@yahoogroups.com
> Subject: [erp4it] Re: Repository proliferation: time for a freeze
>
>
> John -
>
> >
> > Business ERP was about 'one enterprise wide database', 'one
> >enterprise wide work environment' and  'one set of integrated
> >processes'.
> >
>
> Sorry to be blunt, but that's simply NEVER going to work.
>
> There are simply too many datasinks (VSAM, DB2, IMS, Supra,
> VMS, dBaseIII, Oracle, etc., etc.) for that dream to ever happen.
>
> Applications are point-solutions, typically paid for by the line
> managment.
>
> Yes the humongous ERP/CRM scale "solutions" are allegedly
> corporate wide... but then look at their success rates.
>
> If I had 10 cents for every shop where I've heard... "We're an SAP
> shop... but those old legacy systems still keep running..."
>
>
> Remember IBM's infamous RepoMan (AD/Cycle, Repository
> Manager)?  What was it... 1700 DB2 tables in the repository
> model.  Natually it collapsed under it's own complexity.
>
>
> What I'd like to see is relatively lightweight federated repositories
> that can be easily & cheaply placed alongside, or woven into the
> exisiting change management process of existing systems.
>
> - David
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
> Printer at MyInks.com. Free s/h on orders $50 or more to the
> US & Canada.
> http://www.c1tracking.com/l.asp?cid=5511
> http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/dpFolB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> erp4it-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>

All -

Just to toss a hopefully provocative thought on the table...

Relational database engines (DB2, Oracle, etc.) are excellent for
DATA.

But meta data databases don't contain much data... they contain
lots & lots & lots of relationships, with minimal actual data.

I would posit that a flat file engine is more appropriate... with
super, duper indexing abilities.

- David

John -

>
> Business ERP was about 'one enterprise wide database', 'one
>enterprise wide work environment' and  'one set of integrated
>processes'.
>

Sorry to be blunt, but that's simply NEVER going to work.

There are simply too many datasinks (VSAM, DB2, IMS, Supra,
VMS, dBaseIII, Oracle, etc., etc.) for that dream to ever happen.

Applications are point-solutions, typically paid for by the line
managment.

Yes the humongous ERP/CRM scale "solutions" are allegedly
corporate wide... but then look at their success rates.

If I had 10 cents for every shop where I've heard... "We're an SAP
shop... but those old legacy systems still keep running..."


Remember IBM's infamous RepoMan (AD/Cycle, Repository
Manager)?  What was it... 1700 DB2 tables in the repository
model.  Natually it collapsed under it's own complexity.


What I'd like to see is relatively lightweight federated repositories
that can be easily & cheaply placed alongside, or woven into the
exisiting change management process of existing systems.

- David

-----Original Message-----
From: Robert S. Falkowitz [mailto:robert@...]
Sent: Tuesday, November 04, 2003 12:13 PM
To: erp4it@yahoogroups.com
Subject: RE: [erp4it] Repository proliferation: time for a freeze

There are several points here, each of which could be a separate thread:

 

1. Service Management tools tend to use data models that overlap with "well-established enterprise masters" and thereby create integration headaches. What are these established masters, and what are the strategies of IT organizations to deal with these headaches (other than what is mentioned below).
[ctb] The established master for personnel is usually the HR system, in tandem with the provisioning (security) systems such as LDAP or Active Directory. Depending on industry, the master for locations would either be in operational or facilities areas. Some kind of calendar master can usually be found since the beginning of automated data processing in any shop; the data warehouse time dimension might be a place to start, or again operations. It's hard generalizing across industries.

2. Some of these tools use proprietary APIs which, in the best of cases, are still non-trivial to use. What are other users experiences in this area?
[ctb] Worked for two years with the ModelMart and Cool:Gen APIs. Both were as you say non-trivial, beastly so. Folks who complain about the complexity of XMI don't realize that there are really no better alternatives. The problem domain is just hard. 

3. Is the OMG's XML Metadata Interchange a good choice as a canonical format between such tools? [ctb] I think so. DCML if it gets baked may be an alternative.
[ctb]  Which tools currently use XML?[ctb]  I assume you mean XMI. The uptake is good in the data community, due to the general acceptance of the Common Warehouse Metamodel, and the UML vendors are coming along. I did an overall summary last year and found that I could harvest over 70 different products using XMI either natively or via MetaIntegration, which was twice as many as CA's Advantage Repository could support. (See www.metaintegration.net, a firm that Giga called the "Switzerland of Metadata." They have scanners that can emit XMI for many CASE tools.)

 

IBM is a special case. They have a very strong direction towards basing large sections of their product architectures on eMOF, Essential MOF. This is already part of the Eclipse framework. Another interesting effort sponsored by Sun is the open source NetBeans Metadata Repository; its main problem is that it is an interface implementation riding on top of a B-tree persistence architecture. Someone needs to implement a real DBMS-based persistence solution of it.

4. Will MOF-compliant repositories become commonplace, and if so, will  they become a commodity infrastructure technology? What are the implications of this for IT organizations?
[ctb]  This is really the $64,000 question. I'll post separately on this.

5. How can tools improve their added value by better understanding IT business processes?
[ctb] The same way that ERP systems did for other business areas. There's the well-known criticism of ERP tools that they tend to force business processes on companies, rather than supporting what was already there. But the other side of the coin is that, when the company has dysfunctional (or no!) process, the ERP solution helps on both the technical and process levels.  

6. Is there really a reliable way to stop snoring?[ctb]  Read the erp4it list before bed; it promotes deep sleep :-) 

 

From where I sit, I cannot see how a software editor can afford to put on the market a solution that does not provide, in and of itself, data structures that cover the requirements of that application.
[ctb]Given current market realities, I tend to agree. But if they decouple the front and back ends via a JMI or XMI based interface, then they would be much better positioned to support other repositories.  

 The market into which they are selling is far to diversified to do otherwise. I suspect, too, that the creation of standard interfaces is extremely expensive for these companies, so they only do it if they can see the payback up front and run little risk in developing the functionality.
[ctb] Well, Informatica's recent experience with SuperGlue is informative. From what I understand, they originally said "We are not going to support MOF at the general case, we are just going to instantiate CWM" but their engineers actually determined that the MOF interface was helpful in engineering the specific solution. These standards help to decouple your architecture internally, as well as promoting interoperability.

 As it is, many of the leading tools already have interfaces to tools like OpenView, Patrol, LDAP servers or SAP, that only require configuring to use.

 

-Robert Falkowitz
[ctb] 

Thanks Robert, great discussion.  

-----Original Message-----
From: John Gibert [mailto:J.Gibert@...]
Sent: Tuesday, November 04, 2003 8:12 AM
To: erp4it@yahoogroups.com
Subject: Re: [erp4it] Repository proliferation: time for a freeze

Charles and all,

 

Twenty years ago when 'Business ERP' started to happen with MRP, few people believed that integrating disparate departmental systems with disparate data sources was what ERP was about.

 

Business ERP was about 'one enterprise wide database', 'one enterprise wide work environment' and  'one set of integrated processes'.

 

So should ERP4IT be pursuing the same goal a single repository and a single work engine?
[ctb] 

Good, fundamental question. I continue to use the "erp4it" formulation as evocative (provocative?), not prescriptive. I DON'T want to see the kind of vendor domination the classic ERP model implies. I DO want to see the same sorts of efficiencies. Having the cake and eating it too, I guess. That's where the standards come in. 

 

Can IT move forward to ERP4IT if it tries to tie together 'best of breed' solutions for the individual domains of IT because the process overlaps and gaps and inconsistencies as you point out are so great.

 

Now remember that data models hold  not only 'standing data' like assets, but also hold 'transaction/ event data' like incidents. There is no standard IT process model that defines IT's processes and so, if system A, an ITSMA product, handles IT 'Incidents' (as ITIL defines them), then system B, a PSA product, will handle 'Issues' (as PRINCE defines them)- are 'Incidents and Issues' the same or different? The lack of agreed basic terminology is just a start.
[ctb] This is why we need an ITSM Metamodel or equivalent. There has already been some work done by DMTF, DCML is starting, and now I hear from a colleague that I need to check out the TMF work.

 

Web services will allow composite solutions to be made from individual elements of applications and data sources, and the OMG with XML and MOF can provide mechanisms for data definition and data interchange. However the critical thing is to establish a standard data and event definition of IT management processes along with some overall architecture of the IT domains to glue it all together. How long will that take to accomplish and who will drive it?
[ctb] A lot is already there in UML 2, EDOC, and CWM, especially in terms of pure configuration management. The more I look at UML 2 the more I think it can handle most general CM challenges. What's missing is the process-centric stuff: incident, problem, change, capacity, continuity. 

 

I'm NOT advocating standardizing the process models. That's where the vendors need to compete. However, some precisely specified reference models might be useful, and might be necessary to as a framework for standardizing the event model.

 

Again re: who: it will be DCML, DMTF, TMF, or OMG.  

 

I am a member of the itSMF and an associate of the PMI, APM, IFEAD. There are so many professional business and IT interest groups operating so many IT frameworks that protect their own corner tightly and would need to be eased out of them. I am willing to help because I believe in the need for a Unified approach to management.
[ctb] Agreed re: the silos. But the overlaps are so huge. Simply standardizing the concepts of system, component, server, and the deployment of system to server would be a big start -- so many tools cover this. See http://www.omg.org/cgi-bin/apps/doc?ptc/03-08-02.pdf, "Deployments" (p 197). This is a very elegant conception, not as baroque as some OMG stuff.  

 

I have looked at IT management frameworks that span IT domains like COBIT and feel that we need to define a generic advisory IT management framework with terminology - all ISO certified to move this forward.

 

Equally if not more importantly, what has been said above should also fully involve the business as the driver of IT, ERP4IT that does not fully involve the business will be like ERP with no CRM - IT processes isolated from the corresponding business drivers and processes.
[ctb] This is where Service Level Management comes in I think, an area that I am less familiar with. I know it's working for infrastructure vendors (e.g. telecomm). Has anyone seen it succeed in a classic, business-driven, data-centric, big IT environment? 

 

We need ERP4BIT which should integrate Business-IT Strategy, Business-IT Architecture, Business-IT Development and Business-IT Delivery and Support.
[ctb] 

Interesting idea - but separation of concerns/decoupling/encapsulation is also helpful in order to manage the complexity. 

 

My company has been working on a single integrated 'ERP4BIT' solution called Be-st and it is possible to have true ERP4BIT. We see the value of web services and XML and MOF as a way of making the product work with other solutions - until it replaces them. Please see our web site www.be-st.co.uk for details.

 

Best regards, John Gibert
[ctb] 

Thanks John! 

 

----- Original Message -----

From: Charles T. Betz

To: erp4it@yahoogroups.com

Sent: Tuesday, November 04, 2003 3:40 AM

Subject: [erp4it] Repository proliferation: time for a freeze

(from www.erp4it.com)

Repository proliferation: time for a freeze

As part of my job, I have been reviewing quite a few products for the internal IT market. (Again, for newcomers to this blog, the concern here is not for our business customers, but rather for enterprise IT's own internal processes and the automation solutions being proposed for them.)

The common denominator among every single one of these vendors is they all are building their own repository, usually based on SQL, and with their own proprietary data model.

I have done a detailed analysis of several such data models for such tools, and continue to be dismayed by the huge overlaps. One reviews an asset management system from company A and finds it has a nontrivial incident management capability baked in, as does the change management system from company B, while the configuration management solution from company C has a little bit of everything. All have their own tables for key enterprise IT reference data such as location, calendar, and staff, none of which IMHO should be sourced in any such application (such data should have well-established enterprise masters). This is not to mention core information such as server, component, system, and business process, all of which needs to be easily interchangeable.

So, we are pushed into buying such solutions, and then the IT capability winds up with the same integration headache we've been solving for our clients for years. If you're lucky, there is an app server or at least a library with a public API. If you're unlucky, dual entry or maybe you can hack the tables and cram stuff into them (risking vendor support). And even in the best case scenario of a robust public API, you still have to figure out its semantics and map the source to target. If you want a canonical publish/subscribe representation -- what then?

Well, one answer would be to use the OMG's XML Metadata Interchange as your canonical format between such tools. But this raises an interesting question - why don't the vendors just support XMI as a common i/o format? This might actually have some radical consequences, the end result being I think the commodification of the repository capability. If every repository simply understands XMI, and supports specific key models such as the definition of systems, components, and their deployment to nodes - that's a huge part of the problem domain right there, that no longer needs to be modeled by each and every vendor.

If MOF-compliant repositories become commonplace, and the OMG continues to crank out useful metamodels (including the IT Service Management Metamodel I'd like to see), then the market really shifts. Repositories are hard to do right, and companies that want to play in that space should focus on them -- but they may well become a commodity infrastructure technology.

The value-add stuff will come in understanding the IT business processes better. If you can show an application that integrates (meta)data from disparate sources and is clearly best-in-class in such categories as managing internal IT workflow, supporting analytics, and other IT process related applications, you will succeed. And you might well find you don't need to build yet another repository.

-ctb

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

----- Original Message -----

From: Charles T. Betz

To: erp4it@yahoogroups.com

Sent: Monday, November 03, 2003 9:40 PM

Subject: [erp4it] Repository proliferation: time for a freeze

(from www.erp4it.com)

Repository proliferation: time for a freeze

As part of my job, I have been reviewing quite a few products for the internal IT market. (Again, for newcomers to this blog, the concern here is not for our business customers, but rather for enterprise IT's own internal processes and the automation solutions being proposed for them.)

The common denominator among every single one of these vendors is they all are building their own repository, usually based on SQL, and with their own proprietary data model.

I have done a detailed analysis of several such data models for such tools, and continue to be dismayed by the huge overlaps. One reviews an asset management system from company A and finds it has a nontrivial incident management capability baked in, as does the change management system from company B, while the configuration management solution from company C has a little bit of everything. All have their own tables for key enterprise IT reference data such as location, calendar, and staff, none of which IMHO should be sourced in any such application (such data should have well-established enterprise masters). This is not to mention core information such as server, component, system, and business process, all of which needs to be easily interchangeable.

So, we are pushed into buying such solutions, and then the IT capability winds up with the same integration headache we've been solving for our clients for years. If you're lucky, there is an app server or at least a library with a public API. If you're unlucky, dual entry or maybe you can hack the tables and cram stuff into them (risking vendor support). And even in the best case scenario of a robust public API, you still have to figure out its semantics and map the source to target. If you want a canonical publish/subscribe representation -- what then?

Well, one answer would be to use the OMG's XML Metadata Interchange as your canonical format between such tools. But this raises an interesting question - why don't the vendors just support XMI as a common i/o format? This might actually have some radical consequences, the end result being I think the commodification of the repository capability. If every repository simply understands XMI, and supports specific key models such as the definition of systems, components, and their deployment to nodes - that's a huge part of the problem domain right there, that no longer needs to be modeled by each and every vendor.

If MOF-compliant repositories become commonplace, and the OMG continues to crank out useful metamodels (including the IT Service Management Metamodel I'd like to see), then the market really shifts. Repositories are hard to do right, and companies that want to play in that space should focus on them -- but they may well become a commodity infrastructure technology.

The value-add stuff will come in understanding the IT business processes better. If you can show an application that integrates (meta)data from disparate sources and is clearly best-in-class in such categories as managing internal IT workflow, supporting analytics, and other IT process related applications, you will succeed. And you might well find you don't need to build yet another repository.

-ctb

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Great posts, all. This is exactly the kind of discusson I wanted.

I'll respond when the baby stops crying. Just a note - only your FIRST
post is moderated. After that, they go right through.

Regards,

Charlie

(from www.erp4it.com)

Repository proliferation: time for a freeze

As part of my job, I have been reviewing quite a few products for the internal IT market. (Again, for newcomers to this blog, the concern here is not for our business customers, but rather for enterprise IT's own internal processes and the automation solutions being proposed for them.)

The common denominator among every single one of these vendors is they all are building their own repository, usually based on SQL, and with their own proprietary data model.

I have done a detailed analysis of several such data models for such tools, and continue to be dismayed by the huge overlaps. One reviews an asset management system from company A and finds it has a nontrivial incident management capability baked in, as does the change management system from company B, while the configuration management solution from company C has a little bit of everything. All have their own tables for key enterprise IT reference data such as location, calendar, and staff, none of which IMHO should be sourced in any such application (such data should have well-established enterprise masters). This is not to mention core information such as server, component, system, and business process, all of which needs to be easily interchangeable.

So, we are pushed into buying such solutions, and then the IT capability winds up with the same integration headache we've been solving for our clients for years. If you're lucky, there is an app server or at least a library with a public API. If you're unlucky, dual entry or maybe you can hack the tables and cram stuff into them (risking vendor support). And even in the best case scenario of a robust public API, you still have to figure out its semantics and map the source to target. If you want a canonical publish/subscribe representation -- what then?

Well, one answer would be to use the OMG's XML Metadata Interchange as your canonical format between such tools. But this raises an interesting question - why don't the vendors just support XMI as a common i/o format? This might actually have some radical consequences, the end result being I think the commodification of the repository capability. If every repository simply understands XMI, and supports specific key models such as the definition of systems, components, and their deployment to nodes - that's a huge part of the problem domain right there, that no longer needs to be modeled by each and every vendor.

If MOF-compliant repositories become commonplace, and the OMG continues to crank out useful metamodels (including the IT Service Management Metamodel I'd like to see), then the market really shifts. Repositories are hard to do right, and companies that want to play in that space should focus on them -- but they may well become a commodity infrastructure technology.

The value-add stuff will come in understanding the IT business processes better. If you can show an application that integrates (meta)data from disparate sources and is clearly best-in-class in such categories as managing internal IT workflow, supporting analytics, and other IT process related applications, you will succeed. And you might well find you don't need to build yet another repository.

-ctb

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

From: Charles T. Betz

To: erp4it@yahoogroups.com

Sent: Tuesday, November 04, 2003 3:40 AM

Subject: [erp4it] Repository proliferation: time for a freeze

(from www.erp4it.com)

Repository proliferation: time for a freeze

As part of my job, I have been reviewing quite a few products for the internal IT market. (Again, for newcomers to this blog, the concern here is not for our business customers, but rather for enterprise IT's own internal processes and the automation solutions being proposed for them.)

The common denominator among every single one of these vendors is they all are building their own repository, usually based on SQL, and with their own proprietary data model.

I have done a detailed analysis of several such data models for such tools, and continue to be dismayed by the huge overlaps. One reviews an asset management system from company A and finds it has a nontrivial incident management capability baked in, as does the change management system from company B, while the configuration management solution from company C has a little bit of everything. All have their own tables for key enterprise IT reference data such as location, calendar, and staff, none of which IMHO should be sourced in any such application (such data should have well-established enterprise masters). This is not to mention core information such as server, component, system, and business process, all of which needs to be easily interchangeable.

So, we are pushed into buying such solutions, and then the IT capability winds up with the same integration headache we've been solving for our clients for years. If you're lucky, there is an app server or at least a library with a public API. If you're unlucky, dual entry or maybe you can hack the tables and cram stuff into them (risking vendor support). And even in the best case scenario of a robust public API, you still have to figure out its semantics and map the source to target. If you want a canonical publish/subscribe representation -- what then?

Well, one answer would be to use the OMG's XML Metadata Interchange as your canonical format between such tools. But this raises an interesting question - why don't the vendors just support XMI as a common i/o format? This might actually have some radical consequences, the end result being I think the commodification of the repository capability. If every repository simply understands XMI, and supports specific key models such as the definition of systems, components, and their deployment to nodes - that's a huge part of the problem domain right there, that no longer needs to be modeled by each and every vendor.

If MOF-compliant repositories become commonplace, and the OMG continues to crank out useful metamodels (including the IT Service Management Metamodel I'd like to see), then the market really shifts. Repositories are hard to do right, and companies that want to play in that space should focus on them -- but they may well become a commodity infrastructure technology.

The value-add stuff will come in understanding the IT business processes better. If you can show an application that integrates (meta)data from disparate sources and is clearly best-in-class in such categories as managing internal IT workflow, supporting analytics, and other IT process related applications, you will succeed. And you might well find you don't need to build yet another repository.

-ctb

To unsubscribe from this group, send an email to:
erp4it-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Martin Erb
Servitect

Telephone: 804.934.2383 (tie 414) Fax:804.934.2232 (tie 414)
E-Mail: mailto:martin.erb@...
Cell:804.357.9550 SMS/TXT vtext.com Text e-mail: 8043579550@...
Mail: Capital One, 12011-0310, 5600 Cox Road, Glen Allen, VA 23060 USA
Location: Highwoods III Building 1 #3059

************************************************************************** The information transmitted herewith is sensitive information intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.

Hi All --

Congratulations to Charles for starting this new group.  It's good to see
people trying to get a comprehensive view of the IT elephant (:-)

The following has been posted to other groups, but is hopefully also of
interest to ERPs.

Here's an interesting quote from Cliff Longman writing in the October Tdan....

"Next-generation data warehousing assumes that both the business model and
reporting requirements are ever-changing. This enables businesses not only
to obtain up to date business intelligence, but also to compare present,
past and predicted performance, no matter what the business structure is at
any given time. This enables business leaders to run truly adaptive
enterprises, capitalising on opportunities and reacting to global events
faster than the competition."             ---  http://www.tdan.com/i026hy03.htm

In our work, we have been trying to address ever-changing reporting
requirements, by fielding new technology.

It would be good to hear from ERP folks -- what is your favorite
methodology and of toolset to address this ?

Thanks in advance for your thoughts.               -- Adrian


                                         INTERNET BUSINESS LOGIC

Business Rules in English + Semantic Data Integration + Your Oracle Databases

                                            www.reengineeringllc.com

Adrian Walker
Reengineering LLC
PO Box 1412
Bristol
CT 06011-1412 USA

Phone: USA 860 583 9677
Cell:    USA  860 830 2085
Fax:    USA  860 314 1029