How to take a Transaction Based Vendor Relationship to the next level?

In the following blog, I talk about "What is the definition of a strategic partnership with a vendor?" and outline a few thoughts on how large enterprises should engage with their vendor partenes and what the expectations of such a relationship should be.  A fellow blogger of mine expressed his "dissapointment" with vendor partners and their focus on selling new product as opposed to helping maximize the returns from the existing IT Assets.

I whole heartedly agree the pressure from vendors can be exasperating.  I was thinking if there is a way to turn this around. What if  as an example, your IT product vendor were told that they would have to provide expertise (at no cost) to solve current interoperability issues or resolve performance bottlenecks between their product and one other product while show casing a operations admin and management/ monitoring tool - OAM tool?  This would be their elite product engineering or premium consulting service participating on-site mentoring your team and not the "support" organization which has to trouble shoot remotely.

Another example, if this is a package solution vendor with a long deployment cycle then the vendor can be asked to offer (again for free) analysis tools or processes or best practices and other accelerator kits that improve speed to market for their product, with the chance to demonstrate components of their next generation product.  Again, the vendor has to part with IP (intellectual property) and address your pain point with the chance to demo a product that would or could be a fit in "your" enterprise.


The result would be the ability to extend or enhance the life of existing investments, while evaluating the vendor product, vendor processes and expertise in a real life scenario.  Most importantly however, you are putting their resolve to test as to whether they are able to or willing to be your strategic partner and not just a transactions based product vendor.

Of course, I would be remiss in not stating that VMO, PMO and your legal departments would have to help with insuring this was a fair and scientific discovery process and also, that the licensing models were conducive to both parties.

As always your comments are welcome. 

Surekha -

Key learning from Home Entertainment/Automation that can be applied to SOA/SaaS

Unlike the previous generation where technology innovation was driven by enterprise needs, over the past few years technology innovation such as smart phones, multimedia, game consoles, multimedia and social networking is being driven by the consumers. In short the consumers have gone digital, whether it is HDTV, Blue-ray, Home automation, smart phones, media servers or IMS (IP Multimedia Services). The vendors manufacturing these devices and services understood that unless there are standards adopted by industry - the consumers would not adopt these technologies (especially as they are not cheap). It is for this reason, most of the large vendors (hardware, software, manufacturers, protocol stack providers, etc.) got together to form the Digital Living Network Alliance (DLNA).


Their objective was to resolve the following consumer challenges:

• Products designed for the home should be easy to install, provide noticeable user value and be affordable
• Product must inter operate with each other without requiring the consumer to undergo complex setup and configuration for connection between devices
• Digital home products must inter operate with each other and with existing CE devices such as TVs and stereos.

Doesn't this sound very similar to the current IT Operations challenges?

The above diagram illustrates DLNA's view of the customers needs (source: DLNA). In order to be vendor neutral and provide the consumer the ability to control any service (yes! they call it services) the DLNA members standardized the technology stack (as shown below - source DLNA).

The key learning here is that the vendors adopted Peer-to-Peer (P2P) for device discovery, control and Media management. For now they have all adopted UPnP, especially as most existing devices at home (desktops, laptops, storage devices, game consoles, IP based TVs, Stereo systems, network hubs, etc.) support UPnP. Some of the vendors such as Microsoft support both UPnP and WS-Discovery and it the long term (once the backward compatibility issues are addressed) the industry may migrate to WS-Discovery.

For those getting ready to purchase TVs, Phones or other Digital Devices, I would recommend you verify that they are DLNA Certified.

The next obvious question is What does this have to do with SOA/SaaS? Well! why not use this same approach for deploying services? It would make life much easier for IT Operations and potentially eliminate the need for additional ESB hops in the network. Yes! I am back on this topic :). The Services-Oriented approach, it is basically a P2P architecture, i.e. a consumer invokes a producer. As most of the large software vendors have made a commitment to adopt Services Component Architecture (SCA) and developing the SCA Run time engines, it would great if they could adopt either UPnP, WS-Discovery or some other P2P technology. The following diagram illustrated the joining of new node/service(s) to the P2P network.

Benefits:
Following are the benefits of adopting this approach:

• Based on the SCA standards -unique (logical) service name for services both for defining and invocation. Do not need to know the EPR (physical location) at the time of deployment.
  
• Multi-cast availability of service whenever an instance come up - dynamic configuration does not require IT Operations or tools (even if they are automated) to change configurations.
• Service maps (for a predetermined domain/network) maintained at each node. Complete map could be maintained in the Super peer (read up on p2p architecture for more details).
• Eliminate the need for Service Registry in production. As each instance of the node and services is maintained dynamically by the Super Peer - there isn't a need to maintain and administer a Service registry.
• Eliminates the need for having a separate monitoring agent on each node, especially as each instances could updates it's own service performance details in the P2P map.
• Universal administration tool could be used to configure one or all the instances at any node and propagate the changes across the network.
• As the consuming services would know the EPR of the producing service, this eliminate the need of an ESB.
  

The Newton: Component Model (Key technologies, OSGi, Jini, SCA) is the only run time engine I know of, that supports both P2P (Jini) and SCA. The Apache Tuscany project does claim to support JXTA (P2P) binding and have not researched it as yet.

Just my thoughts and as always do feel free to drop me line with your comments and/or feedback.

- Yogish