Letterhead Logo - DOC 8 by Y51jP30

VIEWS: 5 PAGES: 5

									                                                 October 9, 2008

TO:             ALL BIDDERS
REF:            JOB NO. 08/0439
DUE DATE: October 20, 2008 no later than 2:00 p.m. Local Time Houston, Texas
All bidders are required to sign and attach a copy of this addendum with each proposal for a Data Warehouse
Solution for the Harris County Toll Road Authority. This addendum must be received by the Purchasing
Department no later than the above due date.
                                          ADDENDUM NO. 4
The following information is being provided to address vendor questions and clarify the requirements:

1. RFP, Section 1.61: What type of data migration tasks would HCTRA expect the vendor to do? 1.61
   references the data migration from the existing systems/hardware real-time or near-real-time to the DW.
   Other than the capture of the data from existing systems, no data migration is expected during the initial
   contract period (Phase I). HCTRA does anticipate extensive data migration in future contract periods
   but this will be discussed and scoped after implementation. Phase II is expected to begin around
   November 2009 or sooner.

2. Will there be a daily backup window available, or will the DW need to be available 24x7x 365 for user
   queries? The DW will be receiving and processing data 24x7x365, and likely searching data in the
   future.

3. What is the length of time that all original captured data will need to be kept and maintained? At this time,
   the length is indefinite… Assume ~5-10TB the first year (excludes images), and for at least four years
   after the first year. After the first year and during the second phase of the DW implementation (not
   covered in this RFP), the real-time availability, storage, and archiving (both on-line and offline) will be
   assessed.

4. RFP, Section 1.46: By ‘client’ does this mean the Decision Support Client? If so, will the client
   application be supported on both the Windows and Linux platforms concurrently? Which platform is
   planned for the initial deployment? The reporting/query tool shall be accessible via standard web
   browser… a client application (e.g. for a power user) may be proposed but must support both Windows
   and Linux platforms. If the proposal includes a client application, assume both platforms for initial
   deployment.

5. RFP, Section 1.49:       If the DW is centrally hosted, define what is meant by a “site”?
   How many sites are anticipated to be implemented? Ultimately this is intended as an in-house solution
   which will by definition be replicated for redundancy. Initially, it is not a requirement but may be
   quoted as an option if the proposed as an in-house solution; redundancy (disaster recovery) is a
   requirement if proposed as a hosted solution.

    The multiple sites/languages text references the varying points of input from different locations and
    platforms, as well as, the multiple points of query which will be both manual users (reports interface) as
    well as systems, platforms, and/or applications (site interface). After the first year, in addition to the
       individual reporting users it is anticipated that approximately six sites will be utilizing the
    DW directly for source and summary data.

6. RFP, Section 1.55: Beyond the 20 or so internal users previously defined, will there be additional
   consumers of the data warehouse reports via intranet or extranet? If so how many?
   Assume, at the end of the implementation year, there will be approximately 20 query generators
   and 10 power users. Architect so that in the future multiple systems may synchronously query or
   send data to the DW for data and moderate data compilations. The initial architecture of this
   effort is key to future success.

7. RFP, Section 1.12: How much data will come from each system listed per year? What is the growth
   rate per year? Does each system provide a logfile output? Note that historical data shall be
   incorporated in the expected second phase of this project. Anticipate approximately 1.5 million
   transactions per day with a total transaction size of 500KB. Outputs of each piece of hardware or
   system/app widely vary – in some case a log may be captured, in other cases it shall simply be a
   data capture of throughput, etc.

8. RFP, Section 1.13: Does Harris County expect vendor to resolve any data conflicts between capture
   points? Yes, data conflicts as well as audit and hardware health.

9. RFP, Section 1.17: Will each system source (i.e. ATTLAS, CHAS) time stamp every event to
   support the reporting requirements? In most events absolutely. Due to the transaction-based nature
   of the HCTRA system, it is important to know precisely when a transaction occurred, a payment
   was made, or account information updates were received.

10. RFP, Section 1.39: Will an X.509 certificate be acceptable? Yes, provided that the contract
    language includes updates as needed for this certificate in order to be fully PCI compliant, and
    must be included in response.

11. RFP, Section 1.54: Is the intent to provide an unlimited amount of storage? Yes Or a solution that
    provides growth for unlimited amounts of data and additional systems? A solution that provides
    growth for unlimited amounts of data, additional systems, and the storage required to
    accommodate same.

12. How many total databases will the vendor interface to? Ultimately, the data warehouse is intended
    as the master data source.

13. How many total tables in these databases? Currently, HCTRA has over 1,000 tables in the current
    schema which includes some redundant data across systems, and it also includes historical and
    summary data points. It does not currently include health or hardware data.

14. How many inserts over what time period (20 million inserts a week, etc.) will the system be expected
    to support? Anticipate approximately 1.5 million transactions per day with a total transaction size
    (approximate) of 500KB. Daytime inserts, due to the nature of the business, shall far exceed the
    volume of nighttime and weekend inserts.

15. How many queries and over what time period (100 million queries over a month, etc.) will the
   system be expected to support? Unlimited… Assume, at the end of the implementation year, there
   will be approximately 20 query generators and 10 power users. Architect so that in the future
   multiple systems may synchronously query the DW for data and moderate data compilations. The
   initial architecture of this effort is key to future success.

16. The availability requirements imply a DR solution would be necessary. However; the RFP states
    otherwise. Are there specific DR requirements or is this left to the judgment of the vendor? Would
    HCTRA accept a slightly lower availability requirement in lieu of a DR solution? The data
    availability requirements are not flexible.
17. How many environments are required (dev, test, prod, etc.)? At minimum, Development, Testing,
    and Production. Ideally a 4th environment for UAT exists between the Test and Production
    environments. The refresh of these environments MUST be specified in the response.

18. Please define the total number of interfaces required? This is at the discretion of the vendor. As
    stated above, at the end of the implementation year, there will be approximately 20 query
    generators and 10 power users. Architect so that in the future multiple systems may
    synchronously query the DW for data and moderate data compilations. The initial architecture of
    this effort is key to future success.

19. What would be the required information to be included in the DW first load to be exploited by
    November 2009? Not an initial load of historical data, but the historical data shall be
    incorporated in the expected second phase of this project. Anticipate approximately 1.5 million
    transactions per day with a total transaction size of 500KB.

20. The information to be loaded in this first phase would come from which operating Systems and / or
    devices? What type of data base are they on and running on which operating systems? What number
    of tables comprises each one of these data bases? Currently, HCTRA has over 1,000 tables in the
    current schema which include redundant data across systems, and it also includes historical and
    summary data points. The existing tables typically reside within an Oracle system. However, note
    that the long-term data capture will not originate from these tables, but shall replace these tables
    as the Master Data Source. It does not currently generally include health or hardware data.
    Hardware currently runs on various operating systems although for the most part they are either
    Windows or Linux.

21. Regarding information integrity, are there master tables duplicated in several systems and in such
    case, do they have the same coding algorithms? no

22. How many years of transactions would you like to store information about in the DW? For purposes
    of this RFP, assume all years. Again, the first year is not focused on a load of the historical data –
    that is expected in the second year effort.

23. What query service level would you require the system to allow? Would you need a 24 x 7 service
    level agreement? Provide structured service support options in the proposal including limited as
    well as 24x7 service level agreements.

24. What unstructured data would HCTRA wish to load in the DW? Describe the type of analysis
    HCTRA would require? Images and PDFs are two examples of the types of unstructured data
    which will be loaded. Transactional, hardware, and account association would be examples of
    analysis.

25. What security schemes / levels would HCTRA require the system to include? Would all users see the
    same information? Would they all perform the same actions? To be further defined in the analysis
    phase; however, initially the expectation is 1-3 administrators with full access, with the balance
    (20+ users) having structured access to respective systems (e.g. finance, hardware, customer
    service, etc.).

26. Is HCTRA expecting to have any sort of Balanced Score Card by November 2009? If so, what would
    be the main indicators HCTRA is keen on having? Does HCTRA have a definition for them? Is the
    required information in the existing systems? The balanced score card shall be finalized as a result
    of the analysis phase of implementation; the existing systems only partially provide the indicators
    which shall include redundancy, availability, and audit-ability.

27. RFP, Section 1.6: If DR must be back up within 6 hours, how lagged can it be and how long is data
    catch up allowed to take? System goes down Wed at noon, and DR is up 6 hours later, but can it be
         from a 1 week old backup and data loads will catch up within a week or does it have to be failed
    over to a system with as up to date data as the original system? The backup window should be a
    minimum of 24 hours (daily); therefore, this scenario should not apply.

    Also, how long until the decision is made to switch? If the system goes down due to a server crash
    and it will take 8 hours to get a technician to replace the failed piece, does that mean 6 hours from the
    time the system went down, the new one is up? or 6 hours from the time the issue is identified? or
    does DR come into effect after some X period of downtime? what about weekends or middle of the
    night crashes? This may be determined during the analysis phase; reasonably, it is typically a
    judgement call by the parties involved.

28. RFP, Section 1.12: How many real sources? Please reference the HCTRA System Diagram
    provided in Addendum No. 3 for a reasonable count of data sources.

    What data from a web site? traffic/hits or users who log in to add value to their passes, or something
    else? Traffic/hits, the track of a user who logs in to make a payment or update their account
    information, etc.

    Applicable hardware components of the tolling system.. What specifically has to be captured? Live
    video feeds? Traffic information like average speed, backups? Component inventory (how many
    gates and detectors there are?)? Hardware components are shown on the HCTRA System Diagram
    provided in Addendum No. 3. Live video is currently not a part of the tolling system but may
    become so in the future. Image capture. Transaction data capture. Component action capture.

29. RFP, Section 1.13: Does this mean store the points in a master system and a DR site? Or store in
    fact tables and audit tables? Have backups? Ideally, all three; please structure the proposal in such
    a way that ensures no data is lost.

30. RFP, Section 1.37: As soon as the system receives a file, it must be backed up off site? Or do the
    source systems retain copies for an hour or week in the event we need to ask for a retransmission?
    Most of HCTRA’s source systems (software and hardware) do retain data for a period of time.
    However, the received file should be backed up in a timely manner for both redundancy and good
    practice. The backup window may be as long as 24 hours, but a shorter timeframe is preferred.
    DATA LOSS IS NOT AN OPTION.

31. RFP, Section 1.46: Explain more about multi-lingual please? Does all of the textual data in the DW
    have to be in more than one language? Does the data and the application interface both need to be in
    mutli-languages? Which languages and how many have to be supported? We assume only US
    Dollars? Yes, only US Dollars. The reporting and application interface shall support existing
    coding languages as used by the HCTRA.

32. RFP, Section 1.49: Multiple sites/languages? What sites is this referring to? What type of
    administration? Ultimately this is intended as an in-house solution which will by definition be
    replicated for redundancy. Initially, it is not a requirement but may be quoted as an option if an
    in-house is proposed; redundancy (disaster recovery) is a requirement if proposed as a hosted
    solution. The multiple sites/languages text references the varying points of input from different
    locations and platforms, as well as the multiple points of query which will be both manual users
    (reports interface) as well as systems, platforms, and/or applications (site interface). After the first
    year, in addition to the individual reporting users it is anticipated that approximately six sites will
    be utilizing the DW directly for source and summary data.

33. RFP, Section 1.63: What are path analysis scenarios? Cross-system path analysis in a website
    example would be the route a unique user takes to navigate a site (i.e did it take 3 clicks to
    purchase, or twenty?). Path analysis in cross-system functions would be a piece of data passing
    from point a to system b and ending at system c, then perhaps revisiting point a.
        The following referenced article may be of use to some vendors:
   http://esj.com/business_intelligence/article.aspx?EditorialsID=8895.

34. RFP, Section 1.13: Why is there a need to have two or more points of data capture? Hardware audit,
    data QA, etc.

35. RFP, Section 1.13: What kind of data volume (number of new or updated records each minute / hour
    / day) is expected across all source systems? Note that historical data shall be incorporated in the
    expected second phase of this project. Anticipate approximately 1.5 million transactions per day
    with a total transaction size of 500KB. Outputs of each piece of hardware or system/app widely
    vary – in some case a log may be captured, in other cases it shall simply be a data capture of
    throughput, etc.

36. RFP, Section 1.33: What is the current approved list of hardware/software vendors at HCTRA?
    Harris County does not have an approved list of hardware/software vendors.

37. RFP, Section 1.37: Is the data loss a concern regarding the source systems or data in the data
    warehouse? Both; data loss is unacceptable and any identified source of data loss and/or data
    discrepancy is a concern.

38. RFP, Section 1.41: Please elaborate on definition of “auto query”. Programmatic or software
    system event prompted queries.

39. RFP, Section 1.43: Please provide list of Web, HCTRA applications and HCTRA hardware,
    including interface capabilities for each application and hardware model numbers and operating
    systems.
    NOTE: It is VERY likely that new hardware will be implemented during the DW effort, so the
    data capture should be as ubiquitous as possible, with the architecture of the warehouse
    considering the intended functionality of the inputs.

40. RFP, Section 1.45: What email deployment tools are in use today? In-house mail server.

41. RFP, Section 1.55: What is the anticipated number of users over the first 3 years? Assume, at the
    end of the implementation year, there will be approximately 20 query generators and 10 power
    users. Architect so that after the first year multiple systems may synchronously query the DW for
    data and contribute data compilations/summaries. The initial architecture of this effort is key to
    future success.

42. RFP, Section 2.2: Please elaborate on “foresee and maximize integration” It is likely HCTRA will
    add new hardware and/or systems within the next several years. The ease of integration for new
    applications and new hardware inputs is necessary.

43. RFP, Section 4.11: Please elaborate on what is meant by “creative execution”. The RFP states,
    “Vendor shall provide an example of performing the creative execution and analytics/tracking for
    a Data Warehouse solution project.” “Creative” is corrected to read “creation”.

                                                Sincerely,
                                                //s// Jack R. McCown
                                                Jack R. McCown, C.P.M.
                                                Purchasing Agent

________________________________                For             ________________________________
Bidder's Signature                                              Company Name
VJG/vlc

								
To top