I missed a breakfast meeting today. The first time that has happened. Breakfasts usually start at 8 am and this one got pushed by one half hour. I timed it the usual way but hit the 8 am rush which I usually avoid. Realizing that I will be late, I called and left a voice message. The message stayed where I left it and my date waited a few minutes and left. I sent out an apology and rescheduled the meeting. If there was a way to get voice messages in email we might have still had an abbreviated meeting.

Can't wait for unified communications to become a day to day reality!  

Life Technology

 

Frank Scavo has a nice post on the downsides of vendor consolidation in the enterprise software space. His arguments are centered around vendor lock in and he writes:

• "Consolidate to a single vendor for worldwide financials, but standardize operational systems on another vendor's platform. Always leave the option open to replace one with the other.
• Consolidate to a single vendor for centralized CRM and order management, while allowing one or two different vendors to provide operational systems at the plant level, perhaps one for large plants and one for small plants.
• Revive a best of breed approach. Leave HR, asset management, and other non-core systems outside the scope of the primary vendor's implementation.
• Test vendors' touted SOA capabilities to build composite applications. If these capabilities really are what vendors say they are, they ought to allow "seamless integration" with third party applications."

Very true.

What of software services ? Vendor consolidation is low hanging fruit for both vendor and client.
The classic approach is to get a offshoring biggie to come in and clean house. Lock in is not such a big issue. Offshoring and process efficiencies that come with consolidation are big wins. But there are things to watch out for. Here are a few:

    - Keep the larger sourcing picture in mind : There are things that the offshore model is simply not suited for. Niche skill areas, choppy demand that fluctuates very frequently and onshore staff augmentation are a few things that come to mind. It's better to consolidate such requirements and give it to one local vendor - rather than to an offshore player.
    - Understand where your star contractors figure :  Great performance, good cultural fit, strong skill sets, loyal to your organization BUT offshorable. Vendor consolidation might be a good time to really examine the type of work these loyal stars are doing. Do they understand your business? Do they really have strategic value? Have they ended up managing the business relationship? If the answer is yes, consider hiring them rather than firing and replacing with an offshore provider. But think twice if you want these stars to continue to be domestic contractors and expect them to work with new resources from the offshore provider. The inherent conflict of interest could jeopardize your budding offshore relationship.
     - Closely examine productivity claims: It's easy to show improvement when your nose is in the dirt. Consider today's economy. People seem to be thrilled just because we are improving. If you are at an 80 year bottom the only way is up! Productivity norms of the current team of contractors should be base lined and the offshore provider should go up against this baseline. Also consider the fact that offshore work hours are usually longer than those of your local contractors. Apart from improvement, benchmark the norms against best in class.
      -Sign short term contracts with rewards and penalites: Vendors might give you an overall better deal if sign up a long term, 5 year contract at the outset. Guess what? You'll get an even better deal if you sign up for a year and then renew. Throw in six monthly reward and penalties and the deal becomes even sweeter.

IT strategy Outsourcing Technology

Jeremiah pops the question "Will URL's go away?" and says the future is "content to be found and served through context". With search engines getting increasingly sophisticated, at least from a consumer perspective URL's are getting abstracted. You don't have to know the URL of a resource to get to it- as long as you have a decent idea of content and the context surrounding the content. However, in a Web 2.0 world URL's will continue to be the bedrock of how information is referenced and consumed by applications. Take REST for example. External interfaces of typically procedural applications that are current exposed as method calls would now become URL's. URL's might be getting hidden away from the end consumer of content, but will become increasingly relevant at the plumbing and the infrastructural layer.  Consumer Internet Technology

Amit Ranjan writes about the launch of IE 8 Beta. "Internet Explorer 8 beta launched today and its new features promise to take the browser to new standards of user friendliness and safety." Surely there is a web 2.0 flavour. Should you switch ? Read PC World's comparison of Safari, Firefox and IE. It calls IE 8 a "work in progress". Want a walkthrough before you install ? Check out this nice youtube video.

 

Consumer Internet Products Technology

Tom Foydel over at Sightlines writes about the next wave of technologies that will hit the SME sector. The regular suspects are all there : RFID, Open Source, SAAS, Clouds and stuff. There are a couple of surprises as well because you don't hear so much about these yet: Alternate energy, Cell Technology. Tom's list seems comprehensive but I'd like to know what you think? Are there any emerging technologies that are not in the list?Corporate IT Technology

Wiki defines Desktop Virtualization (DV) as "Desktop Virtualization involves separating the physical location where the PC desktop resides from where the user is accessing the PC." They go on to define the following flavours :

"Single Remote Desktop - in this model, a single desktop PC is accessed remotely across a network connection using remote PC access software, such as GoToMyPC, WebEx, PCAnywhere, Windows Remote Desktop, VNC and other similar methods.

Shared Desktops - in this model, a multi-user server PC environment like VDIworks Virtual Desktop Platform, Quest's Provision Networks, Citrix, Ericom Software, WebGlobix Software, and Terminal Services are used to host many users who all "share" a common PC desktop environment together on a server machine. In this case, it's generally possible to host up to a few hundred desktop sessions on powerful server hardware.

Virtual Machine Desktops - in this model, also referred to as Virtual Desktop Infrastructure, or VDI, virtual machine technology is used to host multiple instances of a standard, single-user desktop PC operating system (e.g., Windows XP) on a server machine. In this case, it's generally possibly to host a few dozen desktop sessions on powerful server hardware. VDI products are offered by Quest's Provision Networks, VDIworks, Citrix, VMware, WebGlobix and Ericom.

Physical PC Blade Desktops - in this model, individual "client blade" PCs are used to host multiple independent user sessions, each one running on its own physical PC blade. In this case, it's possible to host as many client PC blades as you have rack space, power and data center space to accommodate. There are several companies that provide this model such as HP and ClearCube Technology. "

Bill Snyder makes a case for an overstated business case largely on account of unclear ROI drivers. Jonathan at Information week takes a contrary view, arguing that DV drives security besides just dollar savings. He brings out the following benefits. My thoughts are in italics:
- Stricter licensing. Sure benefit here. I am sure most managements would not like to be burdened by the consequences of employees installing "evaluation" versions and failing to remove them. I also believe there are other ways of controlling this centrally without going the DV route.
- Better manageability.
- Lower TCO on account of extended thin-client hardware life, fewer cycles spent on hardware-induced OS failure, and lightened deployment efforts. Extend client hardware life and lower OS failure costs ? Not sure if there is a real TCO case here. Clients are usually replaced not because the hardware has failed, but because the s/w has caught up and is more hungry. You would need to upgrade the server infrastructure if this happened in a DV environment and the exact cost -benefit comparision is not clear. But yes, if you are not running anything on the client, you would save dollars on upgrades. Hardware induced OS failures are not common enough IMO and with the typically good quality h/w found in most organizations, this is less of an issue. 
- Better business continuity. Maybe ? Depends on whether your continuity efforts are helped by letting users working offline rather than depend entirely on a centralized environment where they need to be online all the time to be productive. In countries where the physical infrastructure (roads, transportation etc) is strained there is a trend of letting employees work from home. In such cases, if you also had sub optimal telecom infrastructure, you might get better continuity by not centralizing. 

Guess the jury is still out on this one.
 

Technology

BPEL4People was recently announced as a step towards narrowing the gap between BPM (Business Process Management) and SOA. As always, we have a lineup of biggies endorsing the new spec. Read this IBM white paper to know more. The justification for the new spec is given as :

Human user interactions are currently not covered by the Web Services Business Process Execution Language (WS-BPEL), which is primarily designed to support automated business processes based on Web services. However the spectrum of activities that make up general purpose business processes is broader than this, because people often participate in the execution of business processes. To support a broad range of scenarios involving people within business processes, a BPEL extension is required. 

Makes sense and well intentioned, but begs the question if this is really the area where the focus should be. What is the point in adding a new layer of complexity when adoption is stifled with the complexity on existing layers ?  Just take a look at the number of specs in WS-* and you'll know what I mean. Time and money is better spent on rationalizing this spec spaghetti and thus promote mainstream adoption instead of adding to the mess.

Technology Web2.0

Nick Carr writes says "The management of atoms is becoming as important as the management of bits.." in his insightful (as always) article. The last few decades has seen work move to wherever it can be done most efficiently at the best possible price. As enabling technologies have evolved and outsourcing models have matured, we have seen software outsourcing progress from maintenance all the way to product development. If the management of atoms becomes as important as the management of bits, we will likely see outsourcing models evolve further in the infrastructure space. We could have a Google data centre in China, managed by technicians in Vietnam with the software written in the US and maintained in India!Outsourcing Strategy Technology

I recently attended the JAX India seminar which covered topics like SOA and enterprise architecture. The organizers have put up some presentations online. I particularly liked the presentations by Tobias Israel, Ramesh Loganathan and Thilo Frotscher. Thilo is a top quality web services trainer/ architect and I richly recommend him for any web services related corporate training requirements. You can contact him at contact@frotscher.com. Note : I have no business relationship or personal friendship with Thilo. Just loved his sessions !  

 

programming Technology Web2.0

Bruce Tate's book "From Java to Ruby" is one of the few books on programming languages written for the manager. It provides a strategic view of how to position Ruby within the enterprise and offers insights on helping Ruby "cross the chasm" and become a mainstream language.  

Top five messages:

Don't use a Bofors gun to kill an ant: I cannot  agree more. Plenty of people out there refuse to look beyond J2EE and .NET when it comes to web application development. Bruce argues " Don't use Java when all you want you application to do is to babysit a database". Use Java when you have complex, heavy duty entreprise computing problems to solve.


Ruby's biggest selling point is productivity: Ruby can be 5 to 10 times more productive than Java for certain types of applications.


There is more to productivity than meets the eye: Increased programmer productivity acts as a lever that brings gains in project management, faster time to market, lower usability risk (due to faster iterations) and lesser ramp up time.


Ruby is more than just a scripting language: Ruby even when combined with Rails might fall well short of a full fledged J2EE platform, but it much more than just a scripting language. Rails brings sufficient ammunition to solve enterprise integration tasks that are well out of scope of a 'scripting language'.


Politics is as important for selling as technology: Even when the 'hard numbers' business case is clearly favourable a new technology or language is likely to loose out politically. The key challenge that Ruby will need to overcome is political than technical. "Nobody got fired for buying IBM" and so the adage goes.






 

Book review Technology