Remember AD/Cycle? If you're thirtysomething, chances are you do. Eyewitness accounts vary, but basically it was an attempt to tie all application development and design efforts together using a common repository. Although there are still some AD/Cycle hopefuls today, it never really came to be.
AD/Cycle was part of IBM Corp.'s (Armonk, N.Y.) System Application Architecture (SAA), which was defined in approximately 1986. SAA was an effort to integrate all IBM computer and operating systems. It defines a standard user-access method, standard programming interface, and a communications link. In support of SAA, IBM defined several frameworks. AD/Cycle was one of the first frameworks and defined the CASE strategy for SAA. AD/Cycle was intended for use with a number of third-party tools, using a mainframe-based Repository Manager metadata storage facility. Several vendors, including Intersolv Inc., KnowledgeWare, Bachman Information Systems Inc. (now Cayenne Software Inc. following a merger with Cadre Technologies Inc.), Synon Inc., Systematica, and Easel Corp., jumped on the AD/Cycle bandwagon. The bottom line is that those who evaluated Repository Manager returned it in frustration.
I became aware of AD/Cycle early in my career as I began to teach systems analysis and design and database design at a local college. I was always a big proponent of common design repositories, and with the advent and popularity of CASE, it looked like AD/Cycle was a prime mechanism to allow different design and development environments to share information. What's more, AD/Cycle was a way to reach the nirvana of system development -- design and application component sharing and reuse (something we have yet to achieve).
Although today we are largely still repositoryless, many movements are afoot, and most of them are proprietary and linked to a particular tool. For example, Allegris (Intersolv's application-partitioning tool, which I covered in my column last month) comes with its own object repository. Powersoft PowerBuilder's Extended Attribute Set is another repository linked to a tool, but this one also provides a mechanism for other third-party tools to enter and extract design and application information. For instance, Logic Works Inc.'s ER/Win and Rational Software Corp.'s Rational Rose CASE tools can all link to PowerBuilder's Extended Attribute Set.
So where is this all leading? Microsoft Corp. also has its own repository bundled with Visual Basic 5.0. Although this repository is largely bound to Visual Basic, Microsoft is promoting it as an independent product with an open interface and capabilities beyond those found on other repositories. It is certainly worth a closer look. This month, let's drill deeper into Microsoft Repository 1.0 to see if it could be what AD/Cycle never was, or what AD/Cycle should have been. You be the judge.
The idea behind the MR is to share design and component information among design and development tools. Most CASE tools support some sort of design data exchange (such as CASE Data Interchange Format [CDIF]), and most don't let application architects and developers view or process the information, nor do they manage dependencies among models and tools. For instance, although you can define and share a data model between ER/Win and Popkin Software and Systems Inc.'s System Architect, they cannot share the same model concurrently, and tool integration is difficult.
Some development tools are able to work with some CASE products, but most CASE tools provide only a one-way trip from CASE tool to application development tool. For example, you can create the database and interface design using a CASE tool, then send it to the application development tool's repository. Typically, it's not a good idea to move the application information back into the CASE tool, because it's almost impossible to keep both the CASE tool repository and the application development tool repository in sync. I've seen many a project hindered when developers and application architects attempted to move application information from the CASE tool to the application development tool and back again one too many times. My experience is that you have one shot, so get it right before you send the design to the tool.
A true repository is supposed to address most of the existing limitations while providing active storage of application information contained in object models, database models, and even application components. MR is able to provide an open information model describing objects and relationships of an application as well as a mechanism for building on the information model. This provides application architects with the power to evolve an application design over time. In addition, MR provides a set of well-defined interfaces for manipulating the design information in the repository and a shared database spanning many application models that provides relationships between the models through links.
The idea is to store the model and the descriptive information together. The repository is able to hide the information behind the interface and therefore enable tools to evolve data when the information model changes. The tools view only the information model and not the physical schema.
MR gives developers and application architects the ability to build complex information models using different application domains (components, OLTP applications, or data mining applications). The models link together using shared interfaces. The interfaces define how the repository object and descriptive information interact. Therefore, you can have a truly tool-independent application design with models that span several tools.
MR ships with Visual Basic 5.0, but it's really a standalone product destined to span many Microsoft and non-Microsoft tools. MR exists to lure in other third-party tool vendors to create new products or modify existing products to use the MR interface. So far, Logic Works, Rational, and Texas Instruments have all declared support for MR with product migration. Many other vendors are heading the MR direction as well (Microsoft is naming approximately 20).
In addition to sharing design information, MR lets you share and reuse components. MR does more than just serve up components like Web servers do; it is able to bundle the component with the design information as well. For example, not only can you access an accounts-receivable component to snap into your application, but you can also access the associated object model as well. Thus you can use the component "as is" or modify it to meet the exact requirements of the application, using the object model as a frame of reference and a means of evolving the component over time. For example, a tool is able to share a component with another tool, because the information model is common and sharable among the tools. (See Figure 1.) The tool communicates with the repository using a common API, allowing the tools to access and process the descriptive information and thus employ the component with linked design information.
As you may have guessed by now, knowing Microsoft, objects exist in the MR as ActiveX components. A developer using an MR-compliant tool uses the interface to the object to associate properties of the object as well as to define relationships with other objects that are stored in the repository. If that's not as clear as mud, you'll find it easy to understand that a repository object defines itself in terms of the interfaces that it exposes to the outside world (tool, developer, application architect). The interfaces exposed define an object's state as well as how tools can manipulate the object. An interface has properties, methods, and relationships to other interfaces. To me, this looks a lot like the Microsoft COM interface.
As with most repositories, an underlying database stores and manages the physical repository data. Many repositories use object-oriented databases because of the complexity of the data that exists in a repository; however, Microsoft is opting for a relational database for the repository. You can use a true database server or a desktop database. This means that you can scale your repository to support just a single developer or to support hundreds of application architects, developers, and even project managers. The team development capabilities are innate to MR because of the natural sharing of information that shared repositories provide. However, you'll need to integrate a code-control system such as Microsoft's SourceSafe to handle version control just as you would with any other repository-driven development tool.
Logic Works is also supporting the MR and is currently demonstrating a bidirectional link that integrates ER/Win database models with the MR repository. Developers can use Logic Works' popular database modeling tool to define the logical and physical database schema, storing the information in the MR. Developers and application architects will then have the ability to combine that database design information with application design information generated by tools such as Rational Rose. These CASE tools are the heavy hitters in the client/server world, and I'm sure they'll put some momentum behind MR.
So what hoops will you need to jump through the adopt this? I would not recommend that you head this way unless you're currently a VB developer, and if you are, VB 5.0 will provide the migration facilities. Remember, this is not a code-control mechanism, but rather a sophisticated mechanism to link models to implementations. Application architects could derive the most benefit from this repository, because it permits the sharing of models. The trick is to find tools that the repository supports. Although some key tools do, most don't.
The few issues that I have with MR relate to most Microsoft development products. First of all, MR is really relevant only for a Windows environment. Although most of you out there run Windows, a few organizations still find the use of Windows repugnant. Second, Microsoft needs to include more development tool support. Most CASE tool users will find value in working with MR, but the real value of MR is when I can have several CASE tools share repository information with several development tools. Think about that for a moment. It's not clear to me whether Microsoft is willing to promote the use of other development tools. However, with the open interface, it's easy for other tools to support MR.
I have high hopes for MR. I hope Microsoft doesn't lose sight of the goal of providing a common repository rather than a proprietary mechanism to protect interests. If the company succeeds with MR, everyone will beat a path to its door -- including me.
