[CNST] Potential technical approach with respect to engaging vendor interest

Erik Barkley Erik.Barkley at jpl.nasa.gov
Fri Jul 13 01:06:57 EDT 2007


All,

At today's telecon we discussed one of the issues raised by vendors 
at the recently concluded OMG meeting. Namely, how to engage vendors 
in building interest in and implementing standardized service 
management.  As you may recall, I indicated that I thought the 
biggest potential opportunity for vendors would be to concentrate on 
delivering software tools/capabilities to the flight project side of 
the service management interface (aka UM -- Utilization Management in 
CCSDS SLE reference model terms) as this represents far more 
potential customers.    The other side of the interface, CM (SLE 
Complex Management in reference model terms) is, I think, a smaller 
market and more involved as this is where the TT+C services being 
managed are mapped into equipment -- I think there is probably a fair 
amount of  CM specific idiosyncrasy that has to be dealt with between 
the various networks to properly implement this -- perhaps more than 
vendors may be willing to consider, at least with respect to 
developing a product that can be sold more or less off the shelf.

Sticking with the customer or UM side of the interface, it occurs to 
me that a potential  model to pursue and suggest to various vendors 
is analogous to the TurboTax model.  I realize that I am veering into 
dangerous territory by comparing service management with the US tax 
code, but there are some parallels in terms of complexity  -- it just 
happens to be more geometric and physics related for us rather than 
legal code.  In any case, the reason I suggest this, is that those of 
us in the service management working group have long been aware that 
the service management recommendation covers a significant number of 
use cases.  The prototyping done to date has, by necessity, tended to 
be very "literal" when it comes to developing the GUIs for driving 
testing and not really operated at a higher level.  But it has also 
been recognized that with standard messages/well defined referential 
framework under the covers there should be ample opportunity for a 
client GUI to be far more sophisticated.

If you have never used the TurboTax software before (and I  do not 
have stock in Intuit),  it offers you the ability to provide the 
information in terms of an "interview" style such that you never have 
to look at/understand a tax form.  However, it also gives you direct 
access to the tax forms at any time should you wish to enter 
information that way. Either way, it packages up all your tax info 
encrypts and ships it off to the "service provider" (tax 
authority).   The suggestion here is that I believe there is ample 
room for developing these kind of higher-level "wizards" or interview 
dialogs that shield the end user from having to understand all of the 
details of the service management parameters.  For example, I could 
envision, that there could be a telecom analysis section where 
configuration profiles could be developed with respect to link margin 
modeling that results in capture of configuration profile 
standardized parameters.  Similarly, another section of this client 
software could walk the user through the various 
contingencies/scenarios all the while building a service package 
invocation message  under the covers.  And similarly to TurboTax, one 
could envision that the client would allow direct access to the 
"forms" which in this case represent directly supplying parts of the 
messages exchanged between UM and CM.  Eventually this could evolve 
into something that handles higher level use cases involving multiple 
standardized SM operations as matter of course.    Presumably, with 
some flexibility/edit preferences options, this could be made to work 
for interfacing to any CM implementing the CCSDS recommendation and 
have a various parameters for tuning the underlying communications 
involved (i.e. Web services (SOAP/HTTP) SMTP, etc.)

There are  other things that I think could be considered here as 
well, but I thought I would get the main idea across as I will be out 
of the office tomorrow and next week.  Any comments?  Does this seem 
like a reasonable idea to think about in communicating with 
vendors/getting them more more enthused about this (albiet from more 
of a technical perspective)?

-Erik.





More information about the CNST mailing list