TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: All
from: Mike Bilow
date: 1996-03-19 13:57:38
subject: A NEW STRATEGY FOR VISUALAGE AND VI

* Forwarded (from: Netmail) by Mike Bilow using BilowMail0.2.
* Original dated: Mar 19 '96, 11:02

From: get{at}apt.usa.globalnews.com
To:   

           A NEW STRATEGY FOR VISUALAGE AND VISUALGEN

IBM is integrating and adding to its Visual tools, but a lack of 
focus could still leave them in application development's second 
division 

It is IBM's way to let slip hints and winks about new products 
and strategies months - and in the worst cases, years - before 
they see the light of day. Recently, IBM has been spreading a lot 
of stories about a project called San Francisco. This appears to 
be a project to bring some order to IBM's disparate object-
oriented, development strategy.

One component is a agreement with JBA to co-operate on 
technology.  Another is the news that VisualAge - IBM's 
Smalltalk-based development environment - and VisualGen are to be 
more closely integrated.  Other products are to find a more 
conhesive role within the strategy and there will be some 
completely new products. But trying to divine exactly what is 
going on and the possibilities of market success for IBM are not 
easy.

                        THE STORY SO FAR 

VisualAge and VisualGen have developed significantly since we 
last reviewed them a year ago. The question is: have those 
developments been significant enough? The short answer to that 
question is probably no. According to Steve Barrie, co-author of 
Bloor Research's forthcoming 2nd Generation Enterprise 
Client/Server Tools: An Evaluation and Comparison, "both 
VisualAge and VisualGen are well-engineered products which are 
competent rather than outstanding.  Neither could be described as 
a market leader."

The particular strengths of the two products, as identified in 
the Bloor Research report, are repository and language 
capabilities in the case of VisualGen, and the development 
environment and OO capability in VisualAge. All of these merited 
scores of 8 out 10. To put these figures into perspective, this 
meant that VisualGen's repository tied with Progress 8, Seer*HPS, 
Dynasty and SNAP but was behind USoft Developer, which scored 9. 
VisualAge's development environment tied with eight other 
products and was behind Neuron Data's Elements Environment, which 
scored 10.

In terms of language or OO facilities, in addition to ties, both 
products were outscored by three vendors who were awarded 9 and 
NatStar (formerly NS/DK-2) which rated a 10. In other words, 
neither product is a leader in any of the eight categories ranked 
in the report.

The problem is that the enhancements that have been implemented 
do no more than maintain the products' relative positions in a 
highly dynamic market. Given that the number of competitors in 
the 2nd generation client/server tools arena is increasing, this 
means that other vendors are continuing to encroach on the 
existing IBM user base, while VisualAge and VisualGen are not 
having the same success on other platforms.

The reasons for this are not very hard to find. VisualAge has 
been positioned, by IBM, as a client focused tool. This means 
that it tends to compete with the likes of PowerBuilder and 
Sapiens Ideo. In fact, it is probably as likely to face 
competition from down-market products like Visual Basic or 
Borland's Delphi. Yet VisualAge provides a more complete 
development environment than either of these and, in terms of its 
scalability, in particular, VisualAge should certainly be 
considered in a bracket with products like Dynasty or CA-
OpenROAD.

VisualAge has achieved a reasonable degree of success. However, 
it is mostly used in environments where client front-ends are 
being redeveloped rather than in building whole new systems. The 
reason for this is directly attributable to IBM's positioning of 
the product, despite the fact that it is perfectly capable of 
building entire applications. Although one would hesitate to 
recommend using it for very large enterprise-wide systems, it 
actually scored 6 out of 10 in the Bloor Research category for 
scalability, which puts it on par with Oracle's 
Designer/Developer 2000, Informix NewEra and Compuware's Uniface 
6.

VisualGen has different problems. In the first place, it was 
designed as a replacement for IBM's CSP (Cross System Platform) 
4GL product.  As sales of this product in the UK were dismal it 
is hardly surprising that there have been few takers for 
VisualGen. Indeed, Graham Cunningham, who is IBM's leading 
VisualGen guru in the UK, spends half of his time in Minsk, 
Turkey and assorted locations in Eastern Europe where, 
apparently, CSP was rather better received and VisualGen has 
achieved corresponding success.

                        THE RELATIONSHIPS 

One of the big problems in understanding and reviewing VisualAge 
and VisualGen is their relationship to one another. The fact that 
VisualGen generates VisualAge Smalltalk code for application 
clients would suggest that they are tightly integrated but, in 
fact, they are not. In addition, it is difficult to imagine 
anyone wanting to develop a new application without having access 
to the client code that is generated. But this is precisely what 
VisualGen gives you. You could license VisualAge separately but 
any changes you wanted to make would not be reflected back into 
VisualGen.  

In other words, neither VisualAge nor VisualGen solve the 
client/server issue. According to Barrie, "IBM's products are 
both very good at what they do. That is, they address client 
processing and server processing respectively. Unfortunately, 
customers want a whole solution not a part of one. Our 
recommendation would be that IBM should integrate the two 
products as a matter of urgency." 

As it happens, this is precisely what IBM intends to do. At some 
point in the summer of 1996, VisualGen is due to become the 
VisualAge 4GL. Despite the nomenclature it is apparent that it is 
actually VisualAge which is being integrated with VisualGen, 
rather than the other way round. Barrie considers this an astute 
piece of marketing, "VisualAge, with its object-orientation and 
GUI characteristics, has a more modern image. VisualGen, with its 
association with legacy systems and earlier development 
traditions, lacks the glamour of VisualAge as a name." Actually, 
it would be more correct to say that VisualAge is being 
integrated with VisualGen TeamSuite. And this represents a fly in 
the ointment.  VisualGen TeamSuite was first announced in 1994 
but its first component, a link between VisualGen and Team 
Connection, was not released until December 1995, while the other 
major component, DataAtlas, was only due for release last month. 
This does not bode well for the target integration date.

Of course, IBM has a long tradition of failing to meet its 
release dates. However, if it fails to do so with the integration 
of VisualAge and VisualGen then it could lose significant 
credibility. The market for these tools is very dynamic at 
present and IBM could irretrievably lose any claim to being a 
significant player if it does not meet its own schedules.

The new components of VisualGen TeamSuite are illustrated in the 
diagram. DataAtlas is a CASE tool which concentrates on data 
rather than process modeling, while Team Connection provides a 
repository which acts as the binding agent for the whole 
development environment.  There is also a Business Requirements 
Tool planned, which will integrate with Team Connection. Further, 
IBM has licensed Software One's middleware product to provide a 
CASE bridge for importing third-party CASE models. It should be 
noted that VisualGen, like many of the tools in this market, can 
use data modeling to advantage.  IBM, like many of its 
competitors, has never seen any particular value in doing further 
CASE work, such as process modeling, in conjunction with the 
VisualGen product, since the functions of such models is subsumed 
by the product itself.

                         TEAM CONNECTION 

Team Connection is based on the ObjectStore object oriented 
database management system. It is symptomatic of second 
generation client/server tools in that the market, as a whole, is 
moving towards repository driven development. As one would 
expect, the advent of Team Connection allows IBM to offer change 
and configuration management in a manner that is essential if its 
tools are to be used in enterprise-wide multiple-developer 
environments.

Team Connection also represents the glue that will enable the 
integration of VisualAge with VisualGen. Here, however, there is 
a difficulty. VisualAge for Smalltalk, the original product, has 
its own repository. This is licensed from OTI who market the 
product as Envy/Developer. This is specifically designed to be a 
Smalltalk repository and, as such, IBM has no desire to replace 
it. However, this means that a two-way bridge must be built 
between this repository and Team Connection. This could hardly be 
described as an elegant solution to the question of integration.

IBM has released a number of VisualAge products for different 
languages. The first of these was Smalltalk and, subsequently, it 
has have provided VisualAge for C++ and VisualAge for Cobol.  It 
is expected that other versions, for example for PL/1 or Basic, 
may appear in due course. This, in itself, is not a concern. But 
these other versions of VisualAge will be directly integrated 
with Team Connection rather than via a bridge between the two 
repositories. Thus, the later additions to the VisualAge product 
line will actually offer more attractive development 
environments, in that they are tightly integrated, than the 
flagship Smalltalk version.

Yet another confusion is the pending introduction of ObjChart.  
This an object-oriented CASE modeling tool that is intended to do 
for VisualAge, what DataAtlas does for VisualGen. This would be 
good enough, however, ObjChart is intended to provide a complete 
model-driven environment which can generate VisualAge 
applications (either C++ or Smalltalk) directly from the defined 
models.

There are two problems with this. First, VisualAge has been 
positioned as a product in which development is largely driven by 
construction from parts. That is, the developer uses class 
libraries in order to build his application, reusing parts as and 
when necessary.  While this approach is compatible with data 
modeling it is not commonly associated with a full-scale CASE 
approach.  

According to barrie, "the market for 2nd generation client/server 
tools splits quite clearly into three categories." There are 
vendors with object-based approaches which can be best classified 
as grown-up 4GLs, there are true object-oriented tools which 
build from components, and there are model-driven approaches.

VisualAge has always been regarded as in the second category.  It 
is quite a departure to try to move into the third. Only Seer*HPS 
offers a comparable choice of approaches." In other words, IBM 
appears to be trying to back two horses in the same race.  
According to Eric Woods, senior consultant at Ovum, "ObjChart is 
a technology that could shape the market and, if IBM can get a 
coherent message across, then it will hold a very strong position 
in the market". The danger is that a two-way bet means dilution 
of effort, and market positioning, in both areas.

                   WHAT CHOICE OF METHODOLOGY 

Another concern is the methodology to be employed. Of the various 
CASE methodologies that have been defined, only Shlaer/Mellor is 
specifically designed to provide code generation directly from 
object models. Other methodologies may provide some code 
generation capability but one would not expect to generate an 
entire application solely from those models. In order for 
Shlaer/Mellor to do so it is necessarily rather prescriptive and 

--- 
* Origin: N1BEE BBS +1 401 944 8498 V.34/V.FC/V.32bis/HST16.8 (1:323/107)
SEEN-BY: 50/99 78/0 270/101 620/243 711/401 409 410 413 430 808 809 934 955
SEEN-BY: 712/407 515 517 628 713/888 800/1 7877/2809
@PATH: 323/107 170/400 396/1 270/101 712/515 711/808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.