Accenture Technology Labs Blog

The Power of The Shiny New Thing

Shin, David — Thu, 29 Jul 2010 21:25:00 GMT

It’s dangerous to state the obvious. When stating the obvious, you run the risk of looking like you don’t know that your point is obvious, when in fact, your whole point is that the obvious isn’t obvious to everyone. Obviously.

A couple of weeks ago, I spoke at a social media conference, focusing on ensuring that your social media activities lead to relevant and measurable outcomes. At the end of the presentation, I was asked for advice on how to start a successful social media campaign. My answer was in the form of a question, asking what the person wanted to accomplish. Were they looking at social media as a way to increase sales? Build brand image? Get ideas from their customers? What was the definition of “successful”?

I find myself asking this question a lot, in part because social media is still a “shiny new thing” for many business people. Human beings, like cats, are bedazzled by the “shiny new thing” (henceforth, the SNT), whether it’s a new phone, a new kitchen appliance, or a new algorithm. We are hypnotized by its brilliance, and we begin looking for ways to use the SNT whether it’s useful or not. Anyone who has bought an appliance like an ice cream maker knows this.

So, social media is a new SNT, and people are desperate to use it. They are probably right to do this. Despite its shininess, it is a very useful tool. However, it’s a tool that is most powerful when properly directed. Therefore, when people ask a general question about social media, I ask them to first articulate what they are hoping to accomplish. Is it a goal that is well served by social media? Sometimes it’s not. When people ask me whether or not they should tweet or blog, I ask them what they want to say, and how do they expect to benefit from their work. Often, the answer takes a while to come out. Such is the power of the SNT. As we do social media strategies for people, we begin by asking these questions. What are the success criteria overall? What is the business goal? How do people expect to measure the results? In other words, tell me what you want to accomplish, and I’ll tell you if and how social media can help you, along with guidance around the channels, content, and organizational structure.

Starting with a definition of your end goal might seem like obvious guidance, but it’s a point worth highlighting because the allure of the SNT is so strong. It can often get you using the right tool for the wrong reasons. Each campaign, and even each post, should be done with an outcome in mind. So, you might ask, what is the point of this post? Good question. I’ve briefly mentioned some of the things we’re doing with social media strategies for our clients, crafting strategies that target different business challenges across different social channels, taking into account governance, metrics, and a host of other concerns. At the risk of stating the obvious, my hope is that we can work with you to create such a strategy. But be forewarned, I’m likely to answer your questions with questions of my own.

Opportunity Eco-System

Shin, David — Sat, 26 Jun 2010 01:03:00 GMT

Good news from the infrastructure cloud, such as Amazon’s EC2 and S3 services. At the price of $100, you have a cluster with 1000 servers in your hand for an hour. Data center and server configuration? Done. Management and maintenance? Done.

So, the question is “what are you going to do with it?” Now, it’s time to sit back and think about what we couldn’t do before, and what we can do now with this elastic infrastructure cloud.

Many have already discussed applications with seasonal load. For example, you don’t need to target your web server farm’s size to peak load any longer. Rather, you can build an elastic web server farm that automatically scales its capacity following the traffic demand. Or, your company must generate a quarterly forecast that requires a business analytics application with computing power equivalent to a hundred servers. Because you only run it four times a year, three hours each, you couldn’t financially justify purchasing 100 servers for that purpose only. Now, with the cloud, twelve hours multiplied by 100 servers is only $120. (Yes, network bandwidth fee and so on will make it more than $120, but still much better than buying 100 servers.)

Anything else?

I want to introduce the Opportunity Eco-System. This is a place where the software provider and the user can meet safely. It is hosted in a public cloud. Before we get into details, let’s take a look at a typical setup scenario.

Scenario

Bob is a manager in the quant department of an investment firm. His job is to determine a target price of a mutual fund by running sophisticated pricing algorithms. Like yesterday, Bob received an email that advertises AccuPricer, a new pricing engine. Bob has three strategies: 1) investment is all about taking a risk for bigger return! Try’em out! 2) When it comes to IT, “don’t change until it breaks!” or 3) wait 6 months and see what the reaction from early adopters are. None of them are optimal strategies, though.

Opportunity Eco-system for users

Users can try out new software on pre-configured virtual machines. Yes, you have a practically unlimited resource pool; try multiple softwares from multiple vendors at the same time. Remember “at the same time”, not “one-by-one.” In this way, You can give a new offering a chance without interrupting your current workflow. At the first phase, you can consider the new offering’s workflow as a “what-if” scenario. The Opportunity Eco-system makes this flow seamless.

Now, you are running multiple options for one task in parallel to using the cloud. Therefore, you want a comparison metric for various reasons. First, Bob needs to choose one of many results from many engines, as his target price should be one number. Second, Bob may want to draw a conclusion from many results using a “voting scheme” or an “averaging scheme.” Even in this case, Bob may not want to give even weight to all sources until they obtain Bob’s confidence. Lastly, after Bob tries out the new engine several times he may want to filter it out if he is not satisfied with the engine. Otherwise, a year later he will be running more than 100 engines all at once, quickly burning out his IT budget. The Trial Eco-system provides an interface where you can setup your comparison metric objective (accuracy, time, cost, etc.,), and collect statistics for comparison. It is interesting that sometimes “accuracy” cannot be scored in real time. If a software engine is to predict a future value of one property, we can tell the real accuracy at the time when the future arrives. Trial Eco-system provides a future-feedback feature that collects the real value at future time and updates the credibility of the engine.

So, what should Bob pay for? Bob pays for the usage-based license for engines he chose. Trial Eco-system is responsible for monitoring usage, billing, accounting, as an uninterested third party. Note that Bob already purchased a site license for some pricers like SosoPricer, and it’s not reasonable to pay extra license fee for the SosoPricer Trial Eco-system edition. Trial Eco-system enables BYOL (Bring Your Own License) feature so that Bob doesn’t need to pay extra.

Trial Eco-system for software providers

Software providers are another crucial party of the Trial Eco-system. Unless the Trial Eco-system can invite most of the market leading providers into the system, the user’s choice will be limited and the whole system will collapse. The Trial Eco-system lowers a market entrance barrier for software providers. It provides a standard virtual machine image with security features to protect their proprietary software and accounting features for license fee charge. Moreover, it organizes a standard framework so that many of the comparable tools from vendors can fairly compete with each other.

Vision

With Trial Eco-system, from now on, Bob will get a promotional email like this:

“We are pleased to introduce AccuPricer, our new pricing engine. More than 100 customers already tried it out, and 80% of them experienced better results from AccuPricer (see chart 1). To compare the performance of AccuPricer to what you have now, click this link. By subscribing today, you will get AccuPricer $100 credit that is equivalent to a 30 day license.”

Bob clicked the link to allow Trial Eco-system include AccuPricer to his parallel pricing engine list. Still, he does exactly the same thing as he did before to run pricing calculation – he presses the “Price it” button. AccuPricer then runs in parallel with SosoPricer and 4 other engines in Bob’s list. At the end of the day, Trial Eco-system sends him a report that shows the statistics of all the engines in his list. The report shows that AccuPricer performs pretty well. After a month of consistent high performance, Bob and his team decide to make AccuPricer official and discontinue their SosoPricer subscription.

Amazon cloud security best practices

Liu, Huan — Wed, 16 Jun 2010 22:58:00 GMT

Many of our clients are interested in migrating to cloud, but all of them are concerned about security. I wrote before that a cloud is more secure than one's own data center. Following on that thread, today I will focus on a set of security best practices you can follow to enhance your cloud security even further. Since a lot of our clients are evaluating Amazon cloud as a potential choice, I will focus on the best practices in Amazon cloud, but the principles should apply to other clouds as well.

1. Check before connecting.

Since a cloud VM (virtual machine) is outside your firewall, you have no control on the path to reach it. For example, it is well known that one can hack DNS servers. Just a few months ago, china's largest search engine Baidu suffered a DNS attack. So it is likely that your VM could be hijacked too. One best practice is to always check your VM's signature before connecting. Amazon instances generate a random SSH server key on boot up. This SSH server key can be obtained by querying Amazon's (secure) API for the console output. This key from the console output should always be checked against the SSH key reported when you SSH into your VM. To ensure the best practice is always followed, for our clients, we wrote a wrapper around a SSH client, which automatically checks the key before connecting. You can quickly code up something like ours.

2. Encrypt as much as you can.

You should always use SSH or SSL to connect to your VM, which encrypts all traffic. In addition, you should encrypt your data to guard against hard disk theft or inappropriate hard disk disposition. On a Linux OS, this is easy to do because you just need to install an encrypted loopback file system. On Windows, there are a number of products you could use to encrypt.

3. Wipe when you quit.

As an added precaution, you should wipe out the encrypted loopback file when you shut down your instances. This will prevent the most determined hackers from trying to decrypt your bits, if they got a hold of your file, for example by stealing the hard disk. When you shut down your Linux instances by calling Amazon's API, the proper shutdown procedure is invoked. All you need to do is to hook into the shutdown script and wipe out the hard disk in the process. In our experiments, we find that there is enough time to wipe out about 7GB of data before your instance is just killed. That should be long enough for you to wipe out the most critical section so that no one can reconstruct your bits.

4. Stand all by yourself.

One key difference between cloud and your internal data center is that your VM may sit next to some strangers' VM on the same physical hardware. Even though hypervisor isolation has been robust so far, there is always the concern that a vulnerability could be discovered someday and your VM may be hacked by the neighboring VM. One solution is to launch a VM onto its own hardware all by itself. We analyzed Amazon's cloud hardware configuration recently, and concluded that there are two types of instances that occupy the whole physical hardware. Since Amazon does not have any capability to online migrate your VM to another hardware, you can be sure that your VM is standing all by itself. You will receive an email notification if Amazon needs to change the underlying hardware, which happened to us recently.

5. Open to only those you trust

Amazon offers a powerful software firewall, called Security Group. You can have any many Security Groups and as many rules per Security Group as you want. You should use Security Group to lock down access to your application to as narrow a list as possible. For example, if you enable SSH access, you should open port 22, but make sure you only open to the IP addresses from where you will access it. Never open it to the whole world (i.e., 0.0.0.0/0) unless your application is public facing.

Because the fine grain control a cloud offers you, if you follow the above best practices, you can be sure that your application is more secure if hosted in cloud than hosted in your own data center.

WebScalar -- A prebuilt fault-tolerant auto-scaling web server farm in the cloud

Liu, Huan — Fri, 04 Jun 2010 20:19:00 GMT

One of the success stories of cloud is around a startup company called Animoto. The company's website was hit hard when they became famous, but, by running on top of Amazon cloud, they handled the onslaught gracefully. As the traffic increased, they scaled their infrastructure from roughly 50 servers to a peak of 4000 servers. The story demonstrates the power of using cloud -- dynamically scaling based on usage. This is particularly important for web applications where the number of users fluctuates unpredictably, not only through the application life cycle, but also throughout the day.

In comparison, in a traditional infrastructure, you have to provision a fixed capacity because it takes too long to provision additional capacity. In a couple of client projects that I have seen, people grossly over-provision for what they need because it is better to be safe than sorry. As a result, they pay way more than what they should pay, sometimes orders of magnitude higher.

The order of magnitude in infrastructure cost savings alone should convince you that cloud is the right way to go. But, I have to break the bad news to you that you cannot simply drop your application in cloud and expect it to scale all by itself. Although there are many solutions out there now, it is difficult to determine which solution works the best for your application and which solution is the most robust. As a proof, I visited Animoto's website recently and I was surprised to find that their website is down (see below). Apparently, even the cloud poster child did not get it right completely, at least the failure handling part.

What solution out there should you choose if you decide to host your web application in the cloud? Obviously, you can build it on your own. I have talked about how to choose a load balancer in the cloud, but it is just a start. You still need to figure out how to add auto-scaling capabilities and fault-tolerant capabilities. Instead of designing a new solution from scratch, you can leverage an Accenture's pre-built solution.

I would like to introduce WebScalar -- a prebuilt platform developed by Accenture which can host any web applications. WebScalar is auto-scaling, which means that servers could be brought up/down depending on traffic demands. It is also fault-tolerant, any single point of failure is repaired automatically. For example, if the load balancer fails, an active standby load balancer immediately takes over. At the same, a new standby load balancer is spun up to protect against future failures. Lastly, WebScalar also has a set of load balancing modules that could be plugged in. Depending on your application profile, we can plug in the optimal load balancer for your need.

The following video is a capture of the monitoring front end which shows the status of the moving parts in the systems, including the load balancers and the web servers.

WebScalar is free of charge to our client teams, and it is typically used in a larger cloud application migration project. If you have an interest using this solution, you can reach out to your client director or to us directly.

Performance matters

Harvey, Brandon L. — Tue, 18 May 2010 19:39:00 GMT

Performance matters. For people who work closely with technology, this is something of a ground truth. Faster is better; it has always been thus.

But how much does performance matter? Can we quantify its value, so it can be weighed rationally against other attributes a system might have? Generally speaking, this is difficult, but in some ways it's getting surprisingly easy – particularly, in the context of the Web.

Here's how it goes: take a website with a high volume of traffic. Change some attribute of the website, in some small way, and expose a certain fraction of the audience to that alternate version. See what happens.

This is A/B testing. It's not a new idea, and major websites have used it for years to help with layout and design tuning. But recently, some companies have played with A/B testing in another way: to test user's reactions to different levels of performance. And the results, while not surprising, have been fascinating.

Both Google and Bing, for instance, ran studies where they deliberately returned search results more slowly, for a small subset of (unsuspecting) users. Over a series of weeks, they kept exposing the same users to a system that was slightly slower than the norm.

And as it turned out, the users of the slightly slower search engine . . . searched less. Some portion of searches that would otherwise have happened, just didn’t happen. Users got less utility out of the system.

And it only took a small slowdown to create this effect. As little as 100 ms of delay (a tenth of a second) had a measurable impact on users. This is subtle stuff. For groups exposed to greater delays, Google saw a greater reduction in search activity. Just a 2% overall slowdown induced a 2% drop in searches per user.

And if users' propensity to search is hurt by a slower system, their propensity to do other things – like, for example, pull out their wallet and buy something – is hurt just as much. Bing found that a 2 second delay in search results cut revenue per user by 4.3%. For the amount of traffic that sites like Bing and Google tend to see, that's a very large number.

Without question, then, this is an important result for the consumer-facing web. But what about the workplace? How does the responsiveness of a business system affect its usefulness? Unfortunately, I'm not aware of any similar studies in an enterprise context.

But I certainly think they should be attempted. Any enterprise has internal systems that are strategically important to its operation, as a whole, but are also user-driven. That is, they can't simply be mandated into their maximum utility; they naturally have more utility, the more that employees embrace them. Examples of these kinds of systems:

Time and activity reporting
Internal databases, wikis, or other knowledge repositories
Issue reporting and tracking (whether software or human 'issues')
Surveys or internal knowledge markets
Code repositories and build systems
Software-based security systems of all kinds

In each case, it's in the interest of the company that their workers use these systems early, often, enthusiastically, skillfully, and in great numbers. This is the only way to extract maximum utility from these systems. And if they fall short, it actually hurts the company more than it hurts the employee.

The A/B tests from Google, Bing, and others show that slow or unresponsive systems have a cost. There's no reason that business systems, too, shouldn't try to measure – and minimize –that cost.

Requirements Engineering Innovation Agenda

Shin, David — Mon, 10 May 2010 16:54:00 GMT

The first step that most software-development projects take is to develop and document the project’s requirements. The ability to do so well is crucial to the project’s success. The fact that poor requirements frequently lead to rework, cost overruns, and even project failure, has been pretty well documented. However, while a number of industrial-strength tools have been developed to help with requirements management – which kicks in after requirements have been developed, there is much less support for the process of developing high-quality requirements to manage. The technology that has been developed, in academia or industry, has gotten little uptake in real-world projects. This is particularly true for the declarative, textual requirements lists which are the most common form of requirements documentation in enterprise projects. Experts in requirements engineering, both within and outside Accenture have developed best practices for writing good requirements. However, in current practice, most of the activities in requirements development - specification, review, visualization, and analysis of requirements, are typically done manually.

At Accenture Technology Labs, we are working on a Requirements Engineering Innovation Agenda, which seeks to change this. We are developing a suite of intelligent tools that will support all aspects of requirements development including acquisition, specification, review, visualization, and seeding downstream processes. We are developing these tools in close cooperation with Accenture’s expert practitioners. Our tools seek to automate various tasks in requirements development in a way that operationalizes the best practices that they have developed through years of experience.

In the figure below, we show the 4 micro-phases that we divide the requirements development process into, along with the tools we have under development to support each micro phase.

As you can see, these tools are at various stages of maturity – ranging from deployed tools to early concepts. At the mature end of the spectrum is the Requirements Analysis Tool. This tool uses a combination of semantic and syntactic techniques to automate the review of textual requirements against best practices for requirements documentation and has been deployed at over 200 projects and has been shown to have significant cost savings at those projects. Some of the other tools are just out of the oven in initial pilots, and still others are in the initial design stages.

Stay tuned for more updates, ranging from case studies to deeper dives on specific tools.

(Note: Accenture employees can get more information of Requirements Analysis Tool and the other tools at the following link: https://acres.accenture.com. External folks can read some of our papers on the Requirements Analysis Tool here and here.)

Web + TV: Crossing the streams

Harvey, Brandon L. — Fri, 23 Apr 2010 23:05:00 GMT

I'm not obsessed with Web + TV, but here I am posting again about it. Mostly because I’m interested in where technology is going, and part of the question of where it’s going is a question of media. Whether the iPad succeeds as a technology platform, for example, is largely dependent on whether it succeeds as a media platform: a venue for books, for comic books, for cookbooks, for movies, for TV shows. Establishing a new technology platform, now, is largely a matter of establishing a new channel, with all that entails.

Now one claim that I made in a previous post was that

the video web and the written web are still basically two separate media, begetting totally different user experiences, different hardware setups, different patterns of consumption, even different rooms of the house. They’re hot and cool media, respectively, just like Marshall McLuhan said. And what it would take to unite them in some new kind of fusion medium – well, that we have not seen yet.

The distinction between lean-back experiences and lean-forward experiences is probably a cliche at this point, but it’s also an accurate reflection of a real chasm. In one kind of media world, you take in a story; in another, you reach out to type, click, scroll, parse. They are usually separate worlds.

One more bit of evidence for this chasm: "cut-scenes" in video games. Cut-scenes are those expensive-looking video segments that are often screened between game levels, to help establish the story or the mood. But it’s a strange idea, if you think about it: so much energy is devoted to “enhancing” a (highly interactive) game with elements that are so completely. . . non-interactive. It’s just a video. When the cut-scene begins, there’s nothing for game players to do but drop their game controllers slack in their laps and sit back to watch TV for a few minutes. Interaction ceases; perhaps somebody gets up to go to the bathroom. This is a 'game'?

Steven Spielberg, who I was surprised to learn is a serious player (and occasionally a creator) of video games, makes a similar point:

You know the thing that doesn't work for me in these games are the little movies where they attempt to tell a story in between the playable levels. That's where there hasn't been a synergy between storytelling and gaming.

However, I did recently encounter a Nielsen study on media consumption, which paints a slightly different picture. It’s helped me understand how this chasm – between storytelling and gaming, between the flow of video and the interactivity of the web – can sometimes be bridged. Because it turns out that people are, in fact, discovering their own new ways to interact and consume at the same time.

in the last quarter of 2009, simultaneous use of the Internet while watching TV reached three and a half hours a month, up 35% from the previous quarter. Nearly 60% of TV viewers now use the Internet once a month while also watching TV.

Now, is this just multi-tasking in the living room? At least partially, it is. People do unrelated activities in front of the television all the time. That’s not interesting.

What’s interesting is that it’s not all multitasking – and the Twitter traffic says so. Online chatter about American Idol, for example, is substantial, but what’s even bigger is chatter traffic about American Idol while American Idol is on. That is, people are turning to the web – Twitter, Facebook, chat rooms, discussion boards -- to talk about the media experience they’re having . . . even as they’re having it. They’re using the web as one big backchannel.

So despite what Spielberg and I both feel is a lack of “synergy” between lean-back and lean-forward experiences, this is one kind of real synergy. You lean back and enjoy the show – you lean forward give your two cents about Ellen DeGeneres’ new haircut. The video tells the story, while the layer of commentary – the social layer – reflects a shared experience of that story.

I’m certainly not the first one to have noticed this phenomenon. There’s already a new breed of mobile apps like tvChatter, expressly designed for purpose of commenting and dialoguing about live media, as it’s happening. And there’s research interest, too, in what this kind of live commentary tells us about the live event – and about the audience. How was a televised debate received, blow by blow? How does an audience connect with certain scenes, certain characters, certain themes?

Call it the Mystery Science Theater effect, in honor of the campy TV show where robot puppets, silhouetted against the screen of a bad movie, call out snarky comments. Just substitute tweets into the speech balloons.

Cloud Computing : Where is the rain?

Shin, David — Thu, 22 Apr 2010 08:42:00 GMT

Cloud computing professes many advantages: on-demand pricing, less IT overhead, lower cost through economies of scale, lower entry barrier into new territories and so forth. All these are definite nice-to-haves, but is this just a minor chapter in the IT saga or a proverbial paradigm shift? In other words, is this just a passing cloud or a rainmaker?

If I wind my mental clock forward 3-5 years, I see three radical changes that cloud computing could bring.

Prognosis 1: Cloud computing will lead to a dramatic increase in cross-company business processes that will dwarf today’s “business ecosystems”.

Prognosis 2: Cloud computing enables an “exoskeleton” model (as opposed to today’s “endoskeleton” model) for corporate computing. This will open up new white spaces for IT services in many large but fragmented industries such as construction, education, healthcare etc.

Prognosis 3: Cloud computing will give rise to what could be called business process “utilities” – i.e., companies that provide simple and common business processes (e.g., sales tax calculation and remission) but at such a massive scale that they’ll dwarf today’s SaaS companies.

There’s a lot of wealth to be created. But then there are also lots of technical problems to be solved. The first 3 parts of this series will examine each of the three prognoses above. The fourth will outline the set of technical problems that need to be solved in order for these prognoses to come true.

Prognosis 1: Cloud computing will lead to a dramatic increase in cross-company business processes that will dwarf today’s “business ecosystems”.

The moment a company’s IT systems migrate outside the firewall, they can much more easily communicate and exchange information with other IT systems from other companies to execute business processes that cross company boundaries.

To be sure, cross-company processes are not new. In the 80’s EDI was aimed at communication across companies to exchange information across a supply chain within different “business ecosystems” (most notably, within the automobile industry). The travel industry has integrated systems across airlines, car rental companies and hotels to create business ecosystems (e.g., the oneworld alliance, the Star alliance etc) to offer passengers a seamless travel experience across multiple airlines, hotels and rental car companies. However, today such processes are handcrafted and hardwired across systems from a small number of business partners or orchestrated by third party “clearing houses.”

Cloud computing in combination with integration standards like web services and REST has the potential to create cross-enterprise processes at an industrial scale: complex, yet flexible business processes that snake through multiple companies that are part of fluid and ever-changing business ecosystems. One may very well ask: “even if this is technologically possible, what is the business driver for it?”

Practically any human experience you can think of – whether it’s a vacation, a stint at the hospital, or just living your average humdrum day – involves products and services provided by multiple companies. Today, companies provide discrete products and services that we, as individuals, manage and orchestrate. The ability to flexibly weave together a business process with

services from multiple companies around an individual and his or her life seems like a strong driver in the business-to-consumer world.

Much as an individual’s life involves touch points with multiple products and services, almost every process in organizations also involve interactions with multiple business partners. Today, each business partner sells a discrete product or provides a discrete service and organizations manage and orchestrate these internally into business processes. Cloud computing makes it considerably easier for companies to configure business processes that involve internal components and many external components into complex yet fluid processes around their business needs. This seems like a strong driver in the business-to-business world.

To be continued.

View From Our First Year Analyst

Shin, David — Mon, 19 Apr 2010 22:44:00 GMT

Hi, I’m a first year analyst at Accenture Technology Labs (ATL) in Silicon Valley. Many people might be wondering what life is like as an analyst in ATL. What is the average week or day like? What about the average project? I can tell you right now that the only norm about what you’d be doing is that there is none. You have to expect the unexpected and your project work varies nearly every day.

For me, I am currently finishing up a project where I help a company develop a mobile device app. The client is across the country on the east coast, so I have the option of travelling every other week. This is nice, considering the commute to the client is five hours there and six hours back.

When I'm at home in California, I usually get up around 7:30 A.M., get ready, check the day's news headlines, have a quick breakfast, and then walk to work. I like to get there quick and hit the ground running. I don't work with anyone offshore, so I don't get many emails overnight. I am the only person on my project working at my home site, so all of my meetings are phone calls and on the web. I have three status meetings a week with either my client or my Accenture manager, and that is mostly it. The rest of my time is spent working on the project independently.

On my own, I could be doing one of many things: design work, presentations, spreadsheets, coding, testing, planning for the next release, etc. I try and keep my day varied, so I'll usually spend two to three hours on a specific task and then switch to another one, since there is always a variety of things to do. I guess that is one of the advantages of being on a small project. I get to see it [the project] from beginning to end and am involved in almost every part of it.

When I'm in Virginia, I usually fly out Sunday afternoon and return Thursday or Friday evening. On each flight, I can average three to four hours of work, usually coding or documentation. Weekdays at the client site always seem busier and more hectic than whenever I am at my home office, perhaps because I simply have more client meetings that take up my time. Because I'm working independently every other week, face time is a key factor while I am at the client, and everyone will tell you: building a strong professional relationship with the client really goes a long way.

Monday and Tuesday afternoons are usually booked with meetings regarding status, workplans, design, and defect handling. I usually get off around 6:00 or 6:30 in the evening. I'm not done working then, I just take a dinner break. Two or three nights of the week, I have some extra work to catch up on at the hotel after dinner. It's mostly coding or design work that I couldn't get done due to daytime meetings. At the end of the week, I fly back to California to enjoy a relaxing weekend at home.

That's it! I'm transitioning next week to another project, this one being internal. After six months at the client, all I can say is that it was an awesome experience. I learned a fantastic array of new skills and built a strong relationship with a great client. I can't wait to see what my next project has in store.

Bad Cloud!

Harvey, Brandon L. — Tue, 13 Apr 2010 18:47:00 GMT

It turns out that by far the biggest cloud computing systems in operation are . . . botnets! Beyond Google, Amazon, Microsoft, and Yahoo, the biggest cloud on the planet is controlled by the Conficker computer worm. But instead of living in a data center, this cloud is made up of ordinary end-user machines – maybe yours! Maybe mine.

Conficker controls 6.4 million computer systems in 230 countries, more than 18 million CPUs and 28 terabits per second of bandwidth, said Rodney Joffe, senior vice president and senior technologist at the infrastructure services firm Neustar.

[It] is controlled by a vast criminal enterprise that uses that botnet to send spam, hack computers, spread malware and steal personal information and money. . .

Like legitimate cloud vendors, Conficker is available for rent and is just about anywhere in the world a user would want their cloud to be based. Users can choose the amount of bandwidth they want, the kind of operating system they want to use and more. Customers have a variety of options for what services to put in the Conficker cloud, be it a denial-of-service attack, spam distribution or data exfiltration.

http://www.networkworld.com/community/node/58829

Botnet software resembles a virus, in the way it silently infiltrates a user’s machine through some software flaw, or some innocent action on the user’s part. But unlike a virus, which is usually simply destructive, botnets have a useful goal in mind – useful to someone else, that is.

I find botnets scary, but also fascinating. How did we get here? How did we get to the point where the French Navy had to order staff not to even open their own computers?

Not very surprisingly, some of the biggest, juiciest targets for botnets are large organizations with fleets of machines. These fleets can present a soft target for a number of reasons, but one of these has to do with organizational attitudes toward computers. I’m talking about the tendency to treat computers like hardware assets – physical things in space – when computers are really organisms in an ecosystem.

Companies know how to take care of machines, with regular (but hopefully minimal) maintenance. Machines operate in the physical world, subject to regular forces like friction and load. The same kind of care and feeding will work for typewriters, sedans, and even printers.

But software is a different kind of investment. It lives in a parallel universe, subject to frictions and loads that are ill-understood. Its environment is always changing – it’s an unstable ecosystem. And it’s an ecosystem that has predators.

Organizations are used to taking care of printers -- not prey.

New predators can emerge day to day; but many organizations with locked software images are on a 2-, 3-, perhaps 4-year "upgrade cycle". In the gap between 2 days and 2 years, the botnet thrives.

In a funny way, a software investment doesn’t just depreciate over time, like most assets. If you leave it alone for long enough, it can gain the potential for active destruction of value. Look again at that occasionally-handy Windows 2000 machine under Fred’s desk (which he leaves running 24x7, of course). As each day goes by, the odds improve, just a little bit, that this machine has sent spam; has stored illegal information; has helped crack a password; has leaked your own company’s information far and wide.

At what point is a machine’s ability to do useful work outweighed by its potential for doing anti-work?

(Looked at this way, even donations of old computer systems could have a negative value (to the world) that is greater than the positive value of the gift. If a company gives all of its Windows 2000 machines to a school in Peru, then the school might gain a new computer lab, but the Conficker cloud might have just gained a new node which will last for many years.)

So what's the solution?

Fundamentally, these kinds of botnets exist not because organizations (and users) can’t keep their systems up to date, but because end-user system software is simply designed wrong. Or rather, it was designed for a different environment. It was effective in its original environment -- but now it's prey.

Vendors can keep issuing patches; organizations and individuals can apply them; but the botnet authors can, and do, adapt to the patches. There's a reason they're called "patches" and not "fixes".

What would a fundamentally redesigned end-user OS -- designed for today's (and tomorrow's) software ecosystem -- look like? It would most likely involve a top-to-bottom rewrite, from the kernel on up, with predators in mind. Every system design choice would have to be made with an eye to empowering the user but balancing the user’s privileges against threats from outside. System updates, for example, should be seamless, secure, immediate, and not optional. The system itself should be capable of certifying its own secure state.

There are lots of different ways that a botnet-proof system might look -- here is one of them.