| Pete Dashwood 2006-04-29, 9:55 pm |
|
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:4bfhalF10vcacU1@individual.net...
> any
> all
>
> Well, in our case the company choosing the applications and the company
> developing the applications are the same company. So to us the language
> does matter. Is this not the case for many "COBOL shops"?
>
I['ve mentioned this before but it may bear repeating...
1. The cost of software development is getting out of hand. (Why do you
suppose we have seen such a huge upsurge in getting it offshore? Even this
solution will eventually reach meltdown.) Companies are being forced to
outsource their IT solutions and concentrate on their real business. The
luxury of running an in-house IT department is becoming less and less
viable. When this department seems to miss delivery dates, is not responsive
to dynamically changing business environments, and delivers today, what was
actually needed 9 months ago, the patience of the Business rapidly wears
thin.
2. More and more corporates are seeing the "IT department" as having little
or no development role. Their function is to keep the network running,
install OS upgrades, and ensure the safety of corporate data. Applications
are being bought off the shelf or configured by end users.
(More and more I am seeing IT people wailing and gnashing their teeth
because some user department came up with a spreadsheet solution that
obviates the official application being developed by IT. Investigating this
and why it is happening we find the following:
1. They have been waiting for an IT solution for way too long.
2. There is more computer literacy on the shop floor than there has
ever been and it is increasing every day.
3. The people in the Business know exactly what they need to support
their daily work, and it doesn't get filtered through a Business Analyst or
techie.
4. Some of them just want to have the fun of doing it.
Now, as IT professionals we can shake our heads and mutter about 'best
practices', 'proper procedure', 'integration with other systems', but it
cuts no ice on the financial bottom line. The Business is happy; the
accountants are happy, and it is only IT that has a problem with it. (What
IT professionals need to do about this is beyond the scope of what I'm
writing here, but you can bet it involves building a relationship with the
Business and making sure they are involved throughout any development. It
also involves working faster, smarter, and being dynamically responsive to
change, all things which IT has not been good at...))
3. For the reasons outlined above, the days of the "COBOL shop" (read, "IT
application development", because it isn't just about COBOL...) are
numbered. The ultimate goal is for application development to be so easy
that end users can do it. That wouldn't happen with the procedural model we
have been using for the last 40 years, but it is feasible with other
non-procedural approaches. This goal is getting nearer; users are getting
smater, tools are getting simpler (and more powerful). The future does not
belong to Java or any other programming language (the 'short term future'
may well do...); it belongs to smart applications that can be configured
quickly and easily by anyone.
OK, leaving all that aside :-) let's have a look at Frank's specific
point...
Does the language matter?
Yes...and no.
The traditional approach of a central shop where it makes sense to have
everything in one language so it can be easily maintained, is definitely
reaching its Gotterdammerung.
(There are differing requirements that need different languages. This means
different practioners, which pushes costs up and makes the bean counters
look again at the viability of in house IT development... see above.)
Should such a shop press on with COBOL, knowing that the language itself is
facing oblivion and support for it is definitely in doubt, or should a
switch to 'soup du jour' (say, Java...) be made?
Obviously, I cannot answer that here (I offer consultancy for a living...
:-)) and it will depend on the individual cases anyway.
Here are some things that need to be thought about and discussed in any such
shop:
1. What is the short term and long term future for our department?
2. Do we need support and maintenance of our development environment or can
we manage with what we have for a few years yet?
3. What is the state of our existing applications? Are they stable or are we
spending a heap of time in maintenance?
4. If we go to another language, how much of what we have can be
'refactored' or converted?
5. Are we delivering to the Business in a timely and effective manner? Will
a new language help us ot do that?
6. Should we change our development practices and Project methodology to
something smarter and more responsive? How will the new language help us to
do that?
7. How will the new language set the company up for the future? (For
example, if you go Java will you also go to OO formally? Objects and
components are likely to serve the company better in the future than
thousands of lines of procedural code, but it needs to be thought about and
assessed.)
That's enough to be going on with... :-)
Good luck,
Pete.
|