Guidance for 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.

31 Industry Practices for Sustainable EIPs Many industries outside of the traditional transportation IT environment have a longer history of leveraging EIPs to support their business processes. This section highlights current practices and technologies used across the IT industry to design and maintain sustainable EIPs. These prac- tices are based on the results of a survey of IT industry and subject matter experts that focused on the following six areas: • Type of infrastructure • Business services architecture • Data storage technologies • Frameworks for application and user interfaces • Content and operations management • Monitoring services The following recommendations for the development and operation of sustainable EIPs are offered to capture the best practices identified from the survey responses: • Leverage cloud IT infrastructure and services to reduce risk of IT infrastructure obsolescence, lower operating and maintenance costs, and provide flexible and scalable capacity. • Use distributed software design rather than monolithic design. • Adopt a three-tier portal system design separating user interface, business logic, and data into independent layers. • Adopt an event-driven software design rather than a time or request-driven one. • Leverage open source software or cloud services (database, storage, networking, etc.) to limit the license cost when scaling up. • Adopt a looser form of governance allowing each component of each tier to be developed and evolved independently. Each of these industry practices are presented in Subsections 3.1 through 3.6. 3.1 Use Cloud and On-Premise IT Infrastructure Most industries use a mix of cloud and on-premise infrastructure to efficiently meet their needs rather than solely using traditional on-premise infrastructure. Cloud infrastructure is not just on- premise IT infrastructure relocated to a data center and made available as a service. It is an entirely different type of IT infrastructure designed to support a very large amount of data and services and built entirely on low-cost/commodity hardware. The rationale behind using cloud infrastructure is to increase the enterprise portal sustainability by significantly reducing the risk of IT infrastruc- ture obsolescence; benefiting from a scalable, flexible, and on-demand set of IT capabilities; and S E C T I O N 3

32 Guidance for Development and Management of Sustainable Enterprise Information Portals reducing IT infrastructure operation and maintenance time to a minimum. Figure 3-1 shows a diagram representing the differences between on-premise and cloud architecture. Sensitive portal data and services, which may be more vulnerable if stored and deployed on public cloud infrastructure, are typically kept on premise. Ideally, these services are stored on an on-premise private cloud infrastructure capable of interacting with portal data and services located in the cloud. 3.1.1 Reduce the Risk of IT Infrastructure Obsolescence On-premise infrastructure is often composed of reliable and expensive servers or server pairs, which are treated as indispensable or unique systems that can never be down (mainframes, data- base systems, and web servers). These mainframes and servers are often tightly integrated, robust, and expensive to maintain and scale when their capacity has been reached. Unfortunately, they are not immune to the fast pace of IT innovation, and just like desktop computers, they become obsolete very quickly. This is problematic because most owners of on-premise IT infrastructure do not have robust annual budgets to purchase new hardware as soon as old hardware becomes obsolete. Often, owners cannot afford the expertise needed to migrate their operations from one complex system to another seamlessly. Cloud architecture was created primarily to circumvent these issues. Rather than relying on tightly integrated and expensive hardware, cloud IT infrastructure is made of arrays of more than two inexpensive and less-reliable servers that are built using automated tools and are designed for failure, where no one, two, or even three servers are irreplaceable. Cloud architecture essentially moved robustness from the hardware level to the software level. Typically, during failure events no human intervention is required, as the arrays exhibit attributes of “routing around failures” by restarting failed servers or replicating data. Cloud infrastructure experiences hardware failures daily and replaces hardware constantly with the latest hardware available at the lowest cost. There- fore, cloud infrastructure is continuously being renewed with the latest commodity hardware and never risks becoming obsolete. Figure 3-1. On-premise versus cloud architecture.

Industry Practices for Sustainable EIPs 33 3.1.2 Scalable, Flexible, and On-Demand IT Capabilities Traditional on-premise IT infrastructure is typically sized to satisfy an estimated maximum demand and as such always operates at its highest design level, no matter the actual level of demand. Moreover, if demand exceeds the planned maximum of on-premise infrastructure, it is not possible to scale up to meet the extreme demand. In this situation, jobs need to be halted and prioritized to spread the load within capacity, which impairs system users’ ability to access real- time data. Once this scenario becomes the norm, there is no alternative but to purchase larger and more expensive on-premise infrastructure and undertake a costly migration. Cloud infrastructure is built as a pay-as-you-go service and as such can be turned up or down as desired or even turned off when not needed. For example, a sudden request for traffic information from drivers or the processing of a large amount of GIS data can be run quickly and processed at higher speeds without the risk of crashing servers or losing data because the cloud infrastruc- ture will adjust capacity in real time. When the traffic information demand returns to normal or GIS data is processed, capacity automatically shrinks back, ready to scale back up again. The on-demand, scalable, and flexible capacity of cloud infrastructure literally eliminates the “upper bound” problem and reduces the cost of operating IT infrastructure by eliminating the need to pay for IT infrastructure capacities that are rarely utilized. 3.1.3 Reducing IT Infrastructure Operation and Maintenance Time On-premise IT infrastructure requires that an organization purchase equipment and build out and operate a data center. Often, millions of dollars (or more) must be invested in equip- ment before on-premise IT infrastructure can deliver value. Qualified staff need to be hired and spare parts need to be acquired to operate and maintain a newly created infrastructure. Cloud infrastructures eliminate the need to acquire equipment, hire IT infrastructure manage- ment experts, and allocate often expensive real estate to run an organization’s applications. Organizational applications can be developed and deployed directly on the already running cloud infrastructure, which frees the organization to focus its resources on its applications rather than the maintenance of its own IT infrastructure. This advantage of cloud IT infrastructure is often contested and countered because it is associ- ated with servers that are off premise and not owned by the customer. Indeed, cloud providers own, operate, and maintain servers. Yet, often concerns regarding off-premise hosting are unfounded, particularly because cloud services offer greater resiliency, security, and reliability than most in-house hosting of data. Because operating and maintaining servers and taking care of software and security updates regularly is crucial to the business of cloud providers, most are extremely efficient and reliable in these areas. The services offered to customers by cloud providers are up 99.99% of the time. Figure 3-2 shows a graphical comparison of the incurred costs of on-premise and cloud architecture. 3.2 Use Distributed Software Architecture A distributed computer system is one in which the computing power is distributed across several servers connected through a network, communicating and coordinating their actions by passing messages to each other. To be efficient, distributed computer systems require that the software they are running be distributed as well. This means that the software should be com- posed of multiple software components running on top of the distributed servers, leveraging the passage of messages among them. In a distributed software environment, each component performs a specific task, often independently from other components. Consequently, failure of

34 Guidance for Development and Management of Sustainable Enterprise Information Portals a component is localized and independent. This characteristic allows distributed software run- ning on a distributed computer system to recover from failure by restarting tasks that failed on a component on a different server using another software component. Distributed computer systems are designed to leverage the many software components running across a group of servers (cluster) to perform each software function as efficiently and as reliably as possible. In comparison, centralized software, such as the kind typically running on monolithic com- puter systems, involves very tightly integrated processes on the same server, exchanging informa- tion mainly through server memory. Centralized software, by design, attempts to leverage as many of its server resources as possible and relies on a large amount of memory and fast processors to perform each software function efficiently. Centralized software, due to its tight integration, can be managed from a single point of control, but at the same time, it exposes a single point of failure and often cannot deliver the recovery capabilities that distributed computer systems offer. Distributed computer systems are more complex to manage but are much more resilient to failure. Cloud IT infrastructure is mainly composed of distributed computer systems, which is how cloud providers provide reliable up time to their customers. Running centralized software— designed to be run on a monolithic system—on cloud IT infrastructure would be inefficient. The software would run on a single commodity server offering limited memory and processor speed and would not be able to leverage the memory and central processing units (CPUs) available on other servers in the cluster. For the reasons listed above, EIP applications should be developed following a distributed software architecture, distributing software components or tasks across multiple average servers rather than one very performant one to take greatest advantage of the flexibility and scalability that IT cloud infrastructure offers. Figure 3-2. Cost comparison of on-premise and cloud architecture.5 5The graphic shown in Figure 3-2 is used with permission from https://blog.westmonroepartners.com/rain-down-cost-savings- with-cloud-based-business-applications/

Industry Practices for Sustainable EIPs 35 3.3 Use Layered System Design To further optimize the sustainability of EIPs and organize the distribution of software com- ponents across a server cluster, a three-tier or layer architecture, separating software components into groups or classes, is often preferred. As illustrated in Figure 3-3, the recommended three-tier architecture is composed of the following layers or groups of software components: • A user interface layer, also called a presentation tier, containing the various software compo- nents supporting the interfaces (mobile, web, or machine), and allowing portal end users to access the various functionalities of the portal. • A business service layer, also called the logic tier, containing the various software components supporting the functionalities (search, mapping, etc.) of the portal exposed through the user interface layer. • A data layer, also called the data tier, containing the software components providing data storage and archiving services to the business service layer. Each layer is separated by an abstraction layer (service and data abstraction layers) providing a standardized way to communicate between layers. This three-tier architecture is recommended for large systems such as EIPs, as it allows for the creation of portal applications that can be flexible and reusable. By segregating a portal application into the three tiers, any software modification or addition can be performed on a specific layer without affecting the others. This eliminates the need to rework the entire portal application in the case of tightly integrated portal applications. 3.4 Use an Event-Driven System Sustainable EIPs implemented on distributed computer systems could also benefit from the use of an event- or message-driven architecture to ensure sustainability, as opposed to a time-driven or request-driven architecture. In a time-driven architecture, the control flow of computer soft- ware is driven by a clock, and each software component responds to a periodic activation pattern. Figure 3-3. Three-tier distributed architecture.

36 Guidance for Development and Management of Sustainable Enterprise Information Portals This type of architecture is often found in software used in critical systems, such as aircraft and power plants. It is one of the earliest ways that enterprise software was designed. In a request- driven architecture, sometimes called a service-oriented architecture (SOA), the control flow of software is achieved by allowing software components to communicate over a network with each other and request data or actions from each other using standardized requests and responses. This type of architecture is more modern and flexible and is often found in retail and banking systems. Event-driven architecture is an extension of SOA that also leverages messaging between software components but does not implement direct requests and responses between software compo- nents. Rather, event-driven architecture broadcasts across all software components’ messages, conveying the state of the system through different communication channels. Other components of the system subscribe and listen to one or more of the communication channels and decide to react upon receiving the events being published. Event-driven architecture provides the benefits found in SOA, such as increased levels of reusability, higher interoperability between systems, and improved scalability, but also allows for dynamic reconfiguration of business logic by the addition of new event subscribers or the replacement of existing ones. 3.5 Leverage Open Source and Existing Software as a Service Using open source software on cloud infrastructure or cloud providers’ software as a service (SaaS) solutions is preferred over the use of commercial software solutions implemented on on-premise or cloud infrastructure. The rationale for this preference is that most commercial software does not offer licensing and pricing schemes adapted to cloud infrastructure flexibility. Most commercial software vendors’ offerings on cloud infrastructure are similar to their offerings for on-premise servers; vendors charge a yearly or monthly fee based on the number of CPUs or servers on which the software will be running. When put in the context of an infrastructure capable of scaling up and down based on demand, this kind of licensing scheme requires that the system owner purchase as many software licenses as the system will require to perform at its maximum during the year, even if the system only performs at this level for 2 weeks in a year. Also, on a day the system scales above the planned maximum, no software licenses will be available to support the demand. By using an open source software on a cloud infrastructure, the system owner is no longer limited to a fixed number of CPUs or servers to run its software and can scale the system up and down as needed. An alternative to the implementation of open source software on cloud infrastruc- ture is the use of commercial cloud SaaS products offered by cloud providers. While cloud SaaS products are commercial products, they are designed to provide users with the ability to scale up or down based on demand. These products are provided on a pay-for-use model, offering a much less expensive alternative to traditional commercial software on cloud infrastructure. Table 3-1 shows a cost comparison example between a proprietary database on premise (Oracle), an open source database on premise and a cloud SaaS database (Amazon Web Services [AWS] Aurora). 3.6 Maintain a Looser Governance A consequence of using distributed hardware and software computing systems, such as clouds, is that system components no longer need to be tightly integrated with each other and can be developed and maintained independently, using different software and programming languages without altering the efficiency of a system. IT governance typically is designed to help main- tain tightly integrated systems and attempts to centralize and standardize a recommended set of technologies. This approach is not ideal for any computing system, whether monolithic or distributed, as it imposes technologies that may not be adequate for many of the tasks that the enterprise software needs to perform. This approach often constricts the design of the computing

Industry Practices for Sustainable EIPs 37 Table 3-1. Proprietary versus open source versus SaaS cost comparison.6 Oracle Enterprise Edition on Spark Server EDB Postgres Plus Enterprise Edition on IBM Powerlinux AWS Aurora Type Proprietary Open Source SaaS Specification 4 sockets/32 cores 4 sockets/32 cores 4 servers of 8 cores Capital expenditure Server $62,874 $51,755 $- License fee per core Database $47,500 $- $- Partitioning $11,500 $- $- Data guard $11,500 $- $- Diagnostics $5,000 $- $- Total license fee per core $75,500 $- $- Total license fee per server $2,416,000 $- $- Operation expenditure Annual support/maintenance $531,520 $27,600 $- Server Instances $- $- $40,646 I/O Rate (1B I/O) $- $- $200 Storage 10TB $- $- $12,000 Backup 100TB $- $- $26,400 Total cost over a year + acquisition Yearly Cost $3,010,394 $79,355 $79,246 6Data shown in Table 3-1 are from https://aws.amazon.com/rds/aurora/pricing/ and http://info.enterprisedb.com/rs/ 069-ALB-339/images/business-comparison-edb-and-oracle-ebook.pdf system, imposing a specific technology that can make specific software components more difficult to develop, inefficient in operations, and even more expensive to maintain. A preferable solution would be to allow the best match of technology to component, taking advantage of the efficiencies of different languages and code libraries. To allow flexibility in development approach, agencies should adopt a more decentralized form of governance. This type of governance provides more team autonomy in software component development, hold- ing teams responsible not only for development but also operation and maintenance of their code and data, while focusing the standardization effort of the IT data governance plan on com- munication, security, and data quality.