It was revealed yesterday that iPhones/iPads (with iOS 4.0 or later) have been logging the location information of the device and storing that in a hidden file on the phone or the iPad.
This discovery, presented by researchers Alasdair Allan and Pete Warden, at the O’Reilly Where 2.0 conference this week, has sent shock waves through the high tech community. “What? This file contains my whereabouts for the past year? WTF?” was most people’s first reaction when the news broke.
Many iPhone/iPad apps have access to the geolocation of the device, but most only access it at a given point of time and do not attempt to log or create a history file of this information. The discovery that such logs exist begs the question why Apple was logging this data and whether it has any intention of utilizing the information.
I can imagine a number of reasons why Apple would want to collect this data and how they might use it. Device tracking, for instance, is a popular parental control feature that users want. Think your teenager lied to you about his/her whereabouts yesterday? No problem, just log into MobileMe and verify the location tracking information. Similarly, a credit-protection app can be instructed to report the phone’s general location at the time of a suspicious credit card transaction— if the card is used in England and the credit card owner’s phone is in Alabama, hmm… something could be amiss here.
Greetings — thanks for taking the time to read my inaugural blog! Let me introduce myself by way of continuing a discussion that I started at Practicing EA and CIO.com on innovation and technology that I think strikes at the heart of our challenges as enterprise architects. It also provides a good context for my future research, which I discuss at the end.
Closing The Innovation Gap
In part 1 of this post, I claim that a gap opened while we were fighting the overly complex, expensive current state and trying to help our business partners innovate with new technology.
The gap – We cannot deliver new technology and innovation quickly or cheaply enough.
Shadow IT Is The Symptom, Not The Cause
The Symptom – We often blame Shadow IT and manual workarounds for increases in complexity, reduction in quality of service, and obscuring true technology costs. These are symptoms of the problem, not the problem itself.
The Cause – Business users know more about what they need and when they need it and are the most motivated to solve their problems now, not once the budget cycle gets around to funding a project. Central IT, where most EAs practice, is a knowledge store for designing enterprise-scale systems but is constrained in its ability to deliver.
Recent outages from Amazon and Google have got me thinking about resiliency in the cloud. When you use a cloud service, whether you are consuming an application (backup, CRM, email, etc), or just using raw compute or storage, how is that data being protected? A lot of companies assume that the provider is doing regular backups, storing data in geographically redundant locations or even have a hot site somewhere with a copy of your data. Here's a hint: ASSUME NOTHING. Your cloud provider isn't in charge of your disaster recovery plan, YOU ARE!
Yes, several cloud providers are offering a fair amount of resiliency built in, but not all of them, so it's important to ask. Even within a single provider, there are different policies depending on the service, for example, Amazon Web Services, which has different policies for EC2 (users are responsible for their own failover between zones) and S3 (data is automatically replicated between zones in the same geo). Here is a short list of questions I would ask your provider about their resiliency:
Can I audit your BC/DR plans?
Can I review your BC/DR planning documents?
Geographically, where are your recovery centers located?
In the event of a failure at one site, what happens to my data?
Can you guarantee that my data will not be moved outside of my country/region in the event of a disaster?
What kinds of service-levels can you guarantee during a disaster?
What are my expected/guaranteed recovery time objective (RTO) and recovery point objective (RPO)?
The lines are blurring between software and services — with the rise of cloud computing, that trend has accelerated faster than ever. But customers aren’t just looking at cloud business models, such as software-as-a-service (SaaS), when they want more flexibility in the way they license and use software. While in 2008 upfront perpetual software licenses (capex) made up more than 80% of a company’s software license spending, this percentage will drop to about 70% in 2011. The other 30% will consist of different, more flexible licensing models, including financing, subscription services, dynamic pricing, risk sharing, or used license models.
Forrester is currently digging deeper into the different software licensing models, their current status in the market, as well as their benefits and challenges. We kindly ask companies that are selling software and/or software related services to participate in our ~20-minute Online Forrester Research Software Licensing Survey, letting us know about current and future licensing strategies. Of course, all answers are optional and will be kept strictly confidential. We will only use anonymous, aggregated data in our upcoming research report, and interested participants can get a consolidated upfront summary of the survey results if they chose to enter an optional email address in the survey.
Forrester receives a significant number of inquiries from clients requesting Forrester guidance on Information Security Metrics. Chief Information Security Officers (CISOs) need new types of metrics to address economic, legal, regulatory, human resource, communication as well as traditional IT information security concerns. Security metrics must evolve to show the information security effort provides quality, efficiency, and a correlation to cost reduction and profit improvement. CISO’s need new methods for demonstrating the value they and their programs create. Over the course of the next several months I will be working with our clients to provide additional guidance and insight into this important topic. Look for additional research from Forrester in a new information security metrics research paper series. As these papers develop I will comment on their development as well as important issues that surface as a result.
Social technology is coming into every organization whether IT wants it or not. The adoption of social technologies to support business and customer needs has been fastest outside of IT — often with IT playing catch-up and struggling to provide value. CIOs are at a crossroads where they can either choose to lead IT toward social business maturity or sit back and watch as the rest of the organization pushes ahead, leaving IT in social business obscurity. The choice is easy, but the execution is difficult. A new report — Social Business Strategy: An IT Execution Plan — suggests CIOs should assess the organization’s current social maturity and implement a plan that positions IT to successfully support a social business strategy.
Organizations are broadly categorized as social laggards, internally mature, externally mature or enterprise mature. The approach recommended for CIOs differs based on the maturity level. For example, CIOs in organizations with strong internal maturity should focus on developing a partnership with marketing in order to extend the use of social strategy out to customers and business partners.
While very few organizations are already at the enterprise maturity level, CIOs in these organizations can take an active role in developing social business strategy by supporting the creation of a social business council and dedicating staff to support social strategy.
Every year, people talk about the future of IT, which is shorthand for, "Some big changes may be in the works." In the last year, we've had to revise that sentence to read, "Some big changes are definitely in the works." Agile practices will be a critical tool for making this transition successfully, but not because of velocity. At least, that won't be the primary virtue of Agile that helps with the transition.
One of the Founding Fathers of Agile, Jim Highsmith, recently commented on his blog about an MIT study that surveyed one face of this mountain of change:
The implications of these changes in emphasis could be significant in terms of mindset and capabilities in and out of IT departments. From a focus on standardization, optimization, and cost control, the focus shifts to innovative uses of emerging technologies such as social media, cloud computing, and mobile devices; speed to market; flexibility to follow changing opportunities, and building new products and services.
Russian IT decision-makers are optimistic about their prospects for the next 12 months, according to Forrester’s Global Budgets And Priorities Tracker Survey, Q4 2010 – and, surprisingly, much more so than those in other countries -- 67% reported that their prospects are good versus only 52% in the US and 35% in the UK. On my recent trip to Moscow to deliver the keynote speech at Cloud Russia 2012, I looked for that optimism, and the root sources of it. There are certain obvious sources. The price of oil is high, and Russia is an oil exporter. The 2014 Winter Olympics are bringing significant investment to the region. But most importantly the political dialogue is focused on innovation and technology. That, in Russia, counts for a lot.
Given my own research agenda, I investigated the interest in public sector technology adoption and “smart city” initiatives. The answers were mixed. As elsewhere vendors are pushing solutions to improve transportation, energy efficiency and municipal administration. But many of those technology vendors did not share the optimism of the IT decision-makers for their own prospects in Russia. They did not see Russian cities as highly motivated, or incented, to get smart.
Product strategists at Mars, Incorporated are experimenting with mass customized offerings quite a bit. In addition to their build-to-order customized M&Ms offering, their subsidiary Wrigley has just rolled out MyExtra gum, which prints personalized wrappers on Extra gum packs.
Product strategists at Wrigley declined Forrester’s recent request for a research interview, but judging from the myextragum website and their press release, the offering is a really interesting example of a creatively mass customized product strategy. Why? Product strategists at Wrigley have:
Redefined the product using customization. Myextragum isn’t just gum with a customized wrapper. Instead, it’s a greeting card (Mother’s day, birthday, other holiday) or a business card (to be given to patrons) plus gum. Wrigley is moving into a non-adjacent, previously orthogonal product market in one fell swoop. That’s aggressive and creative.
Justified the higher price point. At $4.99 – though the price reduces with bulk orders – the product is pretty expensive for a pack of gum. But, again, it’s not a pack of gum – it’s a greeting card or business card that also has gum inside. This pricing makes sense when you think of the price of Hallmark cards or custom business cards.
We've been talking about the next stage of application life-cycle management (ALM) for several years now. As my colleague Dave West argued, the vision of ALM 2.0 is clear, compelling, and comprehensible. While ALM tools might have a ways to go to fulfill this vision, they have made significant strides in one particular area: integration among tools, whether or not they come from the same vendor. The momentum for ALM integration isn't unique, propelled by the same forces that make integration the killer app in other segments of the software market (CRM, content management, collaboration, etc. etc.). Tools provide potentially valuable capabilities, but these capabilities don't map exactly to the way people work.
The Work Defines The Tool, Not The Other Way Around
The primacy of work over tools explains why ALM 1.0 died quickly from its own success. Having convinced app dev teams of the value of point solutions for task management, planning testing, requirements, release management, and other functions, the obvious question on practically every customer's mind was, "What other tools might help us?" We should be careful about how we understand that question, which is not synonymous with, "What other activities might we make easier or more successful?" The tools are, more often than not, part of the same activity. Planning, for example, should identify risks that shape what requirements you write and what tests you build.