Eclipse creates common metadata
Email
Print
">
Proof that this has been very successful: We have hundreds of vendors providing Eclipse plug-ins so that these tools can interoperate at the metadata level, and not just within the context of [any given] vendors product. A customer can use the Eclipse model framework across products from distinct vendors. Common metadata was absolutely the key point that enabled that success.
Then we said OK, step No. 3 was to expand the operational metadata and tool metadata from Eclipse to the world of information integration.
We had kicked off the Project Serrano a couple of years ago. … What Serrano does is extend that Eclipse framework to allow data architects and developers to find, to model, to visualize, to relate and to develop data assets, so that they can very quickly understand what data assets exist, and so they can very quickly discover relationships between data assets. So you have a table that represents customers. The tools can discover the relationship between that customer table and a transaction table, such as an order entry table. Whether [data relating to] those customers are in Oracle, the transaction is in DB2 or SQL Server [or what have you].
I can discover the assets, the relationships, and I can use that to accelerate or speed up development of applications. The developer does not need to do any of that.
Click here to read an analysis by eWEEKs Darryl Taft of the momentum of the Eclipse Java-based framework after it gained independence from IBM.
Second, because its all built into the metadata infrastructure, I can reuse it. If I have a new application, I dont need to go and ask the system to go rediscover the transaction table or any of that. All of that is available for reuse.
Finally, you can now use this metadata to assess, What would be the impact to my whole application, to my infrastructure, if I make changes to the Oracle system, or to the DB2 environment?
Thats what we are delivering with Serrano.
Then we acquired Ascential. It was already in the path of unifying metadata for all their tools, so that the profiling, quality, ETL [tools] could all leverage the same metadata infrastructure, combined with a single, unified repository that will be coming out in the "Hawk" release.
Click here to read Database Editor Lisa Vaas original, more sunny take on IBMs ability to integrate the myriad products its acquired in its Information Management strategy.
So now that we have acquired Ascential, its easy for us to unify this roadmap. Why? Ascential was focused on providing a common repository. We were focused on extending the Eclipse tool framework. Both things can sit on top of each other.
With that I have infrastructure to support the operational metadata, the architect and the developer, in Serrano and Ascential, and Ascential had support for the business user as part of their Hawk release.
People are wondering, though, How is IBM going to manage the metadata in a federated environment?
When I build a data warehouse, I am extracting data from different systems and, in general, heterogeneous systems. The only difference between federated and warehouse environments is I do consolidation before I access the data: I move all data to one place. In the case of federation, I leave the data where it is and access it when [the request] comes in. In both cases, I need to know where the data is stored, where its coming from, and what kinds of transformations I need to do. Whether I decide to extract and transform beforehand or in real time, the problem from the metadata perspective is exactly the same: I need to understand Oracle tables, DB2 tables, the relations between them and what transformations I need to do.
Next Page: Delving into the guts of IBMs metadata engine.
Click here to read an analysis by eWEEKs Darryl Taft of the momentum of the Eclipse Java-based framework after it gained independence from IBM.
Second, because its all built into the metadata infrastructure, I can reuse it. If I have a new application, I dont need to go and ask the system to go rediscover the transaction table or any of that. All of that is available for reuse.
Finally, you can now use this metadata to assess, What would be the impact to my whole application, to my infrastructure, if I make changes to the Oracle system, or to the DB2 environment?
Thats what we are delivering with Serrano.
Then we acquired Ascential. It was already in the path of unifying metadata for all their tools, so that the profiling, quality, ETL [tools] could all leverage the same metadata infrastructure, combined with a single, unified repository that will be coming out in the "Hawk" release.
Click here to read Database Editor Lisa Vaas original, more sunny take on IBMs ability to integrate the myriad products its acquired in its Information Management strategy.
So now that we have acquired Ascential, its easy for us to unify this roadmap. Why? Ascential was focused on providing a common repository. We were focused on extending the Eclipse tool framework. Both things can sit on top of each other.
With that I have infrastructure to support the operational metadata, the architect and the developer, in Serrano and Ascential, and Ascential had support for the business user as part of their Hawk release.
People are wondering, though, How is IBM going to manage the metadata in a federated environment?
When I build a data warehouse, I am extracting data from different systems and, in general, heterogeneous systems. The only difference between federated and warehouse environments is I do consolidation before I access the data: I move all data to one place. In the case of federation, I leave the data where it is and access it when [the request] comes in. In both cases, I need to know where the data is stored, where its coming from, and what kinds of transformations I need to do. Whether I decide to extract and transform beforehand or in real time, the problem from the metadata perspective is exactly the same: I need to understand Oracle tables, DB2 tables, the relations between them and what transformations I need to do.
Next Page: Delving into the guts of IBMs metadata engine. 
