advising on IT-business alignment
IT-business alignment about us blog our services articles & reports resources your profile exposure
blog
blog
Friday, August 29, 2008

Links for 2008-08-28 [del.icio.us]

Labels:

Thursday, August 28, 2008

Links for 2008-08-27 [del.icio.us]

Labels:

Wednesday, August 27, 2008

Cisco strengthens collaboration portfolio

Cisco today announced its acquisition (which is expected to close by the end of October) of email and calendaring startup, PostPath, for the princely sum of approximately $215 million. The PostPath offering is Linux-based, and has been designed to drop into a Microsoft network as an alternative to Exchange, with the company claiming to offer an easier migration path from Exchange 5.5 to PostPath than from Exchange 5.5 to Exchange 2007.

This acquisition is a logical step for Cisco, which acquired conferencing vendor WebEx in May 2007, followed by policy management vendor Securent in November. Cisco wants to be a major competitor in the collaboration software market, leveraging its communications background to move up the business software stack. With the exception of its small business email offering WebEx Mail, email and personal calendaring has been a noticeable weak spot in the Cisco portfolio, and by building the PostPath technology into the SaaS-delivered WebEx Connect product (which is gradually becoming the platform for all things collaboration at Cisco), the acquisition means it can offer an alternative to customers, and further fleshes out the Cisco collaboration stack.


The previously stagnant email market has seen a flush of activity recently, with hosted email services such as Google's Gmail introducing increasingly viable alternatives to the costs of maintaining an in-house Exchange environment. While it is unlikely that players such as Google and Cisco will making a major dent Microsoft's Exchange market share in the short term, the competition can only be healthy, and at least prompt Microsoft to address the challenges posed.


I have yet to speak to Cisco directly about the acquisition, so I remain quite speculative about how significant a role the company sees this technology playing in the overall collaboration portfolio. $215 million is a considerable purchase price, although it pales into insignificance next to the $3.2 billion the company paid for WebEx last year. Whether the value of the PostPath technology will justify that investment however, remains to be seen. Integration is a key factor in the WebEx Connect strategy, so it will be interesting to see how effectively Cisco can leverage the PostPath features across the breadth of the collaboration portfolio, rather than simply adding a check in the "email and calendaring" box. For organisations considering hosted collaboration offerings such as WebEx Connect, this acquisition could make Cisco a more interesting proposition, especially if Cisco can leverage the Exchange migration strategy touted by PostPath in combination with both PostPath's and WebEx's Outlook integration.

Labels: , , , ,

Links for 2008-08-26 [del.icio.us]

Labels:

Monday, August 11, 2008

The dilemma of "good enough" in software quality

I recently finished some research on the cost and quality benefits of upfront, automated code and design review (i.e. prior to and during the development and build process) through static analysis. One of my conclusions was that the case for "good enough" is no longer good enough in delivering software. But some might argue that this viewpoint is promoting the notion of static analysis as a means of perfecting something - "gilding the lily" - rather than an essential tool for knowing whether something is "good enough".

Not so. In many fields, it is widely accepted that it is not necessary to apply a rigorous quality or testing schedule without first understanding what is at stake, what the risks might be in the event of failure and the severity of those risk. And from there deducing the level of, and appropriateness of, testing techniques, processes and tools to ensure that what is delivered is fit for purpose or "good enough".

In software delivery I would argue that too often the desire to deliver something quickly - especially to meet a deadline, however ambitious or unrealistic - overrides the key question of (fully determining) whether what is being delivered is actually "good enough".

The attitude of 'good enough' has been hijacked as an excuse for "sloppy" attitudes and processes and a "lets suck it and see" mentality. Surely such an attitude cannot continue to exist in delivering software that is increasingly underpinning business critical applications?

It is, you could say, a problem of managing expectations. A one star hotel probably offers adequate and "good enough" services for those on a budget. But this would not be sufficient for five-star luxury seekers. The key, though, is that customers of each know what they are getting for their money and whether it is fit for their purpose. There is a quantifiable means of grading what is delivered and matching that to what is expected.

Software technology advances allow varying levels of sophistication and capabilities and enable much more to be achieved. Software is increasingly becoming deep rooted in every aspect of our modern lives. New business models are being founded on applications and systems developed with many of these new technologies and approaches. If organisations start to restructure their working practices around applications and systems which rely on the new generation of communication and collaboration technologies and approaches, then failure due to poor code or application quality becomes even less acceptable.

The inclusion of rich media and visuals; the push for greater collaboration through the Internet; and unified communications for richer interactive social or work activities, means that any failure in such services would not only have the potential of creating higher levels of frustration - it would reduce productivity more sharply. On top of this, company brands become more easily exposed to damage.

Increasingly when people buy or use software they expect, if not 5-star performance, then performance and quality that is at least "good enough".

How many companies can rigorously look at their testing programs and say that is what they are delivering?

If you set out to deliver something that is important then applying the sloppy, suck-it-and-see "good enough" mentality just doesn't stand up.

What I find incredible after all this time - given the weight of evidence and eminent studies on the cost savings and the growing complexity and importance of software in our modern lives - is that the "sloppy" mentality and attitude still holds such sway in software delivery processes.

Many organisations don't spend nearly enough effort on improving the quality of the software they produce. More often than not they pay lip service to the concept whilst secretly holding the belief that it is a waste of resources (time, staff and money). As I stated at the start, the reality couldn't be further from the truth. In a future blog and report I will examine and discuss the evidence in more detail.

Clearly there is more to this debate: especially as we place a greater reliance on software and grapple with the growing pressure to release new features and functions more quickly both to differentiate in the market and to gauge users' reactions and acceptance.

Is it better to just get something out there that is of reasonable quality and worry about more deep-rooted bugs later, since it is a well known fact that software is never flawless?

This certainly is the option taken by many in the business of delivering software who have met with varying degrees of success and, if you are on the receiving end, - frustration, disappointment and loss.

In the end it boils down to one's interpretation of "good enough" and the answer to the intriguing questions: who and what should dictate what constitutes "good enough" software quality and how do you go about governing it?

If you are looking to answer these questions you will need to adopt a combination of strategies:

- You will need the support of good processes. Static analysis is certainly one way of improving the processes and being efficient with it. It is a tried and tested means for progressing software quality, predictability and lowering software costs. However, it is not the only tool for software quality. It is part of an arsenal of tools and processes needed for a wider and more lasting, cost effective approach to delivering quality software.

- You will need a clear vision, and an understanding of the goals (business and technical) to establish whether something is actually "good enough".


- You will need to put in place a connected tools and communication framework to underpin and support your governance process.

Labels: , , , ,

Saturday, August 02, 2008

Links for 2008-07-31 [del.icio.us]

  • Johannes Ernst - NetMesh: On OpenID's Relying Party Adoption "Problem"
    Johannes Ernst discusses the disparity between the number of OpenID identity providers and associated identities (lots) and relying parties (few) and whether the ratio is likely to change over time, with thoughts on differing objectives and requirements
  • More tech details emerge on Microsoft’s ‘Midori’
    Mary Jo Foley over at All about Microsoft comments on an SD Times article on Eric Rudder's distributed operating system project, Midori. Microsoft may claim it's a research project but the callibre of the individuals involves would suggest otherwise

Labels:


Burn this feed
Burn this feed!

Creative Commons License
This work is licensed under a Creative Commons License.

Blog home

Previous posts

Normal service will be resumed shortly
Links for 2009-07-02 [del.icio.us]
Seven elements of Cloud value: public vs private
The seven elements of Cloud computing's value
Links for 2009-06-09 [del.icio.us]
Links for 2009-06-02 [del.icio.us]
Links for 2009-05-27 [del.icio.us]
Links for 2009-05-20 [del.icio.us]
Micro Focus gobbles Borland, Compuware assets
Links for 2009-05-05 [del.icio.us]

Blog archive

March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
July 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009
February 2009
March 2009
April 2009
May 2009
June 2009
July 2009

Blogroll

Andrew McAfee
Andy Updegrove
Bob Sutor
Dare Obasanjo
Dave Orchard
Digital Identity
Don Box
Fred Chong's WebBlog
Inside Architecture
Irving Wladawsky-Berger
James Governor
Jon Udell
Kim Cameron
Nicholas Carr
Planet Identity
Radovan Janecek
Sandy Kemsley
Service Architecture - SOA
Todd Biske: Outside the Box

Powered by Blogger

Weblog Commenting and Trackback by HaloScan.com

Enter your email address to subscribe to updates:

Delivered by FeedBurner