This article will have more questions than it will have answers, so please send me any thoughts or feedback you have on this topic. As most of you know my doctoral research was in the establishment
of trust in an online environment for the small hotel industry. Trust, design elements, web based application, and business models have an enormous impact on the implementation and delivery of
metadata solutions within the enterprise. A few weeks ago, a co-worker made some comment about adding a reservation process to our collection of services within the metadata environments. Let’s
begin by reviewing what a reservation is and what value it may bring to the corporate environment.
The availability and reservation process is one of the first opportunities a hotel has to interface with the customer. The impression of this process can set the stage for the perception a guest
may feel throughout the process. Reservations refer to the process of holding accommodations for future guests (Dittmer, 2002). Quan (2001) indicates that reservations are used through out the
hospitality industry to eliminate customer uncertainty about the price and availability of the desired service. A reservation can fall into three categories. A guaranteed reservation is reserved
with a credit card or some other payment before the check-in process. A walk-in customer does not actually make a reservation but rather takes an immediate purchase of the product. A regular
reservation is not paid in advance and the room is only held for a specific time period (Weissinger, 2000). The reservation system allows the hotel operator to access the inventory of room
availability for a specific unit and time period. Once a reservation is made the system immediately updates the inventory and ensures the room is not promised to another customer. In addition to
providing information and reservations, the front office provides check-in and check-out services.
Would a reservation service provide any value or is it a waste of time, dreamed up by someone that spends way too much time thinking about metadata? Don’t answer that. Suppose for a moment that
you had a metadata repository that holds common services used inside the corporation. These services are enterprise enabled and are built with reuse in mind. You are the lead architect producing a
design document and reuse of common services is important to the organization. The Service Level Agreement (SLA) indicates that the service you are interested in is running at about 90% capacity
based on the transaction volume. Based on your estimate, your project will increase the capacity to 96% so you don’t see any issues or concerns with the integration. However, you take a glance at
your co-architect and she is working on a design that will utilize the same service. After she heads off to a power lunch, you take a peek at the design and notice the increase in the utilization
of the same service (97%). I see trouble on the horizon. Which project will complete first? Who will flip the bill to buy additional hardware or infrastructure in order to increase the capacity of
the service? What if you could reserve capacity of the service, would that help in any way? Of course it would; the producer would be able to see very early in the system development lifecycle that
they need to expand capacity. They could then pull in all of the customers and get funding to expand the transaction volume or increase disk storage. This would smooth out the demand and be more
proactive versus reactive. Ok, on paper this sounds like an idea worth considering but I am not so sure what other data professionals are going to think. We will come back to this thought.
A typical hotel reservation performs a variety of services for both the producer and consumer. First, the consumer is gently walked through the purchase process. Are your customers gently walked
through the integration process? In addition, we collect a record of the customer which provides the basis for a customer relationship in the future. Do you know who is using your data elements,
web services, or XML schemas? The foundation of a reuse strategy will require you to know who is utilizing your assets. Some of the basic information collected at reservation time is interesting as
well: contact information, product selection, service requests, dates of usage, number of guests, and time of arrival. Would this type of information be useful in a metadata implementation?
Contact Information
When metadata is well managed then we understand who is using the assets. The foundation of any metadata metric program will require knowledge of who or what organization is using the assets.
Contact information is critical for the consumption of an asset, but also for the production of one. Remember, metadata generally acts as a broker between the producer and consumer which means we
should collect information from both our customers.
Product Selection
By definition, a metadata repository is a catalog of products that the technical community offers to fulfill business requirements. As we move toward Service Oriented Architecture (SOA) and Event
Oriented Architecture (EOA), access to data will be done at a more distributed level. In other words, access to the data will be provided by foundational components and direct data access API’s.
Web services and common services will be the integration points for the enterprise. While we will continue to utilize metadata as a data descriptor, describing the service access will become more
important. Hence the need for a reusable asset catalog.
Service Requests
IT man does not live by product alone. It is a services world and the sooner we in the technical community understand the impact of this fact, the better off we will be for what’s coming down the
pipe with out sourcing, commoditization, standardization, and automation. Internal organizations that fail to offer services with their products are doomed to mediocrity and replacement when
something/one comes along that is faster, simpler, or cheaper. A reservation would allow you to offer services and smooth out the demand line for those services.
Dates of Usage
This data is definitely a requirement. When will this project or program begin accessing or using the asset? Knowing this information will enable the internal organization to deploy resources when
and where they are needed. Suppose that you send out a product or service offering to 25 internal customers, the second to the worst thing that could happen is that no one responds to your
offering. The worst thing is that they all respond at the same time. Dates of usage would also help you retire assets from the collection. The Dublin Core has a nice metadata keyword for this:
DC.Date.Valid.
Number of Guests
In the asset world, the number of guests could be transformed into the space required on a shared disk array or expected transaction volume on a service. Different assets will require different
needs to be addressed but the bottom line is that you are reserving some level of utilization for the asset and everyone needs to plan accordingly.
Time of Arrival
Ok, when will you start accessing the asset? We want to be sure to have additional resources available during the first few days in order to ensure that your requirements have been met and to
ensure you haven’t underestimated your utilization requirements.
A metadata reservation application sounds like an idea worth checking out. The benefits of such a system would include improvements in planning, improved business continuity, higher levels of asset
management, and closer relationships with both the consumers and producers of the asset. In addition, knowing who is using your assets would enable additional services like subscription services
and escalation notification. Building a community of support for our assets and sharing lessons learned doesn’t sound like bad idea. What do you think?
