| Clark Morris 2006-10-30, 9:55 pm |
| 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@enternet.co.nz> wrote:
>
>"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
>news:4bfhalF10vcacU1@individual.net...
>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 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...))
This seems good but I truly question whether a spreadsheet 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 spreadsheet, 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.
>
>
>
|