Development and Management of Sustainable Enterprise Information Portals (2018)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

  4 T M o b T f b p w T a c A E u c L t d p F n p a Task 4 Manag his chapter d anagement  f a sustainab est practices his process w unctions into y the best pr rocess, the f ere added w his approach nd, as such,  ompleted be s the researc IPs, addition sers, updatin ollected and  ucidchart, di he focus was ata processin rocurement  ollowing the ine topics ide erformance  nd engineeri  A bloc  A com comp – Devel ement escribes the  of Sustainab le DOT EIP, c  identified in as conducte  sub‐function actices or de unctions and here needed  is referred t is non‐linear. fore reaching h team work al componen g the list of D developed.   agrams were  kept on the  g, GIS data p data process  developmen ntified in Ta management ng,  security) k definition d ponent and  onents of a s op Frame work perform le Informatio onnecting th  Task 3.   d by analyzin s. Each sub‐f composed fu  sub‐function .   o as “a top‐d  It includes a   acceptable  Figu ed through t ts, users, and OT EIP users Next, use cas  created to vi high‐level fun rocessing, lo ing, and cont t of the use c sk 2 (i.e., GIS   , environme :  iagram show data flow dia ustainable DO work for ed in Task 4 n Portals.”  T e business ca g the functio unction was  rther until it  s were check own/bottom trial and erro results. Figur re 40. Needs he decompos  requiremen  that was de es were iden sually repres ctions that a gs processing ent sharing.   ase diagrams and mapping ntal , externa ing the list o gram showin T EIP  Guidanc  of NCHRP Pr he purpose o ses and the f ns of sustain then either m matched wit ed against ex ‐up” approac r aspect, and e 40 represen  to specificati ition process ts were ident veloped in Ta tified and, us ent the use c re used in m , sensor data   , the team d  , bid and co l portal user f component g how data a   e on EIP oject 20‐103 f Task 4 was  unctional req able DOT EIP atched with h one. At eac isting requir h in system e , in general,  ts the proce ons process.  of identifyin ified.  First, t sk 2, based o ing the onlin ases.  As the  any different  processing,  eveloped the ntract , docu s, knowledge s that would re exchanged Develop , “Guidance f to define the uirements d s and decom  a structure c h step of the ements, and  ngineering. I several deco ss from need g the sub‐fu he team iden n the new in e charting se use cases we  business act document p  following di ment and lib  managemen  support a su  between ea ment an or Developm  design and o efined in Tas posing the m omponent s  decompositi new requirem t is a creative mpositions h s to specifica nctions of sus tified protot formation th rvice called  re being dev ivities, such a rocessing,  agrams for ea rary , operati t , asset man stainable DO ch of the  129  d ent and  peration  k 1 to the  ain  uggested  on  ents   process  ave to be  tions.    tainable  ypical  at was  eloped,  s video  ch of the  ons and  agement  T EIP 

130       A process flow diagram showing a relevant example of interactions between several components of a  sustainable DOT EIP   An activity diagram showing the high‐level activities of a sustainable DOT EIP and how these activities  flow together  The diagrams were developed together to benefit from the multifaceted view of the DOT EIP processes. As the  team switched from one view (diagram) of the process to another, the team was able to uncover additions or  modifications that needed to be made to another diagram. The team also tried to stay as close as possible to the  Unified Modeling Language (UML) diagram standard during the design phase but was limited by the features of  the diagramming tool used and the need for diagram clarity. Therefore, the diagrams may not be totally UML  compliant.   Based on the recommendations developed in Task 3.4 (i.e., focusing on the adoption of cloud architecture, cloud  services, and the use of container or server‐less architecture to provide scalability and agility to sustainable DOT  EIPs), the team decided to follow a microservices architecture pattern to develop the DOT EIP diagrams.   4.1 Microservices Architecture Pattern A microservices architecture pattern is an approach to application development in which a large application is  built as a suite of modular services. Each module supports a specific business goal and uses a simple, well‐ defined interface to communicate with other modules. Each microservices architecture pattern is a more  granular evolution of a service‐oriented architecture. The goal is to decompose an application in order to  facilitate agile development and deployment. Large companies (e.g., Amazon, Ebay, and Netflix) have adopted  microservices architecture patterns as their main architecture.  The microservices architecture pattern was generated in an attempt to solve the challenge developers faced  when upgrading large integrated applications. In a monolithic, SOA deployment, each small change meant that  the entire monolith needed to be rebuilt, and this, in turn, meant that rebuilds weren't happening rapidly. With  a microservices architecture pattern, each microservice runs a unique process and usually manages its  own database. This not only provides development teams with a more decentralized approach to building  software, it also allows each service to be deployed, rebuilt, redeployed, and managed independently. The  microservices architecture pattern also allows the application to be reactive and adaptive to user demand. In a  typical microservices architecture pattern implementation, microservices are paired with auto‐scalers and load  balancers. Microservices can then be cloned or decommissioned rapidly to respond to fluctuating user requests  in real time. Microservices architecture patterns are intended to be scalable in three different ways:    Scale by decomposition into simple functions   Scale by cloning services on demand   Scale by partitioning data across a cluster  A microservices architecture pattern is also a more platform‐agnostic approach to application development.  Microservices architecture patterns rely heavily on containerization, which allows microservices to be developed  completely independently from each other using different languages and libraries. Only the interface needs to  be standardized across all microservices.   While the microservices architecture pattern brings many advantages, it also greatly increases application  complexity. The microservices architecture pattern essentially trades code complexity for operational  complexity. A major drawback of a microservices architecture pattern is the increased operational complexity 

131      generated by the addition of interprocess communication and the occurrence of partial failure across the  distributed system. Another microservices architecture pattern drawback is data partitioning. The distribution of  data across multiple processes makes maintaining data consistency much more challenging. Also, some data  operations that are trivial on monolithic systems are not supported at all on a system with distributed data.  Major upgrades involving more than one microservice can also be challenging, as the interactions among each of  the microservices can easily bring about unexpected application behaviors. As a result, service interactions need  to be carefully considered during testing, and deployment needs to be very carefully coordinated.   To alleviate this increased operational complexity, most microservices architecture pattern implementations rely  on automated services to monitor, deploy, and manage their clusters. Scripting approaches have also been  developed to programmatically control the configuration and behavior of microservices clusters and allow them  to be rapidly modified or corrected.  4.2 Task 4.1 Identify Prototypical Users While performing the functional decomposition, the research team used the results of Task 2 to compile a list of  prototypical users of a sustainable DOT EIP, which is shown in Table 49.  We then described the role and  interactions of the users with the DOT EIP. These users were utilized to develop the various use cases in Task  4.2.  Table 49.  DOT EIP users.  DOT EIP users  Category  Administrator  Internal  Contractor  External  DOT Analyst  Internal  DOT Employee  Internal  DOT GIS Expert  Internal  DOT Librarian  Internal  DOT Maintenance (General Services Personnel?)  Internal  DOT Operations  Internal  DOT Procurement  Internal  IT Investigation  Internal  IT Monitoring  Internal  IT Operations  Internal  Knowledge Consumer  Internal/External  Knowledge Expert  Internal  Knowledge Provider  Internal/External  Public  External  State Employee  External  State Procurement  External    The following provides an overview of each of the identified users and how that user interacts with various DOT  EIPs.  

132      4.2.1 Administrator   Administrators are present in all use cases. These internal users have the following responsibilities: managing  other users’ access, managing data storage, managing metadata or database indexes, and archiving data when  necessary.  4.2.2 Contractor   Contractors are external users. They make requests for documents and search and browse datasets, such as GIS  layers or incident records, shared with them by the DOT. Contractors also use the portal to upload data that  they want to share with the DOT.  4.2.3 DOT Analyst   DOT analysts are primarily involved in the advanced analysis of GIS, operations, asset and sensor data. These  users search and browse available data, monitor live data sources, view data activity reports, analyze data, and  visualize analysis results and share them.  4.2.4 DOT Employee   A wide variety of DOT employees are users of EIP portals. This user group is meant to encompass all internal  DOT employees that search DOT and external datasets, request products or services, and upload collected data  as part of their daily activities.  4.2.5 DOT GIS Expert   DOT GIS experts are responsible for analyzing GIS data and creating new data layers.  4.2.6 DOT Librarian   DOT librarians are users in the documents and library use cases. These users are able to search documents;  receive, analyze, and publish new documents; validate document sources; and add metadata to existing  documents.  4.2.7 DOT Maintenance   DOT maintenance users are primarily involved in asset management use cases. These users are able to search,  browse, analyze, and upload DOT asset data.  4.2.8 DOT Operations   DOT operations users are involved in many different use cases. These users search, browse, and/or monitor  sensor, asset, and/or video data. They can also view asset activity reports, as well as review and analyze asset  and performance data when needed.  4.2.9 DOT Procurement   DOT procurement users are found in the bid and contract use cases. These users are able to search procurement  data; issue bid requests; investigate product or service costs; and receive, evaluate, and select bids.  4.2.10 IT Investigation   IT investigation users are found in the network and application monitoring use cases.  They belong to the DOT IT  security team and are involved in investigating and mitigating abnormal IT activity and analyzing historical  network and application logs. 

133      4.2.11 IT Monitoring   IT monitoring users are found in the network and application monitoring use cases. They are responsible for  monitoring IT system activities within the DOT IT systems. They can also perform simple queries to verify IT  systems’ activity.  4.2.12 IT Operations   IT operations users are found in the network and application monitoring use cases. They are responsible for  managing the performance and stability of the DOT IT systems. They can search and monitor IT systems’ activity  and perform action on DOT IT systems to mitigate observed events.  4.2.13 Knowledge Consumer   Knowledge consumers are found in the knowledge management use cases. They are mainly DOT employees but  could also be contractors. As knowledge consumers, they are able to browse and search for knowledge on the  portal to support their daily activities. These users can be either internal or external to the DOT.  4.2.14 Knowledge Expert   Knowledge experts are found in the knowledge management use cases. They manage the knowledge  management system by sharing and distributing new knowledge to other users through a knowledge  management portal.  They can also review and evaluate new knowledge created by others or solicit other users  for knowledge input.  4.2.15 Knowledge Provider   Knowledge providers are found in the knowledge management use cases. Knowledge providers contribute to  knowledge management activities by completing, adding, and sharing new knowledge, as well as evaluating new  knowledge shared by others.  4.2.16 Public   Many use cases have external public users.  These users represent anyone with the need to search, browse,  and/or request public DOT data.  In some cases, external public users also provide or upload data (e.g., public  surveys). There are many examples of public users throughout the various use cases:   Commercial traffic data providers    County employees   Emergency responders   Engineering firms   Federal agencies   Highway patrol   Lawyers and law firms   Local law enforcement   Local transportation agencies   News media   Public safety officials   University researchers 

134      4.2.17 State Employee   State employees encompass any users in departments other than the DOT, throughout the state. These users  are able to search, review, and request DOT data that are sharable with other state agencies. These users can  also upload data that they want to share with DOT.  4.2.18 State Procurement   State procurement staff are staff in departments outside of the DOT that are responsible for issuing bid requests;  receiving, evaluating, and selecting bids; awarding contracts; and finding vendors.  4.3 Task 4.2 Create Use Case Diagrams and Related Business Requirements The research team developed a list of high‐level use cases based on the information that was delivered in the  first interim report.  The team identified a few key use cases that apply across several business areas, generally  varying by time, scale, and user. These use cases are real‐time access, historic data/document access, modeling  access, and support activities. Examples of each are provided below.  Real‐Time Access   The general public, law enforcement, and news media access traveler information in real‐time (e.g.,  real‐time travel conditions and congestion) or by registering and receiving traveler alerts (e.g.,  construction, weather, flood).   DOT operations staff and asset managers monitor and assess the performance of the system and  assets in real‐time to facilitate incident management and asset failure remediation (e.g., signal  failure).   DOT acquisitions staff populate bid information and monitor the bid process; conversely, external  firms access and input information, which may or may not be “real time.”  Historic Data/Document Access   External organizations, such as other agencies or firms, access documents regarding DOT construction  project plans or DOT strategic initiatives.   The general public seeks information about DOT projects in the community (e.g., plans to build a new  highway).   DOT staff historically access data (e.g., operations, acquisitions audits, and asset inventories) to report  on performance and compliance and to plan new activities (e.g., maintenance schedules, new  construction, and new purchases).  Modeling Access   DOT staff, researchers, and other firms/agencies access data for the purposes of modeling risks to  performance (e.g., impacts on congestion) or structures (e.g., seismic loading).  Support Activities   DOT librarians have to obtain, digitize, and index documents for other staff and external users who will  request them.   DOT technical leads, executives, or knowledge management experts will help develop shared languages  and policies to maximize context discoverability. 

135       DOT IT staff monitor system alerts and support data governance policies to ensure site security and  privacy.  Each use case diagram (Figures 41 through 49) is presented along with descriptions of each user action. 

  Figure 41. Asset management a   nd engineering services use case diagram.  136   

137       Setup alert:  Alerts are set up either by DOT operations or maintenance users to be sent when there is important or relevant information  of which other users should be made aware.   Receive alert:  Alerts containing new, important, or particularly relevant DOT system information are received by DOT operations or  maintenance users.    Modify asset data:  DOT maintenance users make any necessary modifications to asset data that have been uploaded.    Create new asset:  DOT maintenance users create new assets in the system as new assets are installed.   Disable asset:  DOT maintenance users disable assets for removal from the system as assets are removed or no longer functional.    Upload asset information:  All relevant asset information is uploaded by DOT maintenance users.   Analyze asset data:  Both DOT operations and maintenance users can analyze asset data as they are uploaded into the system.   View asset report:  DOT operations users view reports on various assets containing the status of installed assets.   Monitor asset:  DOT operations users monitor all installed assets and create reports of the current status.   Search asset data:  All asset management users, both internal and external, are able to search the asset data available.   Browse asset data:  All internal asset management users are able to browse the asset data available.   Text search:  Text searching allows users to type into a text box and use keywords to narrow the available content to only what is  relevant to what they need.   Faceted search:  Faceted searching allows users to apply filters to the data in order to search only through relevant content for what  they need.   View asset data:  All DOT and other state users are able to view asset data.   View asset metadata: All DOT and other state users are able to view the asset metadata.   Visualize asset data:  All DOT and other state users are able to view visualizations of the asset data such as QA control charts.   Download asset data:  When asset data are made available for download, internal users may download a copy of them.   Add new asset:  The administrator adds new asset data in bulk to the system after they are approved for upload.    Decommission asset:  The administrator decommissions asset(s) as they are confirmed to be no longer in existence.   Archive asset data: The administrator archives asset data as assets are decommissioned or no longer needed in the system.   Manage asset metadata:  The administrator manages all of the metadata to ensure that they are still relevant, effective, and up to date.   Manage asset data storage:  The administrator manages data storage to ensure that the system’s capacity is not exceeded and data are  archived as necessary.    Manage asset data access:  The administrator manages all users’ access to the datasets that they have permission to use.    

  Figure 42. Bid and con   tract services use case diagram. 138   

139       Specify need:  DOT employees identify and specify needs for which new procurements need to be opened.   Issue procurement request:  Once needs are identified, DOT employee and procurement users can issue a procurement request.   Open procurement:  DOT procurement users open new procurement opportunities.   Edit procurement:  DOT employees and DOT procurement users are able to edit procurement opportunities once they have been  opened.    Add bid documents:  DOT procurement users add all necessary bid documents to the procurement.   Issue bid request:  DOT and other state procurement users issue requests for bids once the procurement has been opened.    Receive bids: DOT and other state procurement users receive all bids and prepare them for evaluation.   Evaluate bids: DOT and other state procurement users evaluate all bids that were received.   Select bid:  DOT procurement users select the best bid out of all the bids that were received and evaluated.    Find or add vendors:  DOT and other state procurement users search for and add vendors to a bid.   Award contract:  DOT and other state procurement users are able to award a contract once the winning bid has been selected.   Investigate costs: DOT procurement users investigate all costs in the bids that are being evaluated to make sure everything is reasonable  and realistic.   Close procurement:  Once the bid has been selected and the contract awarded, either the state or DOT procurement users can close the  procurement.   Search procurement activity: All bid and contract users are able to search the available procurement activity data.   Text search:  Text searching allows users to type into a text box and use keywords to narrow the available content to only what is  relevant to what they need.   Faceted search:  Faceted searching allows users to apply filters to the data in order to search only through relevant content for what  they need.   View procurement activity: DOT procurement users are able to view the procurement activity.   View procurement activity metadata: DOT procurement users are able to view the procurement activity metadata.   View procurement activity attachments: DOT procurement users are able to view any attachments to the procurement activity.   Download procurement documents:  When procurement documents are made available for download, DOT procurement users may  download copies.   Archive procurement data: The administrator archives procurement data, as they are no longer actively needed in the system.   Manage procurement metadata: The administrator manages all of the metadata to ensure that they are still relevant, effective, and up  to date.   Manage procurement data storage: The administrator manages data storage to ensure that the system’s capacity is not exceeded and  data are archived as necessary.   Manage procurement data access:  The administrator manages all users’ access to the datasets that they have permission to use. 

  Figure 43. Document an   d library services use case diagram.  140   

141       Request document:  DOT employees and external users—contractors and the general public—can place requests for specific documents  to which they would like to gain access.   Search documents: All users, both internal and external, are able to search through the available documents.   Upload new document: New relevant documents are uploaded by either contractors or DOT/state employee users for use by other  internal and external users.   Setup notification:  Notifications can be set up by all users to be sent when there is important or relevant information of which other  users should be made aware.   Receive notification: Notifications containing new, important, or particularly relevant use case information are received by all users.   Publish document: DOT librarian users submit a document for publication on a DOT internal website or public blog.   Review new document(s): New documents are reviewed by DOT librarian users for relevance before being uploaded.   Validate document source:  The sources of new documents are validated by DOT librarian users before being uploaded.   Add document metadata:  As the DOT librarian is reviewing new documents, the user adds all necessary metadata for the document.   Version document: DOT librarian users track the different versions of documents received.   Analyze document: DOT librarian users analyze documents to assess content and extract metadata as they are uploaded into the system.   Text search:  Text searching allows users to type into a text box and use keywords to narrow the available content to only what is  relevant to what they need.   Faceted search:  Faceted searching allows users to apply filters to the data in order to search only through relevant content for what  they need.   View document: All users, both internal and external, are able to view documents to which they have been provided access.   View document metadata: All users, both internal and external, are able to view the metadata for the available documents.   Download document:  All users, both internal and external, are able to download a copy of the documents to which they have been  provided access.   Ingest new document(s): The administrator adds new documents in bulk to the system after they are approved for upload.   Archive documents: The administrator archives documents as they are no longer actively needed in the system.   Manage document database indexes:  The administrator manages all of the database indexes to ensure that they are still maintaining  adequate search performance.   Manage document storage: The administrator manages data storage to ensure that the system’s capacity is not exceeded and data are  archived as necessary.   Manage document access:  The administrator manages all users’ access to the datasets that they have permission to use.   

  Figure 44. Environme   ntal services use case diagram. 142   

143       Setup alert: Alerts are set up either by DOT operations or analyst users to be sent when there is important or relevant information of  which other users should be made aware.   Receive alert: Alerts containing new, important, or particularly relevant DOT system information are received by DOT operations or  analyst users.   Modify sensor metadata: DOT maintenance users make any necessary modifications to sensor metadata that has been added.   Share analysis results:  DOT analyst users share the results of their analysis of sensor data as they have been generated and assessed.   Analyze sensor data: Both DOT operations and analyst users can analyze sensor data stored on the system.   View sensor activity report: DOT operations and analyst users are able to view sensor activity reports to ensure that the sensors are  operating correctly.    Monitor live sensor data:  DOT operations and analyst users monitor live sensor data for any suspicious activity and create reports of the  current status and any potential issues.   Search sensor data:  All internal users are able to search through the available sensor data.   Browse sensor data: All users, both internal and external, are able to browse the available sensor data.   Text search:  Text searching allows users to type into a text box and use keywords to narrow the available content to only what is  relevant to what they need.   Faceted search:  Faceted searching allows users to apply filters to the data in order to search only through relevant content for what  they need.   View sensor data: All DOT and state users are able to view available sensor data.   View sensor metadata: All DOT and state users are able to view the metadata for available sensors.   Visualize sensor data: All DOT and state users are able to create and view visualizations from the sensor(s) data.   Download sensor data: When sensor(s) data are made available for download, internal users may download a copy.   Add sensor feed: The administrator adds new sensor data feed to the system after it is approved for upload.   Decommission sensor: The administrator decommissions sensors as they are confirmed to be no longer in existence or functional.   Archive sensor data: The administrator archives sensor data as they are no longer operational in the system.   Manage sensor metadata: The administrator manages all of the sensor metadata to ensure that they are still relevant, effective, and up  to date.   Manage sensor data storage: The administrator manages data storage to ensure that the system’s capacity is not exceeded and data are  archived as necessary.   Manage sensor data access: The administrator manages all users’ access to the datasets that they have permission to use.   

  Figure 45. External    portal users use case diagram.  144   

145       Setup notification:  Alerts can be set up by all users to be sent when there is important or relevant information of which other users  should be made aware.   Receive notification: Notifications containing new, important, or particularly relevant use case information are received by all users.   Publish content:  DOT employee can publish content to be viewed by external portal users.   Review content:  New content is reviewed by DOT employee users for accuracy and relevancy before being uploaded.   Upload content: New, relevant content is uploaded by DOT employee users for use by other internal and external users.   Submit content request:  State employees and external users—contractors and the general public—can place requests for specific  content to which they would like to gain access.   Search content: All users, both internal and external, are able to search through the available content.   Browse content: External users, contractors and the general public, are able to browse the available content.   Text search:  Text searching allows users to type into a text box and use keywords to narrow the available content to only what is  relevant to what they need.   Faceted refinement:  Faceted searching allows users to apply filters to the data in order to search only through relevant content for what  they need.   View content: All users, both internal and external, are able to view available content.   View content metadata: All users, both internal and external, are able to view metadata for available content.   Download content: When data are made available for download, all users, both internal and external, may download a copy.   Ingest new content:  The administrator adds new content in bulk to the system after it is approved for upload.   Archive content: The administrator archives content as it is no longer actively needed in the system.   Manage content discovery: The administrator manages content metadata to optimize content discovery by external users.   Manage content storage: The administrator manages data storage to ensure that the system’s capacity is not exceeded and data are  archived as necessary.   Manage content access: The administrator manages all users’ access to the datasets that they have permission to use.   

  Figure 46. GIS and    mapping use case diagram.  146   

147       Search:  All users, both internal and external, are able to search through the available GIS and mapping data.   Setup notification: Notifications can be set up by all users to be sent when there is important or relevant information of which other  users should be made aware.   Receive notification: Notifications containing new, important, or particularly relevant use case information are received by all users.   Create new GIS data layer: DOT GIS expert users create new GIS data layers in the system as they are created or identified.   Analyze GIS data: DOT GIS expert users analyze GIS data as they are uploaded into the system.   Text search:  Text searching allows users to type into a text box and use keywords to narrow the available content to only what is  relevant to what they need.   Faceted search:  Faceted searching allows users to apply filters to the data in order to search only through relevant content for what  they need.   Spatial search:  Spatial searching allows users to combine location and text data to narrow the content to only what is relevant to what  they need in a specific location.   View dataset: All users, both internal and external, are able to view available datasets.   View metadata: All users, both internal and external, are able to view the metadata for available datasets.   Visualize layer: When visualizations are available, all users, both internal and external, are able to view visualizations of the GIS layers.   Download layer: When GIS layers are made available for download, all users, both internal and external, may download them.   Manage geospatial databases:  The administrator manages the indexes of tables, spatial reference tables, and raster tables to ensure  good performance of the database.   Manage GIS datasets storage: The administrator manages data storage to ensure that the system’s capacity is not exceeded and data are  archived as necessary.   Ingest new GIS dataset(s): The administrator adds new GIS datasets in bulk to the system after they are approved for upload.   Archive GIS datasets: The administrator archives GIS datasets as they are no longer actively needed in the system.   Manage GIS data access: The administrator manages all users’ access to the datasets that they have permission to use.   

  Figure 47. Knowledge man   agement services use case diagram.  148   

149       Setup notification: Notifications can be set up by all users to be sent when there is important or relevant information of which other  users should be made aware.   Receive notification: Notifications containing new, important, or particularly relevant use case information are received by all users.   Review knowledge activities: knowledge experts review the contribution made by other users to the existing knowledge dataset.   Distribute knowledge: Knowledge experts share new or updated knowledge content with users across the DOT.   Evaluate new knowledge: Knowledge experts and knowledge providers evaluate new knowledge added by other knowledge providers.   Share new knowledge: Knowledge experts and knowledge providers exchange newly discovered knowledge prior to its addition.   Add new knowledge: Knowledge providers add new knowledge document(s).   Complete knowledge: Knowledge providers add content to an existing knowledge document(s).   Search knowledge: Knowledge consumers are able to search through the knowledge content that has been made available to them.   Browse knowledge: Knowledge consumers are able to browse the knowledge content that has been made available to them.   Text search:  Text searching allows users to type into a text box and use keywords to narrow the available content to only what is  relevant to what they need.   Faceted search:  Faceted searching allows users to apply filters to the data in order to search only through relevant content for what  they need.   View knowledge: Knowledge consumers are able to view available knowledge content.   View knowledge metadata: Knowledge consumers are able to view the metadata for available knowledge content.   Download knowledge: When data are made available for download, knowledge consumers may download them.   Archive knowledge data: The administrator archives knowledge data that has become obsolete.   Manage knowledge metadata: The administrator manages the knowledge repository metadata to ensure that they still relevant,  effective, and up to date.   Manage knowledge storage: The administrator manages data storage to ensure that the system’s capacity is not exceeded and data are  archived as necessary.   Manage knowledge access: The administrator manages all users’ access to the datasets that they have permission to use.   

  Figure 48. IT services (network an   d application monitoring) use case diagram.  150   

151       Set alerts: Alerts can be set up by all users to be sent when there is important or relevant information of which other users should be  made aware.   Receive alerts: Notifications containing new, important, or particularly relevant use case information are received by all users.   Mitigate abnormal IT activity: IT operations and investigation users act on the system to mitigate abnormal IT activity by denying  network access and disabling IT assets when necessary.    Deny network access:  IT operations and investigation users deny IT network access to users or system processes.    Disable IT assets: IT operations users disable IT assets that are exhibiting abnormal behavior and cannot be recovered.   Search IT activity: The IT operations, monitoring, and investigation users are all able to search through IT activity.   Monitor IT activity: IT investigation and monitoring users monitor all IT activity for any suspicious activity and create reports of the  current status and any potential issues.   Analyze historical IT activity data: IT investigation users analyze historical IT activity data to identify any abnormal activity.   Investigate abnormal IT activity:  IT investigation users conduct an investigation on an abnormal IT activity that has been identified using  IT activity data.   Text search:  Text searching allows users to type into a text box and use keywords to narrow the available content to only what is  relevant to what they need.   Faceted search:  Faceted searching allows users to apply filters to the data in order to search only through relevant content for what  they need.   View IT activity: The IT operations, monitoring, and investigation users are all able to view IT activity data.   View IT activity metadata: IT operations, monitoring, and investigation users are all able to view IT activity metadata.   Visualize IT activity: IT operations, monitoring, and investigation users are able to create visualizations of IT activity data.   Download IT activity: When IT activity is made available for download, the IT operations, monitoring, and investigation users may  download it.   Configure IT assets: The administrator configures the network access and operating privileges of one or more IT asset.   Manage IT assets:  The administrator manages all IT assets to ensure good performance of the overall system.   Archive IT activity data: The administrator archives IT activity data as they are no longer actively needed in the system.   Manage IT activity metadata: The administrator manages all of the IT activity metadata to ensure that it is still relevant and up to date.   Manage IT activity storage: The administrator manages data storage to ensure that the system’s capacity is not exceeded and data are  archived as necessary.   Manage IT activity data access: The administrator manages all users’ access to the datasets that they have permission to use.   

  Figure 49. Operation and performa   nce management services use case diagram.  152   

153       Search video content: All users, both internal and external, are able to search through the available video content.   Review video sources:  All users, both internal and external, can review the sources for all video that has been shared.   Setup notification: Notifications can be set up by all users to be sent when there is important or relevant video content of which other  users should be made aware.   Receive notification: Notifications containing new, important, or particularly relevant information about video content are received by  all users.   Monitor live video feeds: DOT operations users monitor live video feeds for any abnormal activity and create reports of the current  status and any potential issues.   Review recorded video: All users, both internal and external, can review all recorded video that has been shared.   Share video:  All users, both internal and external, can share new or archived video content that has been approved for public release.   Add video metadata:  As the DOT operations user is reviewing new recorded video, the user adds all necessary video metadata.   Analyze video: DOT operations users analyze video data to create additional metadata as they are uploaded into the system.   Text search:  Text searching allows users to type into a text box and use keywords to narrow the available content to only what is  relevant to what they need.   Faceted search:  Faceted searching allows users to apply filters to the data in order to search only through relevant content for what  they need.   View video:  All users, both internal and external, are all able to view a variety of video data.   View recorded video: All users, both internal and external, are all able to view recorded video.   Stream live video: All users, both internal and external, are all able to stream live video.   View video metadata: All users, both internal and external, are all able to view video metadata.   Download recorded video: When recorded video is made available for download, all users, both internal and external, may download a  copy of it.   Add new video feed: The administrator adds new video feeds to the system after they have been approved.   Archive video data: The administrator archives video data as they are no longer actively needed in the system.   Manage video metadata: The administrator manages video metadata to ensure that they are still relevant, effective, and up to date.   Manage video storage: The administrator manages data storage to ensure that the system’s capacity is not exceeded and data are  archived as necessary.   Manage video access: The administrator manages all users’ access to the datasets that they have permission to use.   

  4 W s a d T c f e t p 4 D D f b B 4 4 T 4 T D 4 T p 4 T D 4  T D 4 T 4 T .4 Task 4 hile perform ustainable D nd graphical iagrams, and he diagrams  ases discove ulfill each bu lements as t eam acknow urpose of th .4.1 Servi uring the dia OT EIP micro urther refine e cloned or t elow is a list  Inte.4.1.1 .4.1.1.1 Pu his compone .4.1.1.2 Co his compone OT EIP.  .4.1.1.3 Co his compone rocurement  .4.1.1.4 Ad his compone OT EIP.  .4.1.1.5 DO his compone OT EIP.  .4.1.1.6 DO his compone .4.1.1.7 DO his compone .3 Model ing the func OT EIP.  Once ly represente  sequence di represent hig red in Task 4. siness case. T he research t ledges that th e workshop t ce Compone gramming p services arch d before any  urned on/off of all the DO rfaces  blic Web Use nt defines th ntractor Web nt defines th ntractor/Ven nt defines th section of th ministrator W nt defines th T Operation  nt defines th T Librarian U nt defines th T Analyst Us nt defines th Informatio tional decom  the decomp d them as co agrams.   h‐level view 1.  Included i hese diagram eam was able ese use case hat will be he nts  rocess, the re itecture. The developmen  upon deman T EIP compon r Interface   e web interfa  User Interfa e web interfa dor Procurem e web interfa e DOT EIP.  eb User Inte e web interfa User Interfac e web interf ser Interface e web interfa er Interface   e web interfa n Process position, the osition proce mponent and s of a micros n each diagra s are not ne  to graphica s may not be ld in Task 5. search team se compone t. Each comp d.  ents identifi ces that will  ce   ces that will  ent User Int ces that will  rface   ces that will  e  aces that wil    ces that will  ces that will  es Using C  research tea ss reached it  data flow d ervices archit m are the va cessarily all e lly represent   entirely com  identified a l nts were dev onent is stru ed during the be used by t be used by v erface   be used by v be used by D l be used by D be used by D be used by D   omponen m drafted th s stable state iagrams, bloc ecture patte rious parts o ncompassing without gett plete and co ist of compo eloped at a h ctured as a se  functional d he public to i endors or DO endors or DO OT system a OT operatio OT librarians OT analysts t t and Data e structure a , the team re k definition d rn designed t f the system  , but they in ing overly co uld be furthe nents that sh igh level and ries of ident ecompositio nteract with  T contractor T contractor dministrators n employees  to interact w o interact w Flow Dia nd behavior viewed the d iagrams, act o respond to that are need clude as man mplex.  The r r refined; th ould compos  will need to  ical services t n effort.  the DOT EIP. s to interact  s to interact   to interact w  to interact w ith the DOT  ith the DOT E 154  grams of a  rafts  ivity   the use  ed to  y  esearch  is is the  e the  be  hat can  with the  with the  ith the  ith the  EIP.  IP. 

155      4.4.1.1.8 DOT Maintenance User Interfaces   This component defines the web interfaces that will be used by DOT maintenance employees to interact with  the DOT EIP.  4.4.1.1.9 DOT Monitoring User Interfaces   This component defines the web interfaces that will be used by DOT employees dedicated to DOT system  monitoring to interact with the DOT EIP.  4.4.1.1.10 DOT Download User Interfaces   This component defines the web interfaces that will be used by DOT employees or non‐DOT users to export  data out of the DOT EIP.  4.4.1.1.11 DOT Map User Interfaces   This component defines the web interfaces that will be used by DOT employees or non‐DOT users to map the  DOT EIP data.  4.4.1.1.12 DOT Procurement User Interfaces   This component defines the web interfaces that will be used by DOT procurement employees to interact with  the DOT EIP during the procurement process.  4.4.1.1.13 DOT Data Collection User Interfaces   This component defines the web interfaces that will be used by DOT employees to interact with the DOT EIP  during data collection talks or surveys.  4.4.1.1.14 DOT General User Interfaces   This component defines the web interfaces that will be used by all DOT employees to interact with the DOT EIP.  4.4.1.1.15 IT Monitoring User Interfaces   This component defines the web interfaces that will be used by IT monitoring users, a subset of the DOT  employees, to interact with the DOT EIP.  4.4.1.1.16 IT Operation User Interfaces   This component defines the web interfaces that will be used by IT operation users, a subset of the DOT  employees, to interact with the DOT EIP.  4.4.1.1.17 IT Investigation User Interfaces   This component defines the web interfaces that will be used by IT investigation users, a subset of the DOT  employees, to interact with the DOT EIP.  4.4.1.1.18 Knowledge Consumer Web User Interfaces   This component defines the web interfaces that will be used by DOT knowledge consumers, a subset of the DOT  employees, to interact with the DOT EIP.  4.4.1.1.19 Knowledge Provider Web User Interfaces   This component defines the web interfaces that will be used by DOT and non‐DOT knowledge providers to  interact with the DOT EIP.  4.4.1.1.20 Knowledge Expert Web User Interfaces   This component defines the web interfaces that will be used by DOT knowledge experts to interact with the DOT  EIP. 

  4 T 4 T r 4 4 T D 4 T s 4 T D 4 T t 4 T t 4 T c 4 T o 4 T c 4 T o 4 T a .4.1.1.21 Sta his compone .4.1.1.22 AP his compone equest and c Busi.4.1.2 .4.1.2.1 Ac his compone OT EIP comp .4.1.2.2 An his compone uch as traffic .4.1.2.3 Ar his compone OT EIP data  .4.1.2.4 Ca his compone he other DOT .4.1.2.5 Co his compone o the DOT EI .4.1.2.6 Fil his compone apabilities to .4.1.2.7 Ge his compone r LIDAR data .4.1.2.8 Ing his compone apabilities to .4.1.2.9 Lo his compone ther DOT EIP .4.1.2.10 M his compone ll the DOT EI te Web User nt defines th I Gateway   nt allows ext ombine the m ness Services  cess Manage nt defines th onents and m alysis Manag nt defines th  sensor data  chiving Mana nt defines th storage and d che Managem nt defines th  EIP compon mputer Visio nt defines th P videos and  e Exchange M nt defines th  all the other o‐Analysis M nt defines th  to all the oth estion Mana nt defines th  all the other gging Manag nt defines th  components etadata Mana nt defines th P data storag  Interfaces   e web interfa ernal applica ultiple respo ment Service e internal DO anage its us ement Servic e internal DO or driver beh gement Serv e internal DO atabases.  ent Services e internal DO ents.  n Manageme e internal DO images.  anagement  e internal DO  DOT EIP com anagement S e internal DO er DOT EIP c gement Serv e internal DO  DOT EIP com ement Servic e internal DO .  gement Serv e internal DO e and databa ces that will  tions to call m nses into a s s   T EIP service ers’ privilege es   T EIP service avior data to ices   T EIP service    T EIP service nt Services  T EIP service Services   T EIP service ponents.  ervices  T EIP service omponents. ices   T EIP service ponents.  es   T EIP service ices   T EIP service ses.  be used by s ultiple DOT ingle one.  s that will be s.  s that will be  all the other s that will be s that will be s that will be s that will be s that will be s that will be s that will be s that will be   tate employe  EIP internal c  used to prov  used to prov  DOT EIP com  used to prov  used to prov  used to prov  used to prov  used to prov  used to prov  used to capt  used to mai es to interac omponents  ide secure a ide advance ponents.  ide archiving ide data cac ide image re ide file uploa ide advance ide large dat ure and trac ntain the met t with the DO using one sin ccess to all th d analysis of   capabilities  hing capabilit cognition cap d and down d analysis of  aset ingestio k the activity  adata associ 156  T EIP.  gle  e other  DOT data  to the  ies to all  abilities  load  DOT GIS  n  of all the  ated with 

157      4.4.1.2.11 Notification Management Services   This component defines the internal DOT EIP services that will be used to provide notification or alerts to all  other DOT EIP components.  4.4.1.2.12 Operation Management Services   This component defines the internal DOT EIP services that will be used to act on DOT systems components by all  other DOT EIP components, for example, taking a traffic camera offline or rebooting a data capture device.  4.4.1.2.13 Persistent Link Management Services   This component defines the internal DOT EIP services that will be used to provide all other DOT EIP components  with persistent link pointing to DOT EIP content. This set of services allows DOT EIP content to be moved around  without having to update all the other components with the content’s new location.   4.4.1.2.14 Publishing Management Services   This component defines the internal DOT EIP services that will be used to provide all other DOT EIP components  with the ability to publish announcements both internally (email and wiki) and externally (social media and  blogs).  4.4.1.2.15 Rendering Management Services   This component defines the internal DOT EIP services that will be used to provide graphic rendering services to  all other DOT EIP components, for example, the rendering of map tiles from raster data.  4.4.1.2.16 Reporting Management Services   This component defines the internal DOT EIP services that will be used to provide report generation capabilities  to all other DOT EIP components.   4.4.1.2.17 Search Management Services   This component defines the internal DOT EIP services that will be used to provide all other DOT EIP components  with search capabilities across all DOT EIP data services.   4.4.1.2.18 Service Discovery Management Services   This component defines the internal DOT EIP services that will be used as a registrar service for all other DOT EIP  components. This service will be used by each DOT EIP component to find the location of specific services within  the DOT EIP clusters.  4.4.1.2.19 Transcoding Management Services   This component defines the internal DOT EIP services that will be used to provide video transcoding capabilities  to all the other DOT EIP components.  4.4.1.2.20 Video Stream Management Services   This component defines the internal DOT EIP services that will be used to provide video streaming capabilities to  all the other DOT EIP components.  4.4.1.2.21 Visualization Management Services   This component defines the internal DOT EIP services that will be used to provide all other DOT EIP components  with advanced visualization capabilities that they cannot themselves generate. An example would be the  visualization of a 3‐D LIDAR dataset streamed to a mobile device.  

  4 T m 4 4  T c D 4 T c 4 T c 4 T w 4 T s 4 T l 4 T l 4 T a 4  T s 4 T d 4 T s .4.1.2.22 W his compone anagement  Data .4.1.3 .4.1.3.1 An his compone apabilities to OT documen .4.1.3.2 Ar his compone omponents w .4.1.3.3 Co his compone omponents w .4.1.3.4 Ge his compone ith geospati .4.1.3.5 Ge his compone ervices to the .4.1.3.6 Liv his compone ive sensor da .4.1.3.7 Liv his compone ive video feed .4.1.3.8 M his compone  set of taxon .4.1.3.9 Ne his compone ervices allow .4.1.3.10 No his compone atabase serv .4.1.3.11 RD his compone ervices to the orkflow Mana nt defines th services to a Services—In alytical Datab nt defines th  the other DO ts or training chive Storage nt defines th ith archiving ntent Storag nt defines th ith content  ocapable No nt defines th al search cap ospatial Rela nt defines th  other DOT E e Sensor Fee nt defines th ta feeds, for  e Video Feed nt defines th s, for examp etadata Repo nt defines th omies or ont twork and Ap nt defines th ing them to l SQL Distribut nt defines th ices to the ot BMS Service nt defines th  other DOT E gement Serv e internal DO ll DOT EIP com ternal  ase Services e internal DO T EIP compo  prediction m  Services   e internal DO  capabilities. e Services   e internal DO storage and d SQL Distribut e internal DO abilities to th tional Databa e internal DO IP compone d Services   e internal DO example, from  Services   e internal DO le from traff sitory Service e internal DO ologies to he plication Log e internal DO og and track  ed Database e internal DO her DOT EIP  s   e internal DO IP compone ices   T EIP service ponents.     T EIP service nents. An ex odels using  T EIP service    T EIP service istribution c ed Database T EIP service e other DOT  se Managem T EIP service nts.  T EIP service  traffic spee T EIP service ic cameras.  s   T EIP service lp organize a s Services  T EIP service their activitie  Services   T EIP service components T EIP service nts.  s that will be s that will be ample would historical dat s that will be s that will be apabilities.    s that will be EIP compone ent System S s that will be s that will be d sensors or s that will be s that will be nd search the s that will be s.  s that will be .  s that will be    used to prov  used to pro  be a set of s a.   used to prov  used to prov  used to prov nts.  ervices    used to prov  used to prov  CO2 sensors  used to prov  used to prov  DOT EIP con  used to pro  used to prov  used to prov ide business vide advance ervices perfo ide the othe ide the othe ide scalable  ide tradition ide the DOT  .  ide the DOT  ide the DOT  tent.  vide the DOT ide scalable  ide tradition  rules and pro d data analy rming text an r DOT EIP  r DOT EIP  database ser al geospatial EIP compone EIP compone EIP compone  EIP compon non‐relationa al relational  158  cess  sis  alysis on  vices   database  nts with  nts with  nts with  ents with  l  database 

  4 4  T i 4 T o 4 T o 4 T o 4 T o 4 B f c d s i N t d Data .4.1.4 .4.1.4.1 Ex his compone nformation, f .4.1.4.2 Ex his compone utside of the .4.1.4.3 Ex his compone utside of the .4.1.4.4 Ex his compone utside of the .4.1.4.5 Sta his compone ther state ag .4.2 Block lock definitio ollowed the D omponent as esigned nine hould be not ncluded in th ote: The res o scale and d ashed rectan Services—Ex ternal Asset I nt defines th or example, f ternal Docum nt defines th  DOT, for exa ternal GIS Da nt defines th  DOT, for exa ternal Knowle nt defines th  DOT, for exa te Procurem nt defines th encies throu  Definition  n diagrams a OT EIP porta  belonging to  diagrams fo ed that the e e IT services  earch team d uplicate itsel gle at the bo ternal  nformation S e external se rom manufa ent Source S e external se mple, from o ta Source Ser e external se mple, from o dge Source S e external se mple, from o ent Services   e external se gh state‐main Diagrams  re created to l framework  one of thre r each of the  xecutive leve topic.   eviated from f by represen ttom.   ervices  rvices that c cturers’ web  ervices   rvices that co nline librarie vices   rvices that co nline GIS dat ervices   rvices that co nline knowle rvices that co tained web   communica  diagram as a e groups—int business acti l, future tren  the UML, Sy ting the com ould be used services.  uld be used  s.  uld be used  a libraries an uld be used  dge reposito uld be used  services.  te structural   basis for the erfaces, busi vities identifi d, and securit sML standard ponents as a    by DOT EIP c by DOT EIP c by DOT EIP c d registries. by DOT EIP c ries.  by DOT EIP c information   design of th ness services ed in Task 2  y topic was n  and indicate  series of clo omponents t omponents t omponents t omponents t omponents t about a syste ese diagrams , or data serv (see Figures 5 ot diagramm d the ability sely stacked r o collect ass o collect doc o collect GIS  o collect kno o collect data m. The resea  and classifie ices. The tea 0 through 58 ed, but secu  for each com ectangles wi 159  et  uments  data  wledge   from  rch team  d each  m  ). It  rity was  ponent  th a 

  Figure 50. Asset management and    engineering services block definition diagram.  160 

  Figure 51. Bid and contra   ct services block definition diagram.  161   

  Figure 52. Documents and li   brary services block definition diagram.  162   

  Figure 53. Environmenta   l services block definition diagram.  163   

  Figure 54. External portal u   sers services block definition diagram.  164   

  Figure 55. GIS and mappi   ng services block definition diagram.  165   

  Figure 56. Knowledge manag   ement services block definition diagram.  166   

    Figure 57. Network and application    monitoring services block definition diagram.  167   

  Figure 58. Operations and performanc   e management services block definition diagram. 168   

169      4.4.3 Component and Data Flow Diagrams  Data flow diagrams are designed to illustrate how data are processed by a system in terms of inputs and  outputs. As its name indicates, the focus in this kind of diagram is on the flow of information—where data come  from, where they go, and how they get stored.  The microservices architecture pattern greatly increases the amount data flowing within an application and the  complexity of the data exchanged between components, which makes data flow diagramming challenging. For  clarity, the component and data flow diagrams that the research team created  (see Figures 59 through 67) do  not show all the components involved in the process and do not show every possible data exchange happening  among components.  Showing these would render the diagrams unreadable. Instead, the team focused on  showing the main data exchanges among the service components involved in the high‐level use cases and  omitted some of the components that were less relevant to the use cases, such as logging and service discovery.  The components that were not included in the data flow but are still involved in the process are represented at  the top of each diagram as unconnected hexagons.  A few notes on the diagrams are the following:   Each component of the component and data flow diagrams has been color‐coded following the color  pattern that was established in the block definition diagrams to differentiate interfaces, business  services, and data services.   Because of the large amount of data connection between components, the team decided to represent  each component as a hexagon rather than a rectangle to increase the number of connection points  between components and avoid having too many overlapping arrows on the diagrams.    Due to the reactive and event‐driven nature of the microservices architecture pattern, most data flow  between component services is bilateral.   To increase clarity, the team decided to differentiate some of the data flow representation in the  diagrams. Black arrows represent the main application data flow, red arrows represent the API gateway  data flow, and dashed arrows represent the security data flow.    

  Figure 59. Asset management services    data flow diagram.  170   

  Figure 60. Bid and contract services    data flow diagram.  171   

  Figure 61. Documents and library servic   es data flow diagram.  172   

  Note: this diagram focused Figure 62.  on the scen   Environmen arios involvin tal services d g the use of    ata flow diag live sensor da ram.  ta by the DOT EIP.   173   

  Figure 63. External portal users service   s data flow diagram.  174   

  Figure 64. GIS and mapping services    data flow diagram.  175   

  Figure 65. Knowledge management serv   ices data flow diagram.  176   

  Figure 66. Network and application monitoring    services data flow diagram.  177   

  Note: this diag Figure 67.  ram focused Operations a  on the scen nd performan arios involvin ce managem g the use of    ent services  live video dat data flow dia a by the DOT gram.   EIP.   178   

179      4.4.4 Activity Diagrams  Activity diagrams are designed to represent workflows of stepwise activities and actions in order to support  choice, iteration, and concurrency. Activity diagrams are intended to model both computational and  organizational processes and show the overall flow of control.  In this section, the research team focused on the representation of the high‐level workflow that would need to  be followed in order to perform some of the use cases identified in Task 4.1 (see Figures 68 through 76). The  activity diagrams designed were not intended to be exhaustive. They were intended to be completed during the  Task 5 workshop.  

  Figure 68. Asset mana   gement services activity diagram.  180   

  Figure 69. Bid and co   ntract services activity diagram. 181   

  Figure 70. Document an   d library services activity diagram.  182   

  Figure 71. Environm   ental services activity diagram.  183   

  Figure 72. External por   tal users services activity diagram.  184 

  Figure 73. GIS and ma   pping services activity diagram. 185   

  Figure 74. Knowledge ma   nagement services activity diagram.  186   

  Figure 75. Network and applica   tion monitoring services activity diagram.  187   

  Figure 76. Operations and perform   ance management services activity diagram. 188     

189      4.4.5 Sequence Diagrams  Sequence diagrams are interaction diagrams intended to show how objects operate with one another during a  specific scenario and in what order. Sequence diagrams use a Message Sequence Chart construct to represent  the system components and their interactions arranged in time sequence. These diagrams depict the objects  involved in the scenario and the sequence of messages exchanged between the objects that are needed to carry  out the functionality of the scenario.   Multiple scenarios and diagrams could be derived from the use cases, components, and data flow identified in  the previously presented diagrams. The research team restricted itself to one example scenario for each of the  topic areas to show and investigate how components of the DOT EIP could interact with one another to fulfill  them (see Figures 77 through 85).  Note: Each component of the sequence diagrams has been color‐coded following the color pattern established  in the block definition diagrams to differentiate interfaces, business services, and data services. 

  Scenario for Figure 77: DOT maintenance employe Figure 77. Asse e archives older  t management a   assets data.  nd engineering services sequence diagram.  190   

  Scenario for Figure 78: DOT procurement employe Figur e runs a procure e 78. Bid and con   ment status repo tract services seq rt on the DOT EI uence diagram. P.    191   

  S t cenario for Figur he rest of the DO e 79: DOT librari T.   an uploads docu Figure 7 ments into DOT  9. Documents an   portal library, ext d library services racts metadata f  sequence diagra rom document a m.  nd shares its ava 192  ilability to   

  Scenario for Figure 80: DOT employee monitors an Figu d analyzes live d re 80. Environme   ata coming from  ntal services seq sensors.  uence diagram. 193   

  Scenario for Figure 81: Contractor searches and do Figure 8 wnloads docume 1. External porta   nts shared on th l users services s e DOT portal.  equence diagram.  194   

  Scenario for Figure 82: DOT GIS expert request an  Figure analysis of a GIS   82. GIS and ma   datasets and visu pping services se alize its results. quence diagram.  195   

  S c cenario for Figur ontribution.  e 83: Knowledge provider search Figure 83 es DOT knowledg . Knowledge man   e management  agement service system, contribu s sequence diagr te to knowledge am.   content and sha 196  res its   

  S t cenario for Figur he findings.  e 84: DOT IT experts search netw Figure 84. Netw ork and applicat ork and applicat   ions logs for abno ion monitoring s rmal behaviors, ervices sequence  analyze and visu  diagram.  alize the data, a 197  nd share   

  Scenario for Figure 85: DOT EIP pu F blic user request igure 85. Operati s a live video str on and performa   eam of a traffic c nce managemen amera on his cel t services sequen lphone.  ce diagram.  198   

  199      4.5 Task 4.4 Create System Requirements List While performing the functional decomposition, the research team also collected additional and new  DOT EIP requirements and organized them into the following categories:   Functional requirements   Performance requirements   Design requirements   External interface requirements   Resource requirements  The requirements were then cataloged to a requirement specification document or database.  4.5.1 Functional Requirements    The DOT EIP shall contain a service discovery and registrar service.   The DOT EIP shall contain a persistent link service.   The DOT EIP shall contain a cache service.    The DOT EIP shall contain an API gateway service.   The DOT EIP shall contain a notification service.   The DOT EIP shall contain a search service.   The DOT EIP shall contain a data ingestion service.   The DOT EIP shall contain an access management service.   The DOT EIP shall contain a content publishing service.   The DOT EIP shall contain an activity tracking and logging service.   The DOT EIP shall contain a workflow management service.   The DOT EIP shall contain a data archiving service.   The DOT EIP shall contain a metadata management service.   The DOT EIP shall contain a reporting service.   The DOT EIP shall contain a file exchange service.   The DOT EIP shall contain a data analysis service.   The DOT EIP shall contain a data visualization service.   The DOT EIP shall contain a video streaming service.   The DOT EIP shall contain a computer vision service.   The DOT EIP shall contain a video transcoding service.   The DOT EIP shall contain a GIS data analysis service.   The DOT EIP shall contain a GIS rendering service.   The DOT EIP shall contain a public web user interface.   The DOT EIP shall contain a contractor web user interface.   The DOT EIP shall contain contractor/vendor procurement user interface.   The DOT EIP shall contain an administrator web user interface.   The DOT EIP shall contain a DOT operation user interface.   The DOT EIP shall contain a DOT librarian user interface.   The DOT EIP shall contain a DOT analyst user interface.   The DOT EIP shall contain a DOT maintenance user interface.   The DOT EIP shall contain a DOT monitoring user interface. 

  200       The DOT EIP shall contain a DOT download user interface.   The DOT EIP shall contain a DOT map user interface.   The DOT EIP shall contain a DOT procurement user interface.   The DOT EIP shall contain a DOT data collection user interface.   The DOT EIP shall contain a generic DOT employee user interface.   The DOT EIP shall contain an IT monitoring user interface.   The DOT EIP shall contain an IT operation user interface.   The DOT EIP shall contain an IT investigation user interface.   The DOT EIP shall contain a knowledge consumer web user interface.   The DOT EIP shall contain a knowledge provider web user interface.   The DOT EIP shall contain a knowledge expert web user interface.   The DOT EIP shall contain a state web user interface.   The DOT EIP shall contain a load‐balancer service.   The DOT EIP shall contain an auto‐scaler service.   The DOT EIP shall contain an analytical database service.   The DOT EIP shall contain an archive storage service.   The DOT EIP shall contain a content storage service.   The DOT EIP shall contain a geocapable NoSQL distributed database.   The DOT EIP shall contain a geospatial RDBMS service.   The DOT EIP shall contain a metadata repository service.   The DOT EIP shall contain a network and application logs service.   The DOT EIP shall contain a NoSQL distributed database service.   The DOT EIP shall contain a RDBMS service.  4.5.2 Performance Requirements    DOT EIP services shall be able to be started rapidly.   DOT EIP services shall be able to be stopped rapidly.   DOT EIP services shall be able to be duplicated rapidly.   DOT EIP components shall be able to be decommissioned rapidly.   DOT EIP components shall be able to be deployed rapidly.   DOT EIP components shall be able to be updated rapidly.  4.5.3 Design Requirements    The DOT EIP component shall be distributed.   The DOT EIP components shall connect to the API gateway service.   The DOT EIP components shall register to the service discovery service.   The DOT EIP components shall content shall be managed through the DOT EIP persistent link  service.   The DOT EIP shall follow a microservices architecture pattern.   The DOT EIP data store shall be part of the microservices architecture.   The DOT EIP shall use centralized logging.    The DOT EIP shall use a distributed tracking and logging service.   The DOT EIP shall rely on events notification to communicate between components.   All DOT EIP services shall adjust to demand spikes automatically. 

  201       All DOT EIP components shall be able to be updated, deployed, and decommissioned without  affecting the other DOT EIP components.   The DOT EIP shall use API standards to design and operate its API gateway.   The DOT EIP shall use a single data format across the entire system such as JavaScript Object  Notification (JSON) or Extensible Markup Language (XML).   The DOT EIP shall provide its clients with required libraries as part of its services.   The DOT EIP shall rely mostly on hyper text transfer protocol (HTTP) and REST for  communication between services.  4.5.4 External Interface Requirements    The DOT EIP shall be able to connect to a live sensor feed service.   The DOT EIP shall be able to connect to a live video feed service.   All DOT EIP components shall rely mostly on HTTP and REST for communication with external  services.  4.5.5 Resource Requirements    DOT EIP shall be implemented on a commodity cluster infrastructure (cloud like).