On Demand product and ROI strategy

By Neil McEvoy 07 Aug 2003 | xSP-strategy.com, special to SearchWebServices.com

Digg This!     StumbleUpon     Del.icio.us

Market Analysis

On Demand product and ROI strategy
These ideas about enabling On Demand can seem pretty complicated and unusual, so how easy is it to make an investment in the concept without being exposed to considerable risk? How easy are the technologies and concepts to implement, and what ROI potential is there?

Actually, surprisingly easy and low cost given the potential for new revenues they offer for those getting involved.

This is most easily described by the fact it requires no new infrastructure. Indeed its core tenant is one of finding a whole new dimension to "sweat" existing assets. I.e. make more money from infrastructure you have already purchased. The On Demand capabilities are achieved not through new infrastructure being deployed, but by the existing set being "upgraded" with new semantic capabilities to achieve new layers within the network stack, a model service provider technical staff will be easily familiar with. I.e. after presentation you have [The Customer].

Establishing and using a global variable of this nature presents the opportunity for numerous organizations to collaboratively create new products and services where they all profit greatly. The greater the richness of the profile of [The Customer], the more new processes can be created that utilize the new elements. For example, an additional [Network Premium] tag could be established that dictated that network message traffic that carried this extra element would receive priority over other packets.

If all networks from end-user to application reflect this policy then the user will enjoy a considerably improved experience in terms of performance and quality. In effect it would create a "business class" version of the Internet and other networks involved in delivering services, and could be used to create all manners of exciting new products. VOIP is an obvious one, but it would be equally valuable for everything from gaming to On Demand TV.

Naturally network providers would charge more to prioritize the traffic in this way (hence the reason they would implement it) but this would just be reflected in the policies of those utilising it. For example, the application or games provider would charge increased subscription rates for this class of service too. Then it presents the customer the ideal choice: Pay more get great quality, settle for less pay less. Some customers will always pay more for a superior solution because it is worth more to them too. Concentrating increased service quality into this segment is the heart of maximising profits.

Business process QOS
This is most easily summarized as QOS for business processes. As the enterprise market begins to expand their use of XML Web services and other agile business methods, they are going to increasingly hope for infrastructure that can reflect the revenue-critical nature of these processes. This is the key point, this is what XML Web services are: Commercial workflow. To ensure their own organization is providing fast, effective and reliable service to their customers it will become increasingly obvious that they need to be buying from their suppliers equally dynamically. Therefore those services that are satisfying buying demand will become increasingly focused on in terms of their reliability and performance.

The only way a telco can turn up at an enterprise customer and offer a guaranteed level of performance, security and reliability for their business messaging is if they are doing so as part of a broader industry federation where the product policy is in equal effect across their competitors. This way any company considering publishing messages to their network (e.g. through web hosting) can do so knowing the QOS methods offered are implementing across numerous other networks that their customers and suppliers also connect to.

This is the VISA effect for xSPs: Competitive organisations happily existing within a greater union because by doing so each party gains more than they had before.

Short-term ROI
However, the power of working in this way is not dependent on everyone being a member, indeed its benefits are immediate as soon as there are two members of the federation working from the same data. This is particularly so when both run large networks in their own right.

For example, a large telco and one of their large hosting customers could agree to work in this way, sharing a singular reference for [The Customer]. If they do, and also implement the shared understanding of [Network Premium], then improved allocation of resource for just their customers could be implemented on the service providers network. Although this is in effect only on their network, it is still in effect, and particularly when you consider the congestion that can occur within local data-centres that host tens of thousands of web hosting servers and so forth, then this policy would be extremely valuable. Indeed while this project is running, they would be the only customer benefiting from it. It is a scenario where being the first to take the leap actually offers more benefit than waiting to see how it develops.

The [Network Premium] customers of the xSPs customer would enjoy improved performance.

Furthermore, combining this with an autonomous, distributed platform for provisioning computing capacity and the telco has the basis for a pure On Demand application hosting solution. I.e. whenever the monitoring process detects that there is a [Network Premium] customer not being served by an application/process server, and then it will simply find available server capacity, install the required 'shell' to run the process (e.g. might be BEA, Microsoft, or likely in the near future BPEL4WS or similar), allow it to execute to fulfil the demand, then clean down and leave the machine. Billing data for the use of bandwidth and compute capacity would be generated and incorporated somehow into the service billing model.

So, by only working with just one other entity, already the model yields considerable benefit. As this becomes clear others will join and so the value increases exponentially.

The strangest source for new growth
The second dimension that makes the investment profile of this strategy so attractive is the fact it is fundamentally a model of sharing, indeed that is everything that it is all about.

It is no surprise then that there is a clear opportunity to maximize profitability and decrease risk by sharing the investment vehicle with others. There will be in essence a finite cost to create the architecture, and the double whammy is that the more people who join in, the cheaper it gets for everyone while increasing the level of benefits because more network providers will become part of the policy framework.

Literally, the less you spend the more benefit you will enjoy.

Federated marketplace services
As well as bringing product benefits, the strategy also offers potential for increasing sales. If you have demand for something where is the best place to find supply for it?

If you needed managed storage then a forum of all the storage service providers would seem logical, wouldn't it? Similar for any other service, such as web hosting, a forum of all web hosting providers would be the most useful place to register your demand for it.

Therefore, you either need to i) join one, or ii) start one, and you will succeed at attracting more demand and creating superior products.

The most high profile example of a loosely coupled federation is VISA International. No stockholders, no one owns it, yet it is one of the most successful commercial entities in the world.

Ongoing services and profit yield
As the depth of the semantic profiles increases in sophistication, so will the services that can utilize them. In keeping with the ambition to always be generating maximum returns as each step is taken further into On Demand capabilities, the key is finding new ideas and revenue opportunities that sweat the assets even further as they are created.

The above utility computing example highlights how this could be put into effect for one major customer, but equally the service provider could use federated services for their own benefit.

In the previous article Identity Federation: The backbone of On Demand, the simplest example given is that of [The Customer].[Postal address]. I.e. a universal schema for the postal address of each individual. Its value is that it immediately obviates the need for "data cleaning". With this federation in effect and including just one or two large networks that are key points for this data type (e.g. the postal delivery services), then any members of the network will automatically have their data updated. Since a large telco themselves commonly runs one or many call-centres and other similar CRM practices, then this presents opportunity for immediate cost-saving; in some cases, probably paying for the technology work required in its own right before any other benefits are enjoyed.

Having got the hang of this type of thinking, then its capabilities could be quickly extended into a series of similar services for both consumers and businesses to use. For example, contact data. Every person and business operates a database of contacts: Personal information about friends and colleagues such as their mobile phone number. By offering automatic address book synchronization through including the mobile phone itself as part of the federation, then whenever your friend [John Smith] changes his phone number or e-mail address, it is reflected in the address book on your phone, as well as in your Microsoft Outlook.

This is relatively easy to roll out because once an integration pattern is established with a new device or network it is available for use elsewhere on the network. I.e. the network only needs to establish an interface with Microsoft Outlook once to be able to then achieve this with everyone's Outlook.

This presents a multi-yield ROI opportunity for some projects. For example, if the telco runs Siebel as its main CRM system, then once they build a network integration pattern with it, it therefore becomes valuable to anyone else wishing to connect their Siebel system in the same manner, since they will be seeking to connect to the same federated network. Although the postal address service is the simple one, it is clear how this is the same connection in effect each and every time.

This is where enterprise IT strategy begins to become utility enabled. Through this model interoperability becomes less about one-off, complex EAI consultancy that telcos simply cannot adjust their business models to suit, it instead becomes more about offering a connection to another network: The universal 'dataweb', offering a multitude of e-services. The method of connection is always the same.

Offering customers access to pipes with services on them, now that telco salespeople can understand!

Device and network innovation
Continuing this further and service providers could begin to offer a wider variety of devices and methods of integrating devices and the data they use.

For example, if you were able to flag folders and files on your PC at home with a [My Data] tag, then you could repeat this for any other device, such as your work PC, laptop, PDA or TV. This means that these devices then agree to maintain a consistent but contextually relevant view of this data on 'themselves'. In other words, you won't need to back anything up, e-mail files to yourself, save them to a central server and so on, whatever you change on one machine will be reflected throughout the network. So when you arrive home from work your home PC is simply identical. The contextually relevant part refers to how each device would display and use the data. A PDA may only be capable of displaying certain types of files, therefore the replication would only include those. This requires another layer of semantic encoding within the object where it describes how different devices will handle the same piece of data.

This also highlights the importance of a greater focus on contextually relevant, network-centric devices. The PC is the most prevalent device on the corporate desktop, primarily because of its programmability. However this comes at a price and its management is an ongoing headache and pit of costs for IT, both in terms of the complexity and the hardware costs. This means application developers are constantly trying to make different functional processes be represented via Windows.

In a high-volume environment like a call-centre it is questionable whether this is the right approach because it introduces a layer of unreliable devices into the equation, devices that are not easily swapped in and out nor necessarily designed for the process of answering phone calls or incoming messages. It is possible with a more open remit technical teams could begin to fashion a complete console station that much accurately reflects the physical actions constantly in effect, making them easier to use, more reliable and faster. No more "Oh sorry, the systems running slow today."

Furthermore, since the potential of distributed call centres was discussed, it is possible that it may become completely distributed, in that call centre agents may even be on the move. They will therefore need equipment that reflects the nature of this environment, possibly with a greater emphasis on Instant Messaging via mobile networks and so forth.

Conclusion: Service building blocks
This last example highlights the value of building a platform capable of offering access to discrete processes on a modular basis. If the approach is one of a collection of "lego" style building blocks, where complete solutions for the entire call centre operation are achieved through assembling and compiling a series of services, then each of these individual services is also available for other models. For example, the same configuration could be presented as the basic customer communications package for a one man SME, where he can receive enquiries from this web site via Instant Message to his mobile device, making him always available. I.e. you can offer one individual CRM process without having to buy a whole CRM system.

With a modular, data-centric approach to integration, then each service can also generate usage data for those individuals identified as using them. For the SME, this just means one single easy to use bill, for the large enterprise customer this could be a complete set of financial reporting processes that utilize this data to enable cross-charging between departments. Another huge value add achieved not through the investment in new infrastructure, but simply through applying a consistent semantic framework to data that is already generated. Solving this for enterprise customers would also solve the OSS integration challenges faced with adopting On Demand.

This means that once any service is created and made available to the network, anyone can make use of the service and "sweat the asset" that little bit harder. The On Demand strategy encourages you make available all of your assets within a safe and constructive methodology to every single device and user on the network as a potential resource for them to use or sell on to others. Self-organising growth of profits.

And this even before considering the idea that being the primary infrastructure for the business process e-marketplace presents the opportunity to begin deriving a percentage of each transaction conducted.

About the author
Neil McEvoy is CEO of the Genesis forum, an industry initiative of Service Oriented Architecture vendors describing the business benefits of their technologies. He is the Chief Architect of the On Demand framework, the platform for autonomic business models that match demand and supply perfectly, and engender agile businesses. He can be reached at neil.mcevoy@webservices-strategy.com.

For more information:

• Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
• Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
• For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
• Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

• Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
• Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
• Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
• Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
• Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary