Implementing an effective data model

After logging in as Admin@FSGPricingTest and COE@FSG, you notice a pattern. The classes shown in each application’s Data Types view are the ones that the application owns. The application is primarily responsible for testing, maintaining, and defining how to package and deploy those data types.

From the FSG application, the Booking team reuses the Persons and Places classes; to not do so cannot be justified.

Use configuration sets or application settings to maintain constants

The first stage in the Booking application involves quoting the price to a customer (Contact) to host an event at a certain location. The Booking application can reuse the data types owned by the FSGPricingTest application. There is a test-only data type named PricingDisplay that is defined by the FSGPricingTest application; this a clue that the Booking application must define its own PricingDisplay class.

The Booking team considered using categorizable Application Settings. The Booking team likes how the FSG COE’s solution supports dotted-path syntax to a property with a data type other than text.

For the Booking application specifically, the Booking team likes how the FSG COE modeled an example event quoting screen where a PricingDisplay data type was utilized. The Pricing component supports a PricingDisplayPage page name parameter within three data transforms: Work- WorkRecalculatePrices, @baseclass RecalculatePrices, and FSG-Data-Pricing Recalculate. The capability is there; the Booking Team might as well use it. Doing so saves the time and effort spent building that functionality themselves.

The Booking team has created a table like the one used to analyze and review the FSG COE’s data model. The Test-Only Data Types column is repurposed as a New Data Types where ownership is undecided column.

The Booking team’s BookEvent case needs to capture information about an event, such as its start and end date.  Hosting an event is core to FSG’s business model, yet the Booking application’s BookEvent case is the only place, so far, where an Event data type is used.

The Booking team can extend the COE-owned FSG-Data-Hotel class for its Hotel application but does not see an immediate need to do so.

The Hotel application and Hotel Proxy application communicate by using the RESTful Pega API. For various reasons such as application size, security, and ease of maintenance, the Hotel Proxy application is not built on the Hotel application. Either a RoomsRequest data type must be defined at the FSG COE level for both applications to inherit. The Hotel and Hotel Proxy applications must use another mechanism to share the class. However, it is necessary to share the REST integration classes that both applications use. The logical conclusion was to build a component to house the shared classes and related code.

The COE has not defined a set of data types related to weather forecasting. So, the Booking team must decide whether its Weather Forecast application owns those data types. Weather forecasting is not essential to FSG’s business model. Should other applications use the same weather forecasting data types but disregard weather preparation? What impact is there if the code to perform both are packaged together? The assumption is the weather forecasting code is lightweight.

The Parking application deals with different types of locations, such as a parking lot or garage. Attendees attending an event and wanting to park nearby would want to view their choices where to park on a map.

A Shuttle application can handle any location, whether a venue, hotel, or where cars are parked. This knowledge reinforces the notion that FSG COE must define a ParkingLocation class. The Booking team can directly inherit, or pattern inherit, that class as needed.

Finally, a Shuttle application requires data types that are related to shuttle trips. The Booking team can define its data types, but can other applications leverage an abstraction of those Data Types such as Trip, Vehicle, and Company?

Hosting an event is central to FSG’s line of business. The potential exists for other applications within FSG, such as Billing and Advertising, to use the same data type definition. As time goes on, other applications can add properties to FSG-Data-Event. A customer might contact a Booking Team member to ask how an event hosting is billed. Property-Read ABAC security can be applied to mask information that only Billing Team members should be allowed to view. The Booking team member can relay the information that the team member can see and then refer the customer to the Billing team if the customer wants detailed information.

A best practice is to standardize the definitions for Persons and Places across an enterprise. It makes sense that the FSG COE maintains the core definitions for classes that extend FSG-Data-Location. One reason for doing so is that Locations are stored in the same CustomerData schema table. When it is built, the Shuttle application must define a Trip as taking place in any two Locations regardless of the type of Location. Best to let the FSG COE take ownership of a ParkingLocation class.

The following table records the decisions made regarding the original set of undefined Data Types.

It is unknown when the Shuttle application is due for construction. The Booking team can certainly benefit if  FSG COE designs an abstract data model where any Vehicle with a limited capacity makes Trips between two Locations. In all likelihood, the Company that owns the Vehicle is not FSG. FSG does not want its employees to become full-time shuttle dispatchers. Instead, FSG wants to automate decision-making as much as possible. For example, the system runs by itself unattended. Over-reliance on stale data could lead to a “garbage in = garbage out” situation. The solution must be capable of accepting data in real-time and making decisions in real-time.