One evening in 1972 I was hanging out in the computer science department at UC Berkeley with a couple of equally socially backward friends waiting for our batch programs to run, and to kill some time we dropped in on a nearby physics lab that was analyzing photographs of particle tracks from one of the various accelerators that littered the Lawrence Radiation Laboratory. Analyzing these tracks was real scut work – the overworked grad student had to measure angles between tracks, length of tracks, and apply a number of calculations to them to determine if they were of interest. To our surprise, this lab had something we had never seen before – a computer-assisted screening device that scanned the photos and in a matter of seconds determined it had any formations that were of interest. It had a big light table, a fancy scanner, whirring arms and levers and gears, and off in the corner, the computer, “a PDP from Digital Equipment.” It was a 19” rack mount box with an impressive array of lights and switches on the front. As a programmer of the immense 1 MFLOP CDC 6400 in the Rad Lab computer center, I was properly dismissive…
This was a snapshot of the dawn of the personal computer era, almost a decade before IBM Introduced the PC and blew it wide open. The PDP (Programmable Data Processor) systems from MIT Professor Ken Olsen were the beginning of the fundamental change in the relationship between man and computer, putting a person in the computing loop instead of keeping them standing outside the temple.
Throughout 2010, I talked with a number of business process executives that are members of Forrester’s Business Process Leadership Board(BP FLB). These leaders all drive large BPM initiatives in the US and Europe, focused on continuous improvement and business transformation. I usually begin those conversations with a question: what’s your biggest problem with business process management (BPM) in your organization? Invariably I get a list of the big issues keeping BPM from progressing within the organization, and interestingly, the list of challenges remains the same across industry sectors and geographic regions:
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:
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.
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.
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.
Mobile authentication is nothing new. SiteMinder, a prominent web access management tool, has been able to handle mobile browsers and sessions for at least 7-8 years. Some users complained of WAP and its limitations, but most could access information and log in to websites with minimal issues.
WAP is gone and it is now replaced by a multitude of devices: tablets, PDAs, smartphones, etc. With the proliferation of Splinternet, we are witnessing not only a boom of content, but also the need to limit access to sensitive applications and data not only from the device but also on the device. Authentication, authorization, and data protection challenges multiply as companies embrace the post-PC tablets, etc.
What do we see people asking about? From the enterprise security perspective, the biggest challenges seems to be protecting the data on the device, performing a remote wipe on a lost or stolen piece of equipment, and making sure corporate information is separated clearly from any private data. Writing mobile applications or designing mobile-capable and still rich, interactive web pages is no easy task either. Companies also wonder about how to deliver and (de)provision applications quickly and securely.
What do we see companies do? Sandboxing corporate data and mandating the use of remotely wipeable devices is the first step. Storing certificates and using transaction signature mobile authenticators to defend against stolen or compromised text messages with one-time passwords is a logical follow-on.
[For earlier posts in this series, click here, here, and here.]
Imagine yourself back in childhood, sitting in the back seat of the family station wagon, en route to one of those long, high-stress family vacations that Americans have honed to perfection. Mom and Dad are arguing over what went wrong so far on the trip, and of course, how they could have avoided these mishaps. Why didn't we ask for directions at the last gas station, instead of letting Dad navigate by dead reckoning? Should someone have called ahead to ensure that there wasn't a problem with the hotel reservations? Who was supposed to remember to pack the camera? Was it reasonable to expect a travel rate of 500 miles a day? Quickly, your vision of vacation as a straight line into the heart of fun evaporates. Replacing it is a circuitous flowchart, each serpentine twist representing a different set of decision points, estimates, and possible outcomes. Who knows what might happen next? The wheels will fall off on a desert highway, and someone will have forgotten to renew the AAA membership?
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.
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.
Over the last few weeks, I have had a variety of conversations with clients that have centered around the scope for the term BPM. I think we all agree that BPM is not purely a technology – but how far does it go.
BPM – The Discipline
Forrester sees BPM as a broad framework of methods, approaches, techniques and technologies that support organizational change, value optimization and ongoing performance improvement. While some see BPM as a narrow technical approach, Forrester regards BPM as including a wide range of improvement methods such as Lean and Six Sigma, along with customer-centric (outside-in) engagement approaches and organizational change management – each one of these levers ties back to a flexible and adaptable enterprise architecture that implements an evolving business strategy. Such an all-encompassing approach can help focus on strategic priorities, as well as opportunities to both differentiate the value proposition, and sharpen the competitive edge.
While some would argue that Lean and Six Sigma are separate – that they are “in the business” – our research data suggests that the most successful BPM initiatives are run by the business, for the business and are of the business (to paraphrase Lincoln). Something like just 20% of BPM process improvement initiatives are run out of IT. Indeed, I would go a little further than that – BPM initiatives run out of IT are just not sustainable in the long term. If you are charged with maintaining a BPM program from within IT (perhaps running a BPM CoE), then one of your primary tasks is to a) identify and b) work with any Lean/Six Sigma programs that are out there.
WaterWare will add more software development and consulting services to Xerox which is always a good thing but more importantly, WaterWare has the Aquifer EHR electronic records system that helps convert paper records to electronic data. Added to Xerox's broad document services and global reach the combination gives Xerox strong capability in electronic health records capture and management. Health Care Reform = as we know- is pushing providers to meet “meaningful use” guidleines which boil down to turning massive quantities of unstructured content into structured data -allowing better monitoting of patient outcomes, better access to health data for consumers, and lower administrative costs. Could there be a stronger core competency for this company – and this combination. I also like WaterWare as a launching point for broader Dynamic Case Management solutions they can extend Xerox capability, using DocuShare foundation BPM and ECM components in verticals like pharmacy and order automation. Combining WaterWare with DocuShare makes sense to boost professional services and system integration, but also to provide some luster to a strong product that has been a bit buried in the larger Xerox. So, a nice pick up.
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
Reason behind my POV
Social CRM is giving customers control
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
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.
I’ve been researching why IT roles fail (or at least struggle mightily and often futily). The roles that come up most often are the ones that are not directly building or maintaining systems. These include architecture, planning, vendor management, relationship management, PMO, and security. As I’ve collected this information, there are themes emerging to explain why they fail. These include:
Wrong skills.An architect was told to define the standards fordata tools but lacked the skills to convince others they should care.
Inadequate capacity. Relationship managersat a midsized firmwere sold as strategic partners to business leaders but were also required to run large apps groups that had recently suffered layoffs.They just didn’t have time for the strategic bit.
Lack of support.The leader of vendor management was supposed to provide advice and oversight on which vendors were selected, butthe CIO did little to rein in other managers who previously had bought what they wanted from who they wanted.