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

You see it everywhere. Right from Microsoft's billion dollar products to simple .NET applications. Features that nobody wants to use, but everybody is made to pay for.  The over-engineering malady stems from wrong assumptions, philosophies and attitudes.

More is always better: More is not always better. Packing in features that nobody wants increases the chances of bugs in the features that people really want, makes them pay more for these buggy features and slows down time to market. The marketing folks who are reading this would probably feel that without some over-engineering they cannot sell the product. Agreed! More could possibly be better for the company making the product, but almost always bad for the end customer. 

We need to plan for the future: Let's face it. Most of the time you cannot predict future requirements. Requirements change and that is the fact. The way around that is not to predict and wire in your 'bets' into your requirements but to make the right decisions in the design. However, watch out for the flexibility mania in design (see below).

Product marketing over zealousness: Rand Eckfeld's IEEE paper brings out the importance of using Agile principles in strategic planning. "Projects must be coupled with a complimentary approach to strategy to in order to achieve the overall business goals. If agile development is to continue growing in the business community, complimentary strategic planning capabilities must be developed that share the same agile philosophies. " Product marketing would do well to apply Agile principles during customer interactions to stabilize and prioritize requirements better. Often product marketing has only a strategic feel of what the customer wants and distills this feel into a 'creative' product requirements specification setting off over-engineering. Steve Garnet explores the idea of Agile in business more fully.

Flexibility mania: Joshua at Dr.Dobbs defines code level over-engineering as "When you make your code more flexible or sophisticated than it needs to be, you over-engineer it."  

 

Gotchas Products Project Management 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

The McKinsey report on Web 2.0 and the relative lack of corporate interest in mashups made me dig a little deeper. I pulled out some data from the programmable web and did a run of MsExcel and this is what the top ten mashup API categories look like.

Here are some quick thoughts:
All the categories are consumer internet based.

Mapping and search predominate thanks to Google and Yahoo

The enterprise potential of mashups is largely untapped at least as far as these stats go.

Consumer Internet programming Technology Web2.0