| |
Thursday 8th May 2003
COMMENTARY - GROUND HOG DAY
| IT'S GROUND HOG DAY AGAIN
1. The Funding issue: So you go talk to IT and business management, and you have just about gotten through the first part of the pitch that says you can save vast amounts of money and create real application adaptability, and you find yourself outside the door and facing a career challenging moment. Of course many probably don't even bother to ask - they know the answer already.
2. The Confidence Issue: So you go talk with other project managers, and sell them on the idea that you can collaborate, share your services and reduce costs and time for the enterprise. But every project manager builds high walls around them - it's the only way they can survive. They lower the walls only when they see cast iron commitments and company policy going that way. So they look at the offered service and say, OK looks good; how will you ensure this is available EVERY time I need it? With what cast iron, guarantees? Like to help pal, but otherwise, no way Jose!
In our writing we have articulated repeatedly the reasons why Web Services are a compelling case. Business context and reuse, loose coupled, enforced separation of concerns, documented, low cost and more. But clearly these are not sufficient. So what do you do? The bottom line is that Web Services can't be treated casually, forget the skunkworks, they need to be delivered within a technical and life cycle management framework that is at least as good as other production platforms are today. Here are a
few tips on how to make Web Services happen:
1. MAKE A REAL BUSINESS CASE
Over the past couple of years many IT organizations have had a hard time. They have been starved of funding, headcount and required to more with less. It seems that business people and managements have become disillusioned with IT. Whilst they fully recognize the value IT brings to the business, they increasingly treat IT like any other business division or function. And here is the key - we in IT have become accustomed to getting investment simply because we have a neat piece of new technology or a new silver bullet. But for the rest of the enterprise new investment has always needed to be fully justified, examined every which way before the project proceeds, with reduced budgets and career threatening commitments.
The other thing to consider is that a limited first class production capability and management system for Web Services is not going to cost the enterprise as much as a new production facility or developing and launching a major new product or market. A Web Services platform can also be phased such that usage can be controlled and focused on Web Services with genuine ROI, and the case proven on a narrow path.
2. FIND THE SILVER BULLET
I often tell the story of a well known financial institution that asked themselves - "what gets reused most in our business?" The answer they came up with was calculations. Like most financial institutions they had a multiplicity of product based application silos which all replicated the core calculations that were common to all products. They established a common service that created a generalized implementation, and over the next n months, every time they opened up one of the silo applications, they called the common service and made the existing code redundant. As a result of quite modest investment, this enterprise was able to cut product introduction by many months, making a major contribution to overall business performance. The question for us all is - "where is our equivalent of calculations?"
3. USE AN EXTERNAL PLATFORM - PAY AS YOU GO
There are now numerous organizations that have established Web Services management platforms for outsourcing. Many of them promote these platforms as a simple way to avoid up front investment, and to allow progressive, low cost implementation on a high integrity platform. Find one that will provide real service level agreements.
You still need to implement the life cycle management system, but the up front, incremental cost barrier is made significantly lower.
4. FIND SERVICES THAT ARE NOT BUSINESS CRITICAL
Years ago I recall Warren McFarlan telling the story about the first business installation of the IBM 370. Hard to understand now, but back then being the first customer of a major new product line was undoubtedly a major risk. It was a Canadian insurance company who was prepared to take the plunge. As McFarlan tells the story, the CIO received much publicity in the popular press. However what the media didn't mention
was the nature of the risk that the company was running. The company in question used the mainframe for specific forms of insurance contract that were high value and low volume, and had assessed that their business could survive for more than 30 days with no service availability. So while the CIO was a hero in magazines such as Time and Newsweek for risk taking, he was applauded by his management for a very different achievement - for making an extraordinary low cost commercial agreement in return for providing a public reference on the new product, at minimal risk.
I am not suggesting that you go find services that are not needed for 30 days at a stretch, but I am suggesting that there are services that don't need mission critical production support environments. For example an easy reversion to the conventional delivery method might work. As a tactical approach to prove the case for services, this might require much reduced investment.
CBDI ROADMAP WORKSHOPS
CBDI has assisted a number of enterprises in various ways to develop their Web Services plans at both business and technical levels. We bring insight gained from working with a large number of enterprises. If you are planning and developing your capability for Web Services, a CBDI Workshop can provide independent review and innovative input that
ensures you are adopting best practice. More details at:
CBDI Services
| Abstract: Here we go again! Enterprises are discovering many of the core issues that inhibited use of software components apply equally to Web Services. Is this a reason for avoiding Web Services, or are there ways to over come them?
Once upon a time many people had a dream. They dreamt they could create software as components that would like other engineering disciplines, be reused in lots of different circumstances. The dreamers envisioned a world where components were traded as commodities in marketplaces that grew ever larger and more successful, as more software components were created that enabled developers to buy rather than build.
Of course with 20:20 hindsight we know that these dreamers did not live happily ever after. The vision of pervasive software components dissolved in tears as supplies of good business components never materialized and developers preferred to write their own software, thank you very much.
MOST ENTERPRISES ALSO FAILED WITH COMPONENTS
Many enterprises also pursued the goal of software reuse through components. However there are relatively few major organizations that have been highly successful with business level components. Here there is a direct parallel with the sad experience of the component marketplaces. The reality for most major enterprises is that business is not organized in a manner that easily permits enterprise wide IT initiatives. So the business case for components has to be made on project ROI, not on widespread reuse, even if it were feasible. Of course there are persistent folk that are persevering with components. They know that well designed components create better application structure that reduces project risk and increases application adaptability. But these are in the minority and while many may claim to implement components these are often physical packages and not well formed components with engineered independence.
THE SAME ISSUES APPLY TO WEB SERVICES!!!
Now while there is great interest in Web Services today, there is little evidence of widespread enterprise adoption. There are many reasons for this, including the dire economic situation. Perhaps business managers are disinclined to put their faith in bright new ideas from IT any more. But the core problem is that many of the issues that drove a stake through the heart of widespread CBD and software component markets, is also going to present a major inhibitor for potential Web Services users.
Your early experimentation with Web Services shows that functionality can be made available incredibly easily and quickly. Forget the vendor hype of virtual business, this approach is highly applicable to internal applications and can solve many cross enterprise integration issues simply and easily. The tools to enable creation and publishing are very productive and the standards based interoperability makes the functionality widely available with little effort. Yes there are interoperability issues between platforms, but these can be overcome reasonably easily even without the WS-I profiles. You create a few Web Services that expose existing functionality to make these widely available and the business case is obvious - Web Services can save serious money!
But the next step is that you need a solid platform, which is at least as stable and trustworthy as your current production platform. There's no point in making great services available if they are only available for 50% of the time, or they have unacceptable performance. Further other project teams are not going to rely on someone else's services unless they have some service guarantees. So the services platform needs to be a fully fledged production platform with full life cycle support including comprehensive documentation, publishing, configuration, versioning, discovery, monitoring, logging, diagnostics etc. And this costs time and money, and really should be a corporate, enterprise wide resource. |
| | Read Full Article / Link to referenced materials |
|
Home