Vendor need to adopt "Common Sense" Strategy

A lot of vendors are jumping on the band wagon about the latest jargon such as SOA, Web 2.0 (or Enterprise 2.o), BPM and now WOA(?). It does make sense from a marketing point of view, however they also need to adopt a "common sense" approach.

Following are a few of suggestions to the large ISVs (Independent Software Vendors).

The Platform is the application:
This is true and that a majority of IT organizations are demanding, starting right from the CIO down. This is true not only for enterprise solution but also for consumer solution, resulting in all major Internet (what do we call these companies now? ) companies such as Google, Yahoo!, Facebook, eBay and Amazon.com are taking this approach. For this discussion I shall limit it to the large Enterprise ISVs.

All the major ISVs have announced and invested heavily in developing their next generation application based on a unified middle ware. The message I am hearing from these vendors is that they will support the current version for quite a while (so if you have PeopleSoft 8.x you may be fine until Oracle decides to pull the plug) but they do expect you to upgrade (migrate - and yes! this cost you a bundle!!!!) to the next generation.

This approach really puts the IT organization (customers) in a spot, more so from people skills point of view. First, it will take time for the current staff (or SI partners) to come-up to speed with the new tools sets and second, the early adopter may pay the price to finding major bugs in the field, especially for their mission critical applications such as Finance, Order Management, Supply change, etc. Don't want to have major problems there. I would like to once again repeat that vendors need to incorporate SOA infrastructure in legacy application. If this does not work for them, they why not support the existing (legacy) applications from the next generation development ?

Lets take the case of an IT organization using PeopleSoft 8.x. Why not provide the PeopleSoft developer to developer to develop/modify existing work flow/application logic using their SOA Platform development tool? Agreed Oracle will have to invest in making this backward compatible for deploying the solution to PeopleSoft 8.x. However, this approach will get the existing support engineers up to speed on the latest tool resulting in faster adoption of the next generation platform.

End-to-End Life cycle Management:
Most ISVs, especially the large ones, do not provide an end-to-end life cycle management for their product stack(s). Of course, they will definitely claim that they do - but not really. How many software companies provide the capability for CIO and the IT leadership team keep track of all their major investments? also, how many of them provide the capability to get realistic feedback of the solutions deployed? None - as far as I know. Most of the Strategic IT organizations have been able to put this in place by procuring multiple solutions (IT Governance tools, EA tools, BPM, Enterprise Monitoring and Management Solutions, BI, etc.) and a lot of $$$ to stitch them together. Wouldn't it be great if the ISVs put something together that could be plugged in? Even if it just only for their solutions?

Provide Complete Solutions:
ISVs must provide complete solutions - not just point solutions that requires a lot of time and resources to customerise the solution. Lets take the case of Master Data Management (MDM) - all major vendors provide this solution (and one of them has 4 MDM products, including UCM) but is only a point solution. Why don't the ISVs integrate their MDM solutions with at least all their major (if not all) applications such as CRM, Order Management, Finance, Supply chain and Customer Support? Also, why not also provide the customer with a list of best practices and governance models (for free)?

It may may help if we all collectively push back on the large ISV and also have their Products Managers from ISVs spend 3 months in an IT Organization. Just a thought.

Vendors need to focus on providing practical (real) advice

Since the end of last year - I have had the opportunity to talk to a number of CIOs, Chief Architects and business executives for large enterprises and one of the constant frustration I have heard from the end-user community (IT organizations) is the lack of practical (real) advice from the vendor community.

Following is an example of a simple Business scenarios:

• In order to increase it's revenue Business Operations would like to learn more about the customer - to identify opportunities for cross-sell/up-sell.
• They approach their partners - typically their preferred SI and/or their preferred software vendors.
• Depending on the vendor (including SI - their resell relationship with the ISV) they would recommend a Data Warehouse, Business Intelligence, EAI and/or Master Data Management Solution. In addition, they will also be willing to guarantee, typically as a fixed bid, implementation within weeks/months (typically 3 to 6 months).
• Business buys into it - spend the money and a year later had not yet achieved the end-result they were promised.

Problem:

• Vendors focus on delivering an IT solution (generate the revenue and move on to the next project) instead of solving the business problem

Recommended Approach:

• As part of every engagement - both the SI and ISVs need to insist on conducting a Business workshop (prior to starting the IT implementation).
  
• Provide real-practical advices - example: for a customer master the vendor typically looks for decision from the business to provide them with direction on where to add the customer - Lead Management, Opportunity Management or Order Management. As the vendors have done multiple implementations - shouldn't they know the best practices in the vertical and recommend the approach?
• SI typically have separate organizations that deal with business transformations and IT (CRM/ERP )implementation teams. Shouldn't every engagement have folks from both the practices at the customer site during the initial stages? Agreed the engagement cost will be a bit higher for the customer - but the value received will be substantial greater than the up-front cost. I for one - would be willing to pay. My problem was that no one approached me with such a proposal. However, I was lucky - my CIO recommended (and funded) that I have a full-time architect(s) from an SI on my team.
  

Thanks to SOA - I am starting to see changes in the SI engagement models. They seem to these days more focus on Architecture & Approach first - before bringing in their implementers. However, I am yet to see this transition happening in the ISV community.

The above example is based on my own experience and the case study is available here. As the case study indicates - I had to solve the same problem twice. First implement and learn from my mistakes and then repeat it again later. If we had real advice - we would have got it right the first time.

- Yogish

Vendors need to incorporate SOA infrastructure in legay applications

The majority of the IT budget (over 80%) is typically committed to supporting the existing infrastructure and applications. Even though adopting SOA brings substantial value over the long term, the short-term impact actually increases the support cost in two ways.

First, IT organizations will need to procure additions infrastructure components such as the Enterprise Service Bus, Registry/Repository, SOA Manager, SOA Governance tools, etc. Products like these not only requires upfront initial investment, it also adds one more layer of abstraction (hop) in the existing environment impacting the end-to-end performance.

Second, the support organization shall need to increase headcount and hardware infrastructure to support this next generation of infrastructure.

Even though most of the existing packaged applications are re-architecting their solution to run on the SOA platform, we are still years aways from wide deployment of these next generation applications.

It for this reason, it may make sense for the packaged application vendors to actually focus on retrofitting their previous versions of applications with the SOA infrastructure such as replace proprietary work flow by BPEL or XPDL, service enable (better) some of the business processes/services. It should be done in such a manner that the developers could still use the existing (proprietary) tools, keep the current functionality as is, limit functionality changes and roll this out as a patch release for the existing ERP, CRM applications.

This approach shall accelerate the adoption of SOA within and enterprise. In addition, enterprises shall be willing to pay incremental support to get this capability, a win-win for both the vendors and their customers.