The Seven Qualities Of Wildly Desirable Software

Mike Gualtieri

Cosmopolitan magazine certainly doesn't publish articles such as "Seven Hairstyles That Will Make Your Man Yawn." Wildly desirable is more like it. And so too, is it with great software. If you want your applications to be successful, you better make them wildly desirable.

My latest published research has identified seven key qualities that all applications must exhibit to be wildly desirable, with our choices based on research and inquiries on software design and architecture; assessment advisories with clients; and interviews with leading experts, including both practitioners and academics.

Forrester defines the seven qualities of software as:

The common requirements that all software applications must satisfy to be successful: user experience, availability, performance, scalability, adaptability, security, and economy.

Seven Qualities Of Wildly Desirable Apps

All seven qualities are important, but if you get the user experience (UX) wrong, nothing else matters.

The UX is the part of your application that your employees and/or customers see and use daily. You can do an exceptional job on project management, requirements gathering, data management, testing, and coding, but if the user experience is poor, your results still be mediocre — or even a complete failure.

Read more

Release Management And The "First Rule Of Holes"

Jeffrey Hammond

 

Ever hear about the "First Rule of Holes"? It's pretty simple — if you find yourself in a hole with a shovel, the first thing to do is.... stop digging!

That's kind of what it's like in app dev when it comes to release management: We've dug ourselves a pretty deep hole, and it's impacting our overall ability to ship software on time. We recently ran a survey of app dev professionals that confirms what we hear in our client inquiries: Most development leaders are frustrated with slow software delivery and their release management process (see Figure). While Agile speeds software design and development, it doesn't do much to speed up release and deployment — creating a flash point where frequent releases collide with slower release practices.

But some organizations have stopped digging themselves in deeper. They are working with their peers in operations to streamline release management and cutting steps into the side wall of their hole so that they can climb out, step by step. Here are five steps that they are taking:

  1. Investing in improving their pre-build processes. Many problems that occur during a release cycle have their root cause in inadequate pre-build tasks and activities.
  2. Expanding release management throughput. Projects that have large code bases or extensive testing cycles are using parallelism and intelligent testing processes to speed up the early stages of the release cycle.
  3. Optimizing their release pipeline. After taking care of the early stages of the release pipeline, advanced teams are implementing virtualization, parallel testing, and developer self service to further compress their release cycles.
Read more

I Don't Want DevOps. I Want NoOps.

Mike Gualtieri

DevOps is a term used to describe better communication and collaboration between application development professionals and infrastructure operations professionals. "Dev"+"Ops"="DevOps." The goal of DevOps to make the process of deploying applications faster and smoother. DevOps is a loosely defined set of emerging practices to get developers and operations pros to work together. Developers and operations professionals are often at odds. Developers want to release software more frequently; operations professionals want to protect the stability of the infrastructure. I applaud the goal of DevOps to improve the process of deploying application releases.

"No"+"Ops"= "NoOps"

The last thing many application developers want to do is have a sit-down with the ops guys. Besides which, they don't understand. Sure, the ops guys efforts are critical to our applications because they have to run on something. But, developers should look to spend more of their time getting closer to the business, not getting closer to the hardware. I fully acknowledge that there is a need for quicker and less-rickety deployment processes. But, I think DevOps is a step backward. Instead I propose NoOps. The goal of NoOps is also to improve the process of deploying applications. But, NoOps means that application developers will never have to speak with an operations professional again. NoOps will achieve this nirvana, by using cloud infrastructure-as-a-service and platform-as-a-service to get the resources they need when they need them. Of course, this is not just about getting virtual machine instances. It is also about release management. Ops can run this public, private, or hybrid infrastructure and give developers the tools they need to responsibly deploy applications faster.

Customer Service Myths, Half-Truths, and Total Nonsense....Continued

Kate Leggett

I got a lot of feedback from my last blog post, and I’d like to share my thoughts on each of these statements about customer service. I am sure my point of view is contentious, so please keep comments coming. It will force me to rethink my stance. I’ll cover each of my categories in a separate blog post.

Social Customer Service Myths

 

Myth

My POV

Reason behind my POV

Social CRM is giving customers control

 

Nonsense

Paul Greenberg defines social CRM as the The "company's programmatic response to the customer's control of the conversation." Its about the company taking hold of the reins of the conversation, not the other way round.

Have a look at what Paul Greenberg says here about this topic:  

Twitter works for customer service

Half-Truth

It sometimes does if the answer can be communicated in 140 characters. It shows that you, as a company are listening and acting on comments.

However, instead of engaging in customer service over Twitter, it is often more effective to take the conversation offline to a more suitable communication channel based on the issue at hand and the customer’s channel preference.

Read more

Explained: Java Is A Dead-End For Enterprise Application Development

Mike Gualtieri

Whoa. My post Java Is A Dead-End For Enterprise App Development received record-breaking readership and passionate comments. Thank you for reading, and thank you for your comments. Clearly it hit a nerve. Many of the comments legitimately called for an expansion of my arguments. Fair enough. I have done that in a 50 slide presentation that I delivered as a teleconference on January 24, 2011. Forrester is making this presentation available to download, free to anyone who registers at the site. Registration is free, so please feel free to register and download the presentation. I welcome your comments on the presentation here, at the original post, or on Twitter.

Click here for free registration and to download the Is Java A Dead-End For Enterprise App Development slides.

SAP 2010 - Predictions Review Of A Turnaround Year

Holger Kisker

SAP Has Managed A Turnaround After Léo Apotheker’s Departure

In February 2010, after Léo Apotheker resigned as CEO of SAP, I wrote a blog post with 10 predictions for the company for the remaining year. Although the new leadership mentioned again and again that this step would not have any influence on the company’s strategy, it was clear that further changes would follow, as it doesn’t make any sense to simply replace the CEO and leave everything else as is when problems were obviously growing bigger for the company.

I predicted that the SAP leadership change was just the starting point, the visible tip of an iceberg, with further changes to come. Today, one year later, I want to review these predictions and shed some light on 2010, which has become the “Turnaround Year For SAP.”

The 10 SAP Predictions For 2010 And Their Results (7 proved true / 3 proved wrong)

1. More SAP Board Changes Will Come — TRUE

Read more

Customer service myths, half-truths and nonsense

Kate Leggett

It is often said that managing a call center is more of an art than a science. Some customer service managers use standard operational metrics to manage their business to – like average hold times (AHT), first contact closure rate (FCR) agent, agent productivity numbers, escalation rates, etc. Others apply established customer service best practices to their organizations without understanding the intent behind these best practices. Yet other companies adopt the current trends without an analysis of their strategic importance.

Here is my list of “half truths and total nonsense” about management philosophies and technologies in customer service. Which ones resonate with you? Which ones do you believe are not myths and work for you?

Kate’s List of Common Services and Support Myths

  • Social customer service myths
    • Social CRM is giving customers control
    • Twitter works for customer service
    • I don’t need to interface my social processes with my traditional customer service processes
    • If I have a forum, I don’t need a knowledgebase
  •  Multichannel customer service myths
    • Established best practice apply to my call center
    • I am special - Established best practices do not apply to my call center
    • Front-line support agents don’t know anything
    • When you measure operational activities, you measure business outcomes
    • Support can act independently of brand –Support can have a different brand identity than the rest of the company
    • Email doesn’t work as a support medium
    • Chat won’t work for tech support
    • I dont need proactive chat
Read more

The Fallacy Of Architecting Behavioral Change With Social Technologies

Randy Heffner

 

Social networking is hot, and it’s smart to think about how your organization might use it to generate benefit equal to the market hype. As you develop your social technology strategy, it’s particularly important to steer clear of a fallacy of thought that often creeps into technology strategies for enterprise communication and collaboration.

Oftentimes, an enterprise social strategy, like enterprise collaboration strategies before them, will have among its goals a phrase suggesting that the technology should “change the way people communicate.” Superficially, this phrase may accurately describe part of the effect, but at a more fundamental level, it violates a very important change management principle. To make my point, I’ll back up and start with a little history.

I used to communicate via paper memos and phone calls, but it was cumbersome and time-consuming. Email has come to replace much of that. So, the “way I communicate” has changed, right? On the face of it, yes, but, looking more closely, not really, at least not at first. Compared to my “before email” days, I still communicate the same types of things with the same kinds of people — only email made these communications easier (for the most part). I started using email because (1) it could improve the existing way I communicated and (2) it fit my work and life context — it was just a new program to use on my handy desktop PC. Once email became part of my context, I realized that I could use it for communications that were too costly before. At this point, it did, to a degree, change the way I communicate.

Read more

When ROLAP Is Not A ROLAP

Boris Evelson

I get many inquiries on the differences and pros and cons of MOLAP versus ROLAP architectures for analytics and BI. In the old days, the differences between MOLAP, DOLAP, HOLAP, and ROLAP were pretty clear. Today, given the modern scalability requirements, DOLAP has all but disappeared, and the lines between MOLAP, ROLAP, and HOLAP are getting murkier and murkier. Here are some of the reasons:

  • Some RDBMSes (Oracle, DB2, Microsoft) offer built-in OLAP engines, often eliminating a need to have a separate OLAP engine in BI tools.
  • Some of the DW-optimized DBMSes like Teradata, SybaseIQ, and Netezza partially eliminate the need for an OLAP engine with aggregate indexes, columnar architecture, or brute force table scans.
  • MOLAP engines like Microsoft SSAS and Oracle Essbase can do drill-throughs to detailed transactions.
  • Semantic layers like SAP BusinessObjects Universe have some OLAP-like functionality.
Read more

Forrester's 5 Key Capabilities For Customer Service

Kate Leggett

Businesses, in 2011, are refocusing on strategies that differentiate them from their competitors. One way to do this is by focusing on customer service. We see that organizations are ramping up their multichannel customer service initiatives. In fact, 90% of customer service decision-makers told Forrester last year that a good service experience is critical to their company’s success, and 63% think the importance of the customer service experience has risen. However, customer expectations are getting higher. Customers are increasingly online, want self-service options, and demand responses in real time, often through their mobile devices. Moreover, social media, such as Twitter and Facebook, has grown to be an important new channel for interacting with customers and engaging in innovative ways.

To meet these challenges, organizations continue their search for solutions to address their most pressing customer interaction management problems. Leaders of customer service and product support organizations tell us that they want to strengthen five key capabilities:

  • Delivering the same customer service across communication channels. It is critical to standardize the resolution process and customer service experience across communication channels (email, phone, web self-service, chat, etc.)
  • Empowering agents and customers with knowledge management (KM) tools. Advanced knowledge management and search tools are a critical necessity for delivering contextual, personalized self-service and agent/customer experiences.
  • Supporting agile customer service with a strong foundation of business process management. Organizations are extending BPM to customer service to standardize service delivery, minimize agent training times, ensure regulatory and company policy compliance, and control costs.
Read more