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 Contact, Address, and Location classes; to not do so cannot be justified.

The Constant class is reusable. Using the Constant class avoids hard-coding values that the business may want to adjust, control and maintain. The FSGSample application does not define a test-only data type to demonstrate how the Constant class is used. Instead, the FSGSample application uses the FSG-Sample-Work-TestConstants class itself to demonstrate how the FSG-Data-Constant class can be used. The Booking team needs to decide on an approach, either define a ConstantProps data type or use Application Settings or something in between.

The Booking application can potentially use the Feedback class after an event's conclusion. The class is used to capture from the customer how well FSG hosted the event.

The Booking team has concerns about the Feedback class. The FSGSample application does not demonstrate how to use the Feedback class. Presently, the Feedback class is abstract and contains only two properties. Other rule types such as sections or data transforms are missing. The Booking team also wonders if an Event Manager must populate the values after corresponding with the customer or if automated approach interfaces with a Pega Survey form.

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.

FSG COE’s Constant class has properties such as Application, CaseUsage, Description, and DataType. The FSG COE’s FSGSample application contains two test cases related to its FSG-Data-Constant data type.

FSGSample’s TestAppConstantsLibrary case defines a D_FSGSampleConstants data page that sources a data transform named LoadConstantsForClass. The Booking team follows this example to define D_BookingConstantProps, D_HotelConstantProps, and D_WeatherConstantProps data pages.

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 Booking team could extend the abstract FSG-Data-Feedback class to form a concrete FSG-Data-Feedback-EventVenue class. The Booking team recommends that FSG COE add a reference property to FSG-Data-Feedback. A report definition is defined within the -EventVenue class and performs a JOIN to FSG-Booking-Work-BookEvent and a JOIN to the BookEvent case.VenueGUID reference property to FSG-Data-Venue. The venue’s name might change since the last recording of the data. Defining a JOIN by using a name property is poor practice, and it is a data integrity violation. The venue's name can be recorded for historical reasons, but the property name should reflect that fact (for example, .HistoricalVenueName).

The Booking team’s extension of FSG-Data-Feedback can be incorporated into the FSGSample2 application to make other higher-layer development teams aware of what is possible. On FSG’s to-do list is developing a common way to send out a Pega Survey, receive the response, and then persist the response to the appropriate FSG-Data-Feedback able. 

The persisted data does not include a property where a Net Promoter Score has been converted to a category (promoter, passive, detractor). Doing so is also a data integrity violation. A report definition can utilize a custom three-input parameterized SQL Function to derive a category. The first parameter is populated using the raw promoter score property. The second and third parameters are the start and end of the category’s integer range (for example, 0 and 6 are the start and end of the “detractor” range). The custom SQL Function outputs 1 if the first parameter falls within the range. Otherwise, it outputs 0. The report definition aggregates the column using the SQL-standardized SUM() function.

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.