On 8/11/2013 9:34 PM, DrFranken wrote:
I am curious what is YOUR view, the view from your seat of the most
important challenge facing your shop, possibly you personally. What is
that largest 'going forward' challenge in the next year? 2 Years? Big
or small but most important, look forward, what IS that light at the end
of the tunnel attached to??
Our platform is universally perceived by other people in our company as
a relic. This is the baseline for all of our interactions with other
departments. This reputation didn't spring up overnight; it was
gradually cemented in place brick by brick as the end users asked for
things they were told were too hard to implement. 'Oh, that's a
database change, very large project.' 'Oh that requires mixing Excel
and DB2, very tricky.' 'Oh we can't handle large memo fields like
Excel, sorry.' 'Oh we need you out of the customer care system so we can
run end of month.' (CLRPFM / batch work requires locks) There are a
thousand 'No!' replies for every 'Yes, I suppose we can. If we have to.'
Our end users have created their own 'databases' - typically Excel
spreadsheets. When asked how many customers we have, every department
has a different answer - which they all swear is correct. Meanwhile,
the DB2 data gets progressively worse and worse, as people neglect
updates. Why do double entry when THEIR data is the one they are using
as the 'database of record'?
Like everyone else, when the web became de rigeur, our company climbed
aboard. Like everyone else, our executives were terrified to put 'the
as400' online. 'What if a hacker gets our customer data? We'd be
destroyed!' And so the web developers were hired. SQL Server, some
packaged CMS to put info up on the web. And FTP to move files between
DB2 and SQL Server. Because stored procedures were 'too hard'.
The future isn't grim because of green vs GUI or web vs thick client or
lack of RPG programmers. The future is grim because have made ourselves
as irrelevant as spoken Sumerian. The end user community EXPECTS that
we cannot handle their problems and they have pretty much stopped
asking. Which leaves my immediate management in a pickle as they
contemplate the next 5 year plan.
I believe that we as a community have some structural problems. There
aren't nearly enough Nathan's and Scott's in our midst. We as a
community can't sustain a discussion on agile techniques, can't
understand how an editor with regular expressions could be useful and
worry that journalling files for commitment control will kill performance.
But those things can change! A smallish number of us can implement
various IBM APIs at will. This opens the door to writing our own
applications as APIs, or services - hey look! Software As A Service, one
of the latest buzz-words. We've been doing it all along. A number of
us have implemented various Java APIs and given working examples (thanks
Scott!) extended existing code. We aren't up to the point where we have
a thriving midrange open source community, but there are several well
established open source projects.
In my opinion, we as a community need to become more familiar with
mainstream computing theory and practice. With a few exceptions (Why
doesn't our DB2 geocode? Why don't operational descriptors handle every
data type? Why can't we define NULLable variables in an RPG
sub-procedure?) our platform is magnificently positioned to handle
future needs.
Men at some time are masters of their fates:
The fault, dear Brutus, is not in our stars,
But in ourselves, that we are underlings.'
Cassius, Julius Caesar Act I, scene ii
--buck
midrange.com
