|
On 2/22/13 3:24 PM, Barkmeyer, Edward J
wrote:
Kingsley Idehen wrote:
> Sadly, monolithic applications too often dominate the
focal points of decision
> makers and developers.
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.
I mean:
it's a bad thing
to have apps as data silo vectors.
> 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".)
I am referring to the fact that organizations
and people are acquiring iOS5
tablets and phones for which
they don't have 'root' access.
> Saddest of all, programmers now totally dominate
dialog about computing.
In some geek forums, perhaps, but that is an insignificant
part of the dialog.
I think most of the
Web dialog is dominated by programmer thinking. I like this
forum because it's one of the few
places where conceptualization and
modelling are key topic drivers.
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.
Correct,
because (and this
is a long story, so I am giving
the short answer) they've
abdicated the prime role of actually taking data literacy seriously.
Computing is all about data processing, as you
know :-)
The programmers are a handful of elves in the woods who
have little influence on any decisions about corporate
computing.
Not so
since the advent of the Open Source era. An unintended consequence, so to speak.
They just get
the job of installing the chosen products and making nice
screen views for upper management.
Pre
Web, maybe, In my experience these days -- it's all about code first and programming
language
oriented religious wars.
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.
Yes, but
the hobbyists are now the
enterprise developer + architect of yore. Sadly, the are rarely
good at real programming and non starters when
it comes to architecture.
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".
I wish
that was my experience. That's exactly how it should be, but not what
I come across in my travels, unfortunately .
> 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?
That's how it
should be, but the folks you describe
aren't part of the major dialogs
that occur on the Web, certainly not in the
quarters that I frequent.
> 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.
Yes, but we have the
eexponential effects
kicking in these days. Thus, really bad stuff
ends up affect a lot of people etc..
The main failing of the period from 1960-1995 was trying to
understand a problem space in terms of an implementation
paradigm.
Yes!
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.
I wish the ccompanies thought in terms of
"blocks" as that would certainly reduce the
problem I am gripping about.
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.
Yes, but still not
the dominant
case I experience though :-(
Kingsley
-Ed
--
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."
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Twitter/Identi.ca handle: @kidehen
>
>
>
>
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
|
smime.p7s
Description: S/MIME Cryptographic Signature
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|