Development and offshoring was Re: IBM file status 97 (was: Prodcuing an output file onlyonFriday?

This is in response to a thread of a few months back and my comments
are interspersed.

On Sun, 30 Apr 2006 14:06:32 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxx> wrote:


"Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx> wrote in message
news:4bfhalF10vcacU1@xxxxxxxxxxxxxxxxx
Howard Brazee<howard@xxxxxxxxxx> 04/28/06 1:51 PM >>>
On Fri, 28 Apr 2006 13:20:53 -0600, "Frank Swarbrick"
<Frank.Swarbrick@xxxxxxxxxxxxxx> wrote:

Not to defend COBOL in and of itself. It's just I simply don't know of
any
other language that is better suited for financial applications. I would
love to have a language that has all of the strengths of COBOL but also
all
of the strengths of other more modern languages.

True. But I don't think many companies choose languages for
financial applications. We choose financial applications and take
the language(s) that come with them.

The application companies have different criteria for selecting their
language(s).

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.

I believe that organizations get the IT they manage for. As computers
become more powerful, the inefficiencies of packages using external
tables and mechanisms other than customized code to control processing
becomes less of a problem. 10,000 thousand cycles measured in
nanoseconds per cycle with overlapped processing is a lot less of a
concern than the same number of cycles where the cycles are measured
in microseconds with no overlap. The move to outsourcing IT however
is more questionable. The computer systems encode and implement the
organizational practices. While program coding by what ever method
(COBOL coding sheets with punched cards, drop down menus and the
latest shining IDE in Delphi, .NET, etc.) may not be the core
competence or need of the organization, controlling the way the
organization works definitely better be. If the IT department is
viewed as unresponsive, that may say more about the communications and
outsourcing may only exacerbate the problem. Now changes are visibly
billable. With outsourcing the people in IT definitely have a loyalty
to the provider and are a part of the provider's culture. Crossing
country boundaries can exacerbate the communication problem even if
the countries are the United States and Canada. Each level of removal
complicates the legal situation.

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 spread*** 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...))

This seems good but I truly question whether a spread*** application
developed as a side project in a using department has the same rigor
that the official application would. Little details like error
handling, making sure the inputs are correct, making sure that
organization policy about items is taken into account, etc. get in the
way. If the IT department is doing as bad a job as the department
creating the spread***, then there is no greater problem. Many
times IT has to be the mediator between/among departments. Just
because something looks right doesn't mean it is right. Bluntly
people in the business don't necessarily know exactly what they need
and these scattered applications may have a good effect on the bottom
line or a disastrous one. This is especially true in an era of PIPEDA
(privacy act in Canada), Sarbanes Oxley accounting system requirements
in the United States, Health information requirements in many
countries, etc. Understanding these requirements and making certain
systems comply with them is time consuming. These laws may require a
documented and structured way of implementing ALL information systems.
We are not there yet but somehow ad hoc production systems producing
data for making decisions don't seem to meet the need of the CEO to
know that a system is in place that can give him or her some assurance
that he can safely sign certification documents.

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.

Application isn't difficult because of procedural code or necessarily
something you want to leave to end users. Pathological events and
data have to be considered. Relationships have to be considered.
Coding is the easiest part. It is the analysis, research, control and
testing that is difficult. It is making sure the external reporting
and help is clear and that includes the manuals and other
documentation. (Yes, I know that IT has been less than sterling in
this regard but documentation and help seems to be an orphan
regardless of whether the user or IT has the responsibility).

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.



.