From Conceptual Architecture to Practical Services:

Download Report

Transcript From Conceptual Architecture to Practical Services:

Portal Design for
KM Applications
A case study for dialogue at the
AIAA Delta Forum, Jan 2006
Edward Ng and Rebecca L. Nash, JPL
The
NASA way
The wrong way
The right way
My way
January 2006
EN/RN
2
In The Beginning – circa Y2K
January 2006
EN/RN
3
Identify & Define Service Needs
 If it’s free, customers want everything
 Money is the best prioritizing catalyst:
– Either indirect costs through overhead
– Or direct charge-back
 Several major needs percolated to the top:
– Managing, “owning” data
– Access control and security (authentication, then
authorization)
– Indexing, searching, and browsing
– Customizing to curb information overload
– Organizing, publishing, and navigating the intranet
January 2006
EN/RN
4
Jump Start the Services
 Typical prototype phase involving 100 to 200 users
 Usually start with home-grown or freeware pilots to
get users 1st hand appreciation
 Then followed by customer survey, tech eval, req
analysis, infrastructure analysis and procurement
 Service gradually grows to enterprise scope of
5000 to 6000 users
 At some point CIO had to decide on indirect vs.
direct charges
January 2006
EN/RN
5
Practical example : portals
Circa
2000
NASA prototype (2002)
JPL portal (2002)
NASA (external) portal (2003)
Inside NASA portal (2004)
Present development of
– flight mission portals and
– community portals for knowledge capture
– people connections
January 2006
EN/RN
6
Project Representation at Every
Information Domain
External
NASA
In-reach Team
Outreach NASA Inreach
January 2006
EN/RN
7
Snapshot of JPL Intranet Portal







~6000 users
CIO burden funded
Average 140,000 page views per week
About 11 M hits per month
103 Channels (portlets)
70% use generic (non-personalized) version
Available 24 X 7
January 2006
EN/RN
8
January 2006
EN/RN
9
Lessons Learned
 Growth of an information service is gradual
and executed in phases – “big bang”
approach is not viable
 It’s more bottom up (inductive) than top
down (deductive)
 There has to be CIO-level commitment
 There is always a possible distraction called
the latest technology on the horizon
January 2006
EN/RN
10
Lessons learned (2)
 There is a normal curve on customer capability:
the top 10% don’t need help, and the other
extreme needs extra help. So you target the
middle 70 -- 80%
 Customers like a real-life advocate behind the IS
 At the EC level – help them see a broader horizon
on IT; see their own niche in the knowledge space
 New generation is much more IT savvy
 Various levels of commitment of channel providing
 “The messenger is always blamed!!”
January 2006
EN/RN
11
Summary
 We started with a conceptual framework
 A team of six pioneers (Jeanne became our Chief
Knowledge Architect)
 Then came prototypes & pilots
 Those that remain grew into enterprise services:
e.g., portal, ELS, KnowWho, Directory
 We then promoted awareness lab wide
 Q&A
January 2006
EN/RN
12
Engineering & Technology Management Group
Questions on this Session?
Exchange: What technology tools improve (or could improve) your knowledge discovery and exchange?
Folder
January 2006
EN/RN
13