Re: [ontolog-forum] Architectural considerations in Ontology Development

["Barkmeyer, Edward J" <edward.barkmeyer@xxxxxxxx>]

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.

 

> 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.

 

-Ed

 

 

--

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."

 

 

 

 

>

> --

>

> 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

>

>

>

>

 

 

_________________________________________________________________
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)