|
District 5: |
|
Send Your |
 |
Statewide Services |
 |
Elements and interfaces that are designated with 
are
relevant to the District 5 region and many other regional
architectures in the state. These broadly applicable interfaces are
actually defined in a separate Statewide Services architecture. They are
included in this District 5 architecture so that the architecture
includes a complete, unified view of all elements/interfaces that are of
interest to the region.
More on Statewide Services
This District 5 Regional Architecture Web Site presents an integrated view of all the transportation systems that are of interest to the region. The regional architecture includes interfaces that are locally defined (i.e., they vary from one FDOT District to the next) and interfaces that are broadly applicable to all, or almost all, regions in the state. While both types of interfaces are presented in a seamless, integrated fashion in the regional architecture web site, they are actually defined in two different architectures. The region-specific interfaces are defined in a regional architecture developed specifically for the District 5 region. The more broadly applicable interfaces are actually defined in a separate Statewide Services Architecture.
What are Statewide Services?
As the name suggests, the Statewide Services Architecture defines the transportation systems and interfaces that are relevant to the entire state. Statewide Services include:
- Central data services and resources that are accessed and used from many different regions in the state. Examples include the CVISN systems that are used to support commercial vehicle credentialing and safety.
- Centralized systems that have jurisdiction over the entire state. Good examples of these systems are the State Emergency Operations Center and State Warning Point.
- Infrastructure elements that occur in most or all districts and interface directly with the traveling public. These infrastructure elements should be consistent across the state since FDOT district boundaries (the boundaries of the regional architectures) should be transparent to the traveling public. Examples include the motorist aid call boxes, service plazas, and rest stops.
- Private sector services that may be broadly deployed as private businesses expand markets and provide services spanning district boundaries. Examples include the Mayday/Concierge Service Provider and Private Sector Traveler Information Services.
Why Define a Separate "Statewide Services" Architecture?
By definition, statewide services apply to many different regions in the state. In the Florida Statewide ITS Architecture, we define the architecture for these services once and then reuse these definitions in each region. This "define once and use many times" approach improves architecture consistency and accuracy, and makes the architecture easier to maintain.
- Consistency. The statewide services must be consistently represented in every regional architecture if the architecture is to encourage integration and consistency across FDOT districts. By defining the statewide services once in a statewide services architecture and then referencing these services from each regional architecture, we guarantee that each regional architecture will include exactly the same statewide service definitions.
- Efficiency. It is much more efficient to maintain an architecture that does not include redundant definitions. When a change is made to the architecture, it is much better to make this change once (in the statewide services architecture) and then let every region incorporate the changes by reference.
What are the Drawbacks?
Since the same statewide services architecture is used by every region, some apparent consistencies may be noted, including the following:
A "Planned" Interface may be identified as "Existing". We set the status of a statewide interface to "Existing" if it has been implemented at least once in the state. This means that you may see interfaces that are defined as "Existing" even if they haven't yet been implemented in your region. The "Existing" status indicates that the interface has already been implemented elsewhere in the state. The standards used by the existing implementation should be considered for use when the regional interface is actually implemented.
Occasionally, Interfaces will be Identified that are not of Interest. While the statewide services are broadly applicable, they may not be universally applicable. For example, a central "Control Burn Permitting Database" is made available to Traffic Management and Public Safety agencies across the state. This database and its interfaces are defined in the Statewide Services database, even though some public safety and traffic agencies may not have a need for this information. The Statewide Services interfaces that are shown represent a range of services that are available to each element in the regional inventory. Only the interfaces and elements that are relevant should be carried forward into project architectures, design, and implementation.
