I attended a panel discussion this week hosted by my college alumni association. The panelists were five Washington, D.C. venture capitalists and fellow alumni. Each had a different focus area, ranging from the U.S. intelligence community to the high tech sector to social entrepreneurship (individuals with solutions to society’s most pressing social problems). My main takeaway from the evening: all that really matters are great ideas.

Although I consider myself to be an entrepreneur, having started or helped start three companies, most of my time now is spent on the day-to-day reactive activities required to run a sixty-person company. It is very rare for true innovation to come from established companies. Fortunately there are plenty of good ideas at RightStar, including:

ADSync. Since there was no easy way in Remedy to synch up Active Directory accounts, we built our own utility. This brand new product has already been sold to two customers.

Service Catalog/PMG. PMG offers an actionable service catalog that works with SDE and Remedy. After seeing the demo, we realized that this is the first “game changer” in our space in a long time. RightStar quickly became a partner.

dbObjectCreator. We’re always thinking about ways to significantly reduce our SDE implementation time by automating the implementation process, leaving more time for better upfront process and design.

ScanStar for SCSM. ScanStar (a.k.a. MagicWand) will soon work with SCSM, Microsoft’s new service desk product. Microsoft’s entry into this market could be huge, meaning that ScanStar for SCSM should be a big seller.

MagicPortal. SDE Client Services did not meet a customer’s requirements, so we developed MagicPortal, a better product that we have already sold to several customers.

In my ITIL v3 Foundation classes, students new to the terminology of formal IT service management often struggle to wrap their arms around the concept of the Service Catalog. Most IT staff can understand a category tree or a category-type-item schema. They look at the services they support from an IT point of view. But when IT needs to communicate to their customers, it’s important that the Service Catalog also have a business face. And IT should understand which external facing services are impacted by the business services they support.

For example, I buy books from Amazon.com. Books and the shipping that sends those books to my door are the services I buy from the business. The business in turn depends on order fulfillment and tracking systems, among others, to ensure accurate and timely delivery for me. In this example, “books” and “delivery” are the external services, which link to “fulfillment” and “tracking” systems in the Business Service Catalog. Those systems in turn link to “database”, “server” and “network infrastructure” in the IT Service Catalog.

It’s important that items in the Service Catalog be defined in simple terms with accompanying detailed descriptions so that the service definitions are widely understood. According to ITIL, the Service Catalog should define:

Of note here is the reference to supported services. Most services or systems, for example, will require network infrastructure. One challenging aspect of defining the service catalog is defining and recording the dependencies and relationships among services and components or configuration items (CIs). This is also, however, an exercise that offers great returns and benefits to the IT organization. If IT can identify relationships among services and CIs, then they can make more informed decisions when planning service outages and changes to the infrastructure.