Ed: +1
But those changes make the IT staff job
very uninteresting, with short training lifetimes on commercial products, and
turn an engineering task into a service task (think “want fries with
that?”). That is why, IMHO, a smaller percentage of people go to
college and major in engineering and computer science.
On the positive side, those trends are
making business processes more and more productive, with higher levels of
productivity for most employees.
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Barkmeyer, Edward J
Sent: Friday, February 22, 2013
12:25 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Architectural considerations
inOntology Development
> Sadly, monolithic applications too often dominate the
focal points of decision
I'm not sure that is "sad". In most
organizations that is vastly better than separate systems for separate
fiefdoms, and the uneducated judgment of some manager that he can do in ExCel
what the company bought a financial system for.
> It's so bad that individuals and enterprises are
> (today) purchasing computing devices en masse for
which (as owners) they
> don't even posses 'root' privileges.
I think this means that corporations acquire and install
lots of computers for workers who lack the privileges to do system
administration. And that is certainly as it should be, because (a) these
people don't have the specialized knowledge to do it, and (b) they should not
have the need to do it. Unfortunately, the providers of much of the
packaged software have not grasped this fact -- they have tried to automate
installation and update processes so that the user doesn't need the systems
management skills, but assume that the user has the privileges he lacks the
skill to use wisely. (In part, this is a consequence of the system
requirements for implementing the "Windows look and feel".)
> Saddest of all, programmers now totally dominate
dialog about computing.
In some geek forums, perhaps, but that is an insignificant
part of the dialog. The local real estate agents and the nurses in the hospital
and the used car dealers are quite able to talk about the computer systems they
use in their daily work, and they are not programmers. And the managers
who chose and bought those systems are not programmers and don't talk with
them. The programmers are a handful of elves in the woods who have little
influence on any decisions about corporate computing. They just get the
job of installing the chosen products and making nice screen views for upper
management.
And OBTW, this is a good thing. Computers in
business and industry are tools, and they are (finally) considered to be tools,
not hobby kits. As Steve Fenves, a former Mechanical Engineering chair at
CMU, observed, "we are finally teaching engineers how to use
computers instead of how to program computers".
> What happened to systems analysts, database
designers, ontologists etc?
They are well paid consultants or "marketing
support" staff for software houses. The in-house analysts in
industry now have different titles: Enterprise Systems Coordinator, and the
like. For the most part, their job is to configure or modify an
off-the-shelf model into one suitable for supporting their operational
practices. Many "systems analysts" are now called
"business analysts" or "enterprise analysts", because their
job is to figure out how the organization works, what needs to change, and how
best to support the target operations practices with mostly off-the-shelf
software systems. Even big companies have spun off most of their software
shops, because they are not core competencies and they rarely provide more than
indirect support for revenue producing processes. A lot more attention is
paid to the source and quality of software that directly implements revenue
producing processes, like operations scheduling, equipment control and online
purchasing. And that requires specialized knowledge and skills, which is
better purchased from a reliable contractor. IMO, this is as it should
be. Shell Oil doesn't build pumps, Tokyo Electric doesn't make turbines,
hospitals don't make dialysis machines. Why should they build software
systems?
> I believe applications are like fish and data like
wine. The world (in the
> majority) still doesn't understand what data actually
is, let alone the
> fundamental implications of such dangerous ignorance
:-(
I agree 100%. But that has been so for 50
years. The main failing of the period from 1960-1995 was trying to
understand a problem space in terms of an implementation paradigm. Today
fewer analysts are being asked to design a solution, because the company
intends to buy the solution, or at least the major building blocks. What
they want the analyst to do is document the real requirements for the capture,
archive and delivery of information. They understand "data" as
the information they will use and how they will use it, rather than what the
system will do to/with it. And that is a major step forward.
Edward J.
Barkmeyer
Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Systems Integration Division
100
Bureau Drive,
Stop
8263
Work: +1 301-975-3528
Gaithersburg,
MD 20899-8263
Mobile: +1
240-672-5800
"The opinions expressed above do not reflect
consensus of NIST,
and have not been reviewed by any Government
authority."
> Twitter/Identi.ca handle: @kidehen