Greetings to the List,
Much of Wirt's QCTerm entry has been snipped, but I felt compelled to offer
some complimentary editorial....
Wirt writes:
> But precisely because of that, the pressure to develop "open systems"
> applications is also going to disappear. Efficiency and elegance
> are going to
> become the buzzwords again. Eschew heterogeneity. Promote simplicity.
I think it is worth adding that "adaptability" and "open applications" (NOT
OPEN SYSTEMS) are what large, multi-business, multi-geography organizations
are in need of. All of Wirt's points are valid (MOST OF HIS POINTS ARE
SNIPPED), and it's the openness and thus the adaptability of the application
which are critical to removing IT as the barrier to changing business
processes. When business events, such as acquisition, spin-off's, integrated
supply chains are introduced at the pace that new IF-THEN-ELSE clauses were
20 years ago, then it's not just elegance and efficiency - it's the speed at
which we can reliably change our applications.
>
> But it's also been my experience that middleware also has a
> relatively short
> lifetime before it too disappears. The same ideas that currently underlie
> CORBA and DCOM are exactly the same ideas that underlay device-independent
> graphics files fifteen years ago and device-independent
> word-processing files
> 25 years ago.
While I don't disagree with Wirt's perspective, I think we are in danger of
missing the vision embedded (if not buried) in middleware (and us vendors
who sell it). Middleware's intention was to introduce a natural layering of
applications. I think many of us would agree that a clean separation between
the data resource, the business logic, the end user tasks, and the
presentation are the goal, not the use of 4 platforms and 4 languages and a
bunch of middleware code. In my opinion it is the ability to move one layer
of your application to any platform (web, kiosk, mainframe, personnel
electronic device) which reflects on what middleware is supposed to be
about, not that you'd necessarily want to do it - but knowing you can, means
that the application is itself modularized into the natural logical layers
preached by object oriented methodologies.
Too often the simplicity and elegance of an emulation approach does not
factor into the account that the application code is still poorly structured
and difficult to change.
> But even during that period when the demand for middleware may
> seem high, it
> is still never much more than a marginal solution, a Band-Aid to
> patch over a
> mess, laced with a dozen unnecessary points of failure.
>
> Beginning with the terminal model and skipping all of this middleware has
> several salutary attributes: It is the most backwards compatible display
> client approach possible. It is, by its very nature, compatible
> with almost
> everything that has gone on before, thus there is enormous investment
> protection implicit in using a terminal emulator as a starting point.
One must account for what the internet, and the future un-anticipated next
generation of communication protocols and devices brings to the world -
expression and the freedom to express. Middleware, and the protection it can
provide to an application, allows for the expansion of what we know of as IT
shops today. Properly deployed, and properly encapsulated middleware
business API's can become the entry points for a great number of newly
developed expressive interfaces. One cannot guarantee that interfaces,
although simple and elegant, are or will always be within IT's control. If
Wirt makes QC Term so easy to use then it might be the accountant or the
claims clerk building the interface - any why shouldn't it be, why shouldn't
they be allowed to select the form and features of an interface that suit
their business process needs, their human interaction fetishes - after all
they've got to use it.
Middleware solutions have evolved a great deal, and CORBA and DCOM should
not be used as the measuring stick of adoption success. Point-2-point
middleware (like ORB products) do not allow for the dynamic qualities that
large self-personalizing applications need to become. Today customers will
re-engage in the market with suppliers of goods and services which make the
customer feel like the supplier has a personal hands on feel for the
customers wants and needs. Static interfaces, hard coded logic are not the
means to this end.
> Applications development used to be simple, easy and fast. We
> want to make it
> that way again, if not outrightly enjoyable. I also firmly
> believe that small
> projects have a very much greater chance of success than large,
> complex ones
> ever do. I very much want to encourage small IMAGE-based applications
> development on the HP3000, where something like a time-card
> collection system
> can be put together by the local staff in just a week or two.
>
> If we're going to plant trees today, I would rather help plant a thousand
> tiny saplings than try to jury-rig one massively large oak.
>
Here here. And I'd rather define some basic parameters for tree planting
and put tools in place that allow each and every person to plant a tree.
Jonathan van den Berg
Premier Software Technologies
|
