A Web-services expert recommends various ways to evaluate and adopt technologies such as XML to optimize your application development strategy.
In the IT industry, a tire kicker is a potential customer who engages in lengthy interactions with a vendor firm but will never buy its products or services. I've known a few of these over the years myself. These clients were frustrating because they often had large IT budgets and real problems that required our expertise, but we could never get a purchase order out of them. A version of the tire-kicker approach, as it turns out, may be a smart way to begin with Web services.
Web services are being adopted in multiple ways. Some firms are beginning on the inside of their organizations, behind the firewall, where pilot projects can be conducted safely without worrying about immature Web services security standards and lack of commercial solutions. This approach is an example of the inside-out approach, where a firm begins internally behind the firewall, and uses Web services as an alternative platform to enterprise application integration. Web services have a compelling value proposition as an open XML-based integration middleware solution in contrast to traditional, proprietary, and expensive EAI solutions. This inside-out paradigm is valid, and can provide great business value by extending business processes outside the firewalls to facilitate collaboration with external trading partners.
A competing Web services adoption paradigm is the "outside-in" approach, where a firm begins at the edges of the enterprise with collaborative Web services in customer-facing or supplier-facing business processes such as procurement, collaborative product development, and demand forecasting. Outside-in advocates argue that the interactions with trading partners at the edges of the enterprise are ripe for Web services because of the nature of the business processes at the edges-"frequent coupling and decoupling, distributed business processes, and the incompatibility of systems between enterprises. Web services are a great platform for resolving these issues, and I agree with this assessment.
The inside-out versus outside-in debate is a common one with Web services these days. I often argue that some industries are more prone to collaboration than others, such as electronics, automotive, and even insurance. Some industries, however, are characterized by complex legacy IT infrastructures, and therefore internal integration provides a more immediate payback. We know that many firms are well along the adoption path with Web services for both internal and external consumption. I still contend that firms deploying external Web services probably experimented internally first, behind the firewall, before exposing services to the outside world. It still really doesn't matter. What matters is that firms are using Web services, in multiple scenarios, for both internal integration and for external collaboration solutions. More important, these firms are accumulating knowledge for the future phases of Web-services adoption--innovation and domination--where Web services are delivering real business value.
However, there are other ways to begin Web services activities in a corporation. Let's explore a few of these alternative Web services adoption pathways for a moment.
The "Play It Safe I Value My Job Approach," also known as Risk Minimization: This is one where a firm implements Web services, or any emerging technology for that matter, in such a way that corporate and financial and business risk is minimized. This adoption path clearly argues for the behind-the-firewall approach of integration, although as I point out above, collaborative Web services also can be deployed behind the firewall as well.
Building A Mobile Business MindsetAmong 688 respondents, 46% have deployed mobile apps, with an additional 24% planning to in the next year. Soon all apps will look like mobile apps – and it's past time for those with no plans to get cracking.
In this special, sponsored radio episode we’ll look at some terms around converged infrastructures and talk about how they’ve been applied in the past. Then we’ll turn to the present to see what’s changing.