Does The Good Old 80/20 Rule Work For Estimating BI Costs?

Boris Evelson

I get tons of questions about "how much it costs to develop an analytical application." Alas, as most of us unfortunately know, the only real answer to that question is “it depends.” It depends on the scope, requirements, technology used, corporate culture and at least a few dozen of more dimensions. However, at the risk of a huge oversimplification, in many cases we can often apply the good old 80/20 rule as follows:

Components

  • ~20% for software, hardware, and other data center and communications infrastructure
  • ~80% for full time employees, outside services (analysis, design, coding, testing, integration, implementation, etc), new processes, new initiatives (governance, change management, training)

Initial softare costs (~80%) vs. Ongoing software license maintenance costs (~20% / year)

Direct (~20%) vs. Indirect costs (~80%). Here are some examples:

Direct ~20%

  • Data integration for reporting and analysis
  • Data cleansing processes for reporting and analysis
  • Reporting and analytical data bases such as Data Warehouses, Data Marts
  • Reporting / querying / dashboards
  • OLAP (Online Analytical Processing)
  • Analytical MDM (Master Data Management)
  • Analytical metadata management
  • Data mining, predictive analytics
  • BI specific  SOA (Services Oriented Architecture) or other types of EAI (Enterprise Application Integration)
Read more

The App Internet: What It Means For Development Professionals

Jeffrey Hammond

 

My colleague John McCarthy just published an excellent report sizing the "app Internet," a phenomenon Forrester defines as "specialized local apps running in conjunction with cloud-based services" across smartphones, tablets, and other devices. Forrester estimates that the revenue from paid applications on smartphones and tablets was $2.2 billion worldwide for 2010 with a CAGR of 82% through 2015. We're witnessing the rebirth of the rich client in real time, on the mobile device instead of the laptop or desktop. Developing applications using native application technologies like Objective-C, Java, or Silverlight is clearly how the majority of developers are reaching these mobile platforms today (see figure).

Read more

Social Breathes New Life Into Knowledge Management For Customer Service

Kate Leggett

You have to admit that knowledge management (KM) is hard — it’s hard to explain, hard to implement, hard to do right. It’s not just technology. It is a combination of organizational realignment, process change, and technology combined in the right recipe that is needed to make KM successful. And when it is successful, it delivers real results — reduced handle times, increased agent productivity and first closure rates, better agent consistency, increased customer satisfaction. Check out the case studies on any of the KM vendors' sites to see real statistics. Yet despite these success stories, and despite there being commercially viable KM solutions on the market for over 10 years, I am unsure whether KM really ever crossed the chasm.  

Why is it then that we are seeing renewed interest in KM in 2011? I believe it’s attributed to listening (and acting on) the voice of agents and customers, coupled with loosening the strings of tightly controlled content that has breathed new life into KM. Most common trends include:

  • Using more flexible authoring workflows. In the past, knowledge was authored by editors who were not on the frontlines of customer service, who foreshadowed questions that they thought customers would ask, and who used language that was not consistent with customer-speak. Authored content would go through a review cycle, finally being published days after it was initially authored. Today, many companies are implementing “just-in-time” authoring where agents fielding questions from customers, not backroom editors, create content that is immediately available in draft form to other agents. Content is then evolved based on usage, and most frequently, used content is published to a customer site, making knowledge leaner and more relevant to real-life situations.
Read more

Want Better Quality? Fire Your QA Team.

Mike Gualtieri

Seriously. I recently spoke with a client who swears that software quality improved once they got rid of the QA team. Instead of making QA responsible for quality, they put the responsibility squarely on the backs of the developers producing the software. This seems to go against conventional wisdom about quality software and developers: Don't trust developers. Or, borrowing from Ronald Reagan, trust but verify.

This client is no slouch, either. The applications provide real-time market data for financial markets, and the client does more than 40 software releases per year. If the market data produced by an application were unavailable or inaccurate, then the financial market it serves would crumble. Availability and accuracy of information are absolute. This app can't go down, and it can't be wrong.

Why Does This Work?

The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn't work, the developers can't say that "QA didn't catch the problem." There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.

As British author Samuel Johnson famously put it, "The prospect of being hanged focuses the mind wonderfully."

Can This Work For You?

Read more

The Nastiest Performance Bottleneck Is Often The Database

Mike Gualtieri

Some of the most joyful technical challenges I experienced as a developer were solving application performance problems. Isn't it fun. You are Sherlock Holmes - examining the architecture, diving into the code for clues, and scouring through logs files to find the bottlenecks that are responsible for snail's pace. However, this job is a lot harder than Sherlock Holmes or CSI. It is more like Dr. Gregory House, because you are racing against the clock. For every minute of sluggish performance, you could be losing eyeballs and therefore revenue. Worst case: the patient, i.e., your website, dies.

Performance Problems Are Usually Elevated Because Of A Crisis

Your business just launched a Super Bowl commercial that confidently directed people to your website - #fail. More likely, a new release of software performs like a dog (with apologies to Greyhounds) because of lame coding and nonexistent performance testing.

 You Need A Clever Solution, Fast

Read more

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.