Email overload is a hot topic. Replace “email” in the title of this post with “message” and the point becomes more obvious.
Summary: Social displaces some interactions that are inefficient over email, but overall introduces more messages for workers to sift through. That’s not necessarily a bad thing. In fact, many organizations invest in enterprise social for the additional collaborative interaction (i.e., messaging) it facilitates.
First, let’s look at how social displaces some interactions that are inefficient over email. In contrast to a private model -- which relies on addressing specific individuals and restricting who can see messages -- a public model allows everyone to more easily:
Find someone who can help. Social platforms elevate experts based on their rich profiles, contributions to the community, and recognition by others. Addressing a larger group also improves the chances the right person will see your message. This avoids what IBM calls the squirrel hunt when you start pinging people to ask “Can you help me with this or direct me to someone who can?"
Surface and participate in relevant discussions. We’ve all been annoyed by massive reply-all email chains. Rather than depend on being forwarded or copied at some point in an important email chain and be unnecessarily looped in on others, social tools allow us to choose to participate in relevant discussions. By electing to get notifications or watching the activity in a particular channel or group we stay "in the know” and can jump in or stay out.
Over the past few months, SAP Services has embarked on a major software-enabled services transformation of its offerings and operating models. The strategic intent is to increasingly rely on IP-based solutions (including SAP’s Rapid Deployment Solutions portfolio and assemble-to-order methodology) to deliver outcomes faster, with lower risks for clients and, eventually, support value-based pricing. Next on SAP Services’ transformation road map? I believe that the organization needs to quickly change the perception of the rest of the SAP ecosystem, which still views SAP Services as a competitor.
SAP Services’ business model used to merely rely on staffing “rock star” consultants on client projects in order to facilitate the implementation of complex solutions. The new strategy aims at positioning the 15,000 service professionals on SAP’s newer solutions (e.g., cloud, mobile, HANA . . .) in order to ensure that early projects generate the promised outcomes. In order to achieve this goal, the delivery teams need to be much more focused on collaborating internally (with the R&D team, for instance) as well as externally (with clients). SAP Services will also need to increasingly work collaboratively with its partners in order to ensure the success of the overall SAP-as-a-Platform strategy.
My colleagues at Forrester and I have been puzzling over the discrepancy between the wealth of attractive new mobile, cloud, and smart computing technologies in the market, and the relatively weak record of actual growth in tech spending that our tech market forecasting numbers show. Certainly, the recessions in Europe and weak economies in the US, Japan, China, India, Brazil and other emerging markets explain part of the weakness in tech buying. In addition, cloud computing’s impact on the timing of tech spending (reducing initial upfront capital purchases of owned hardware and software while increasing future subscription payments for use of these resources) means that spending that in the past would have occurred in current years has now been pushed into the future. Lastly, as a recent Economist article pointed out, business investment in general has been low compared to GDP and to cash distributed to shareholders this decade, as CEOs with stock option compensation have focused on meeting quarterly earnings-per-share targets instead of investing for the longer term (see Buttonwood, “The Profits Prophet,” The Economist, October 5, 2013). Still, even taking these factors into account, tech investment has been growing more slowly relative to economic activity than in past cycles of tech innovation and growth.
Communication is an essential part of the CISO's role, but too often we get it horribly wrong. That was the message laid out by communications expert David Porter at the RSA Conference in Europe recently.
We know that a large part of the CISO’s role is to influence, cajole and encourage our business leaders to make the right choices, enabling our firms to manage risk and move forward safely. Creating compelling communications is a differentiator, but too few CISOs excel in this area and this is holding back their credibility, their career and the risk posture of their employers.
David Porter proposed spending a great deal more time than most of us would be used to, refining the introduction to any piece of communication, and actively crafting it to flow from ‘Situation’ (“Once upon a time there was a beautiful princess..”) to ‘Complication’ (“..who was imprisoned in a tall tower by her wicked step-mother”). That sounds pretty standard, but it was interesting how David then analysed different RSAC submissions and showed how even the professionally written ones deviated from this model, and how much clearer they were once the rule had been applied.
This simple setup opens up the readers/listener's mind and plants questions that seek to understand how the story can be resolved, and stories are powerful communication tools.
The independent ISV market for cloud automation software got smaller today with CSC’s announcement that it will acquire ServiceMesh. I’ve been predicting a take-out of ServiceMesh with my inquiry customers for months, but this was faster than I expected. In short, CSC has picked up one of the few independent hybrid/multi-cloud management vendors. The buy makes sense for several reasons:
CSC needs a unified service catalog, orchestration, and governance platform to pull together its successful and growing cloud business and enable faster enterprise cloud migrations to its multiple cloud offerings (public, virtual private, private). The enterprise evolution to cloud is step-wise – some apps, some infrastructure, and some business units – and buyers need a partner to help decide which makes the most sense to migrate first, and how. CSC can combine its strong managed services capabilities and IT management tools expertise with the application lifecycle (DevOps) focus of ServiceMesh to reach a powerful cloud buyer: the app owner and developer. Apps are where the cloud action is.
CSC wants to maintain some degree of cloud neutrality, and ServiceMesh has built its reputation as a cloud-neutral governance and orchestration platform. ServiceMesh focuses first on applications and services, and leaves infrastructure management to the cloud providers. CSC gains a neutral multi-cloud (read hybrid) orchestration suite and ServiceMesh gets the ability to scale on the back of CSC’s global services footprint. I’ve been waiting for some new marquee customers for the ServiceMesh Agility platform and hope the partnership will bear fruit quickly.
As outlined in Technology Management In The Age Of The Customer, the age of the customer will fundamentally change how app-dev groups operate and interact with business leaders. This post is intended to open a discussion around the likely changes that the age of the customer will bring in the next few to several years — a reasonable planning window. I’ve seen a fair amount of change in this industry. As background, my tenure in the IT industry dates back to 1982, when at the tender age of 25, I left the Cambridge Institue for Computer Programming with a full head of hair and a fire in my belly to do great (programming) things. My first job as a batch programmer for the Massachusetts Department of Public Health lasted long enough to land my next job at Boston University, where I wrote batch and online Natural/Adabas code for a few years. In 1985, I joined Cullinet Software in Westwood, Mass. to develop commercial ERP applications in ADSO/IDMS (before the “ERP” acronym even existed). Online, fully integrated manufacturing, HR, and financial apps based on a network DBMS — it was cutting-edge technology at the time, as were the IBM PCs that began gracing our desktops circa 1987. Ironically, today my iPhone has more power than these early XT machines.
The hype surrounding threat intelligence has continued to build since I wrote the blog "My Threat Intel Can Beat Up Your Threat Intel” in mid-2012. S&R pros are responding to both the hope and promise of threat intelligence. According to our Forrsights survey data, 75% of security decision-makers report that establishing or improving threat intelligence capabilities is a top priority for their organization.
One of the most significant challenges in leveraging threat intelligence is operationalizing it. Today, there are two broad categories of organizations that leverage threat intelligence. I’ll use an analogy to describe them. The US television show “Sons of Anarchy” follows the lives of an outlaw motorcycle club. The Sons of Anarchy refer to themselves as “1%ers”: They have the power, resources, and means to accomplish anything they desire. This is in contrast with the 99% who are merely motorcycle enthusiasts without these capabilities. Some of these early adopters include financial services, technology, and manufacturing companies.
This got me thinking: Should efficient code management be the primary rationale when developing for the mobile Web or mobile apps?
IMHO, no. Judging from my conversations with vendors, agencies, and end users, manageable code bases are a solid goal when developing mobile strategy for digital customer experiences, but by no means the top priority (AKA “strategy first, execution second”). On the flip side, customer experience, customer intelligence, and digital marketing professionals are unlikely to put code considerations up front — or anywhere in the top 10, for that matter — and thus AD&D needs a voice when mobile strategy is discussed (AKA “iterative strategy should be based on execution feedback loops”).
I spoke with the “two birds with one stone” exec after the presentation and he clarified: If the use cases for the adaptive mobile site and a mobile app are largely the same, then it makes sense to leverage the hybrid app code base as your mobile website. OK, that makes sense now: The content and audience will be the same, and therefore repurposing the code base is a worthy effort.
My takeaway: A great deal of confusion persists around mobile — even when experts present to informed audiences. Forrester has been thinking about this question re: mobile development at length to help reduce the confusion:
We regularly get the question: should we build our web authentication and single sign-on solution?
Here's why you should not do it: OWASP 2013 lists "Broken Authentication and Session Management" as the No.2 item to pay attention to when you design your web site. OWASP.org says:
"Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities."
Implementing your own session and key management, validation, update, periodic rollover, etc. mechanisms in a scalable and fault tolerant way is extremely difficult. We regularly get inquiries from clients who want to replace their own in-house built web single sign-on framework -- mostly because they have been hacked or it's too expensive to operate and update.
This is why we see open source and commercial Web Access Management packages and solutions critically important to protect your web assets. Since they are mostly mature technologies, they protect against not just authentication and session management problems but often against cross site scripting and other older threats as well. If you use a newer product or a pure federation product, make sure that the vendor or supplier can help you answer your questions based on the the OWASP list.
I hear people talking about Agile 2.0 a lot. But when I look at what’s happening in the application development and delivery space, I see that many organizations are just now starting to experience Agile’s true benefits, and they’re not yet leveraging those benefits completely or consistently. So let’s stop talking about Agile 2.0 for a moment and instead digest and operationalize what’ve learned so far. There’s plenty to improve upon without getting into inventing new practices and acronyms to add to the Agile transformation backlog!
What I see is that app-dev leaders want to understand how they can optimize existing use of AD&D Agile practices like Scrum, XP, Kanban, improve the practices around the more advanced ones like TDD, continuous testing, CI and CD and leverage all with what they’ve learned over the years (including waterfall). Scaling the whole thing up in their organization in order to have a bigger and more consistent impact on the business is what their next key goal is. We fielded the 2013 version of our Global Agile Software Application Development Online Survey to find out how. I present and analyze this data in my latest report. The survey addressed common questions that clients ask me frequently get in inquiries and advisory, such as:
How can we test in a fast-paced environment while maintaining or improving quality?
How can we improve our Agile sourcing patterns to work effectively with partners?