David Linthicum has a revealing article in the May 1998 issue of DBMS magazine (such a strange loss when it folded – one of my favortite sources of infoe on all things data-based) entitled Conducting Components. It is revealing because the article describe the various tools available for Component management in the late 1990s … and for a number this was their last hurrah.
I can remember using dBase at roughly 10 years prior in the DOS world. One of the wonderful aspects of the program is that it would show me all my development assets when I pointed either to a development home directory or a project file -all the menus, input forms, reports, tables, indexes and scripts. I could see in a glance the complete system and a quick click on any dBase object would bring up the appropriate script or visual editor. Later when Borland bought the dBase franchise, it was possible to see some other assets like Paradox tables and forms or CSV files. In effect a small front end acted as a simple repository of all the assets for a project.
Now extend this idea three steps further – allow the development front end to see the assets and components of any designated project. This means the project likely will be distributed over several servers and visibility permissions will have to be provided and respected. Finally, allow it to see heterogeneous sources – tables, indexes, and other assets from several different database vendors or OCX and Javabeans GUI components or Crystal and R&R report forms or Tibco and Ilog middleware and business rules etc. In effect make the front end, a general repository for development objects. This is theory – now lets see what David describes in 1998.
Development Repositories
The first repository mentioned in Davids article is the Microsoft Repository which was both broad and limited. Broad in the sense that it supported a meta-meta model (the OIM-Object Information Model whicht is a model for describing how to story repository data), had a UML modeling tool (UML Visual Modeler, a Rational Rose subset) and was able ot reverse engineer Visual Basic programs and store them in the repository. In this regard the Microsoft Repository was a big step up from the dBase model because it not only provided a database for storing development resource information but had all these extra tools and architectural design enhancements.
But the Microsoft Repository was myopic – only supporting COM objects and Visual Basic tools – though it was designed to be much broader in application. Strangely enough, as David describes it, Microsoft Repositorys greatest competitor was Visual Studio 98s own Visual Component Manager which tracks all ActiveX and Visual Basic components. Visual Components was even more myopic but it was comparatively successful because it had all the classic Redmond virtues that Microsoft Repository seemed to lack: easy to install, nice GUI interface, worked well with Visual Studio and was “free” being a part of Visual Basic and/or Visual Studio.
There were other repository tools. David cites IBMs Component Broker which helped extend CORBA compliant systems to legacy applications like CICS, IMS, and other OS/390 and AIX systems. The Byte article by Karen Watterson (see references below) mentions Component Brokers predecessor AD/Cycle and Visual Age Team Connection. In contrast to AD/Cycle, Team Connection was built on an Open API and had source code compliant connections to CVS, Visual Source Safe, and other source control systems. I fact Team Connection became the prototype for a new direction in repositories (see below).
The other influential repository of the late 1990s was Unisyss Universal Repository-URep. Like Microsofts Repository, URep was based on an extensible metamodel and databased (using Versants Object database); but unlike Microsoft it embraced a wide range of object types including database, COM, CORBA and others. As well, like IBM, URep supported a number of versioning system and data interchange methods. Also UREP ran on Windows, Unix and mainframe servers. However, even with these advantages, URep and most of the repositories would undergo radical transformations in the coming few years.
Both David and Karen hint at some of the fundamental problems confronting repositories. For example, David states ” although most component based applications are centralized on backend servers, the components themselves are distributed across many different platforms” . Karen cites the high costs and wide variation in repository functionality. And in fact, there is an almost unspoken Central Functional Trap involved in and creating the need to transform repositories.
The Central Functional Trap
Above we see the model of complexity that the current developers of the URep-Universal Repository, Adaptive Inc., see for IT development. In effect, development is a quite complex process. And each stakeholder in the system has different perceptions as to what are the key factors in the process. And those different visions of what are the key factors for development lead to different demands on either a Software Development Repository or a CASE-Computer Assisted Software Engineering toolset for that matter. This leads to what I call the Functional Trap of Centralized Development Repositories and CASE tools. As we can see from the diagram , a repository (or centralized development tool)can mean many different things to the many different stakeholders in IT development, deployment, maintenance and operation.
As well, so much money is spent on such tools that a repository must deliver on such broad expectations. Of course it will support project management interfaces, version control and backup, several heterogeneous object and component types, multiple languages and their frameworks, templates building, modeling display, change management, requirements collection, component monitoring with performance analysis, and on and on – its a list of expected functionality positively Gulliver-Brobadingnangian in proportions.
Yet to build such a Brontosaur brings all the inevitable problems:
1)complex to install and operate;
2)very hard to learn and/or remember how to use;
3)difficult to customize and adapt to our specific requirements;
4)never quite up to date as operational teams do not want to do double and triple data entry;
5)too limited in scope; does not even handle many of our key development objects/artifacts;
6)too large and too costly to maintain especially given marginal returns.
These, by the way, are some of the problems identified with the Microsoft Repository. But I have found equivalent Wailing Walls on the Web for Rationals Requisite Pro, Telogics Tau, and any number of other “central development tools”. This is the Central Functional Trap.
In fact David foresees some of these problems and the transformations taking place in repositories to meet some of these. first they would become distributed to where the problems were. Second they would use emerging XML standards (basic XML as well as XMI-XML Model Interchange). Third they would become like URep or Sybases PowerSite with the latters “ability to deliver multiuser component management using a relational database as repository … defining HTML and Scripts as well as ActiveX and Java objects as components” – not only open in support of a broad range of technologies but also distributed across OS/hardware platforms.
References
Evolving Software Repositories – what US NIST s doing in the general repository arena
Data Foundations has OneData to establish “a single version of the truth” for data and database resources. Data Foundation uses a sophisticated combination of metadata, business rules and ETL agents to maintain both a development but also deployment standard for an organization. This allows for distribution through versioning, distribution and replication with stratified standards within a consistent defining framework.
Karen Watterson The Road to a Universal Repository – defines in very clear terms the trends in repository development circa mid-1998 and highlights some of the key player including