Trnsport Strategic Directions

1
Trnsport Strategic Directions

• Presented to the
• Trnsport User Group
• October 6, 1999

2
Trnsports Next Decade

• Serve not only traditional office workers, but
  also remote and mobile workers
• Provide complete functionality in all areas
  covered
• Extend functionality to related core
  transportation program management
• Be a part of the information world
• Be cost-effective to use, as well as to develop
  and support

3
Key Areas of Attack

• Infrastructure
• Information architecture driving software
  architecture
• Integration
• within Trnsport
• with foreign systems
• Functionality
• Extending current capabilities
• Broadening to new capabilities

4
Trnsport Today many components

• Family of three-tier components
• PES, LAS, CAS, and soon CES
• Similar three-tier client-server components
• BAMS/DSS (requires SAS interface server)
• SiteManager (different three tier)
• Stand-alone components
• Estimator, Expedite
• All must cooperate effectively

5
Issues with Todays Infrastructure

• Multiple software architectures
• Varying user interfaces
• Different customization facilities
• Specialized data interfaces
• No common user authorization (security)

6
Addressing the issues?

• Its an inevitable consequence of increasing
  functionality, so live with it.
• But we really dont have to.
• Rebuild everything on a common code base to look
  and act alike.
• That would take years (to say nothing of the
  cost). And maybe everything shouldnt work the
  same.
• Figure out the common foundation, and fit
  existing systems together better

7
Focus on Information Architecture

• Trnsport is a lot of information, with enough
  software and networking wrapped around it to make
  it useful
• Focus on Trnsports information architecture,
  rather than software architecture
• illuminates strategic challenges
• and leads to new approaches to solutions

8
Trnsports Information

• Relational
• CES, PES-LAS, CAS, BAMS/DSS and SiteManager
  databases
• Custom structured data
• Estimator and Expedite data files
• Other
• BAMS/DSS SAS reference data
• Embedded objects
• Report templates

9
Trnsport Information Architecture Today
10
Preferred Trnsport Information Architecture

• Single shared relational data store
• DB server for CPLCD and SiteManager
• Single shared object store
• Web server with extensions
• Local working copies
• With clearly defined mechanisms for synchronizing
  with the shared data stores

11
Preferred Trnsport Information Architecture
12
Changes from Existing Information Architecture

• Relational store is almost unchanged
• Move all SAS-only DSS data to same platform as
  all other data
• Object store replaces several mechanisms
• Shared network drive for SiteManager objects
• Database BLOBs for CPLCD objects
• Shared network drive for Report Templates
• Networked Estimator database
• New interface processor needed
• Standard way to synchronize working copies

13
Integration Issues

• Varied software architectures and user interfaces
• No global authentication and authorization
• Many-to-many connectivity
• Protocol Tower of Babel
• Local changes require global upgrades
• Proprietary interfaces make it hard for foreign
  systems to participate
• Intranet web clients expand these challenges

14
Three Platform Types

• Client/server
• DB to store information, client to present it,
  application layer for bulk processing
• Stand-alone (typically, file-based)
• Intensive manipulation of small amount of data
  (e.g., cost estimate, bid, daily diary)
• Needs to move data to and from central store
• Thin client
• Traditionally a terminal, now often web browser
• Great for casual and mass use

15
Client-Server Standardize on One Architecture

• P/L/C architecture robust and well-suited for
  this component
• Remove DSS interface server requirement
• Move SM batch server to same app server
• Replace custom DPS communication protocol with
  standard HTTP requests
• Goes through firewalls
• Wrap in SSL for superb wire security
• Use automated tools more easily

16
Stand-alone Connections

• These components must share information with the
  central data stores
• And often each other
• Instead of connecting everything pair-wise, use
  an interface processor
• Specialized web server that responds to data
  fetch and store requests
• Use HTTP for protocol, probably XML for data
  format

17
Benefits from Interface Processors

• Reduced user training and errors
• Interface operations are now one step and
  completely automatic
• Significant increase in Trnsports openness
• Relatively easy for foreign systems to connect
  to HTTP services using XML data formats
• Interfaces likely to be stable, as they are less
  coupled to core system

18
Thin Clients

• Client-server and stand-alone applications will
  never serve the entire agency
• Too hard to deploy. Too hard to manage.
• Support thin clients that are easy to deploy and
  manage
• Lots of options
• Web, X Window, Citrix, Sun Ray, MS Terminal
  Server, VNC, ...
• All reduce Trnsport cost of ownership

19
Thin Client Recommendations

• Support proxy clients for deployment
• No new code, though
• Test, remove any incompatibilities
• Implementation issue, not development
• Use web browsers for new functions
• Platform independent
• Universally available
• User friendly

20
Taming the Connectivity Matrix

• Reduce interactions between components to only
  two protocols
• ODBC for those pieces that must talk directly to
  the database
• HTTP for all others
• Realize that ODBC is not as isolating a protocol
  as we would like, so...
• Support ODBC access only from Win32
• C/S clients, application servers, web gateways
• But the DB server doesnt need this restriction

21
Trnsport Connections
Solid lines show ODBC connections Dashed lines
show HTTP connections New HTTP services could all
reside on one server
22
Functionality

• Hand-held data collector for SiteManager
• Materials management
• Maintenance management
• Data mart
• Scheduling and project management

23
Summary

• Trnsport is in very good shape
• Taming complexity is a major goal
• Reducing cost of ownership also vital
• Focus on information architecture, view software
  architecture as a means, not goal
• Continue to expand Trnsports scope

24
Trnsport Strategic Directions

• Presented to the Trnsport User Group
• October 6, 1999