Capping IT Off

Wall Street Journal: Most Corporate Blogs Are Unimaginative Failures

Gosh, I sure hope we are making a good attempt at not being a boring a corporate blog here! According to the Wall Street Journal most corporate blogs will bore you to death. Fortunately, the author of the article provides some good hints and examples of good corporate blogs. Let's copy their style and we should be safe. ;-)

I would really value your opinion of our blog now, dear reader. Did I just see you suppress a yawn?

Milking the web

The web has become a very lively place. Around the globe, people are happily sharing all sorts of experiences with any subject you can think of. There now is an enormous collection of thoughts, opinions, stories and conversations that you can draw from when you are selecting a car, finding a suitable mortgage, finding the best hospital for treating your mother's heart condition, purchasing top quality roasted Guatemalan coffee beans or finding out personal information about someone you are thinking about hiring.

I use different web resource types (blogs, search engines, feeds, ...) for finding out about different subjects. Moreover, the resource type that I use for finding out more about a subject depends on my connection with the subject. This is visualized in the picture below. I call it my web usage spectrum.

The horizontal axis marks the favourableness of subjects. On the left are the subjects that I don't care much about and on the far right are my favorite subjects. The vertical axis marks the frequency at which I use certain web resources for finding information about subjects. At the bottom are my least used resources and on top are the ones that I use all the time. The length of the boxes inside the graph says something about the universal usefulness of a resource. It is by no means exact nor did I collect any statistics.

I wish to stay abreast with subjects that I am strongly connected with. For that I am relying on resources that I value and trust. As you can see in the graph, I follow these resources using syndication and collaborative tools. For less favourable subjects I take a more traditional, pre-Web2.0-approach.

My web usage spectrum is highly subjective and reflects how I prefer to milk the web. I adapt it every now and then when I learn new tricks. Usually an adaption leads to an improvement in the quality of the information I find, the time I need to find the information or the amount of fun that I am having.

My guess is that my web usage spectrum is not unique and probably sub-optimal. I know that it is tweakable but I am relatively slow at adopting new tools (I am skeptical and allergic to change...). For example, I was only very recently convinced of the use of twitter (you can follow me here).

This all poses an interesting question: How do you know if your spectrum is optimal in the sense that you use the right resources the right way? One approach to answer this is to compare your spectrum with other spectrums. So please share with me: how do you milk your web?. What does your web usage spectrum look like?

Open up your mind

A day in the life of a Capgemini software engineer: sitting in the plane two seats away from the former Miss World. Dream or reality? Well it did happen to me last week when I took the JetAirways flight from Mumbai to Hyderabad for a course. I was thinking about ways to approach her, you know, just to broaden my network. Was even thinking about the company’s land & expand strategy, but her bodyguard (I think) next to her didn’t seem to be happy with me landing next to her. But I was a man on a mission with no time for chit chat with (beautiful) women, since I was expected at the Indian School of Business in Hyderabad for a course week: RightShore for Software Engineers.

The idea of the Capgemini University course is to let you experience the offshore business where it all happens. How much better can you experience India than in… India? It’s a tough five days course where you get cultural training to better understand how your Indian colleagues are working and why certain things are done in a certain way. It also discusses the root causes for communication failure and why we sometimes don’t seem to understand each other. The other part of the course was geared towards senior software engineers that work in a geographically distributed environment where all issues like RUP distributed delivery, use case estimations in a distributed delivery setting, etc are discussed with plenty of room for networking (50 % Indian participants, 50 % European participants).

The biggest lesson I’ve learned during the course is that we still don’t involve our offshore colleagues enough in our projects. Too often we think that the whole analysis & design and the complex work is done in the front office and the boring repetitive stuff in the back office in India. This course tries to radically change your mind and let you realize that the sooner you involve the offshore team, the better it will be for the project. Think about it, how much effort gets wasted with doing knowledge transfer and trying to assure that the back office has understood everything what the front office has designed? A very effective approach is to involve the offshore team right from the moment of doing the bid (since eventually they have to build it) so that they are aboard even before the project has kicked off.

Does that mean that we have to be afraid for our jobs in the United States and Europe? Look around you at how many open job positions are. True, the lower cost of software engineers in India does play a role when you think about offshoring, but a very important reason to consider offshore nowadays is the fact that we can’t find enough technical IT people in the western countries. We see year after year less people entering the computer science programs at universities, while in India almost everyone that goes into university wants to do something with IT. Capgemini India hires fresh graduates at a rate that we can only dream of in the Netherlands. The lack of sufficient skilled IT professionals in the western countries is a concern to all of us in the industry. We even ask experienced software engineers in our Indian office to fly over to Europe for a couple of months to work at a client location since he or she has a certain skill that is very hard to find in the Netherlands. This means that all of us have to start accepting that this transfer of work skills on a global scale is a necessity if we want to stay competitive. Companies that keep on refusing to join this trend, will face the fact that they stay behind since they won’t find enough skilled IT professionals.

Accept it and open up your mind…

Collaboration. Redefined.

While a previous blog post of mine about my web 2.0 life contained a lot of truth, it still was some kind of parody (I think). However, I start to realize that some of the tools that I talked about like Twitter do have a big influence on the way we communicate with each other to get things done.

I am currently looking into the possibilities of using the Amazon Cloud Computing offer and I was looking around for some like-minded souls in the company. I just twittered (twittering a new verb like googling?) if someone at Capgemini was working on this and it got picked up by Tim Kelly, the Capgemini Second Life guru. He met on Second Life the chief evangelist of Amazon Web Services (AWS) Jeff Barr and brought me in contact with Simone Brunozzi, the European Evangelist for AWS and I got in touch with him through Facebook and LinkedIn.

Another nice example, which is not directly work-related but quite interesting because of the collaborative effort of a crowd to solve a problem. Trough Bombay Expats Yahoo! Group, I got the message from a fellow expat here in Mumbai that she found someone’s credit card in the city center and she wanted to return it. Based on the details she found on the credit card, I did a Google search and found the person’s weblog. The other expats in the community were continuing with the web search and soon we found the email address of the person and were able to contact the “victim”.

So, basically with a set of extra web 2.0 tools like Yahoo! Groups, LinkedIn, Facebook and Twitter, I can tap into a whole crowd of people that can help me in achieving my goal. Often not even intentionally. A couple of very interesting initiatives recently started because someone saw my twitter message or read my blog and approached me. One could call it desperate or inefficient, the fact that I am shouting out something with the hope that someone else picks it up. I like to call it collaboration, but redefined.

RIA becomes synonym for website

During a recent discussion with a colleague about a web application that is being developed, it occurred to me that a customer should not need to explicitly require that web application to be a Rich Internet Application (RIA).

The web application we were discussing is currently constructed as a set of server pages that share a common background image (indeed, rather classical). Depending on the connection speed and how images and pages are cached by the browser, the user will likely experience irregular delays and flickering of parts of the screen. In the case of this particular application, this is hardly acceptable, because this particular customer envisions an intuitive and attractive user interface with "Apple-like quality" (I hear that last one quite often).

It made my colleague and I wonder whether our customer had explicitely requested an RIA or not. But now I believe that a customer should not necessarily need to. The RIA is a technological choice advised to a customer to meet certain (user centered) requirements like the ones mentioned above.

I also believe that, as the hype of the RIA is wearing off, requiring a usable, attractive UI is becoming more and more implicit: "of course our new web application should be easy and fun to use". Peope are getting used to RIAs and expect no less than a smooth and effective experience. They expect no less than a responsive (no delays) and usable application that they can access anywhere, anytime.

High expectations? Well, they might still be today, because these requirements still pose much challenge to the designers and developers of web applications. But that is rapidly changing as the quality of design and development tools are improving quickly (both Adobe and Microsoft are strongly focusing on the quality and productivity of their tools).

Website has become a synonym for RIA and vice versa. Maybe the term "website" will even disappear all together as web applications are already stepping out of your web browser onto your desktop (think Adobe AIR, Mozilla Prism).

Going live with prototypes

I was having this discussion in the office the other day. It was about whether a prototype of a web application (for simplicity, I use this as a synonym for web site) could be seen as a first version of that application. More often than not, a prototype is used as the base line (i.e., using the prototype's source code) for the actual development of the application.

On Wikipedia, a software prototype is defined as follows:
"A prototype typically implements only a small subset of the features of the eventual program, and the implementation may be completely different from that of the eventual product.
The purpose of a prototype is to allow users of the software to evaluate proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions".

This definition is used rather rigidly in paper prototypes. These prototypes basically are rough sketches of views and dialogs of the intended application, including indications for user interaction and visual cues. The intended user gets a rough idea of what views and dialogs the application could have and what interaction elements there are. Paper prototypes are at the lowest end of the fidelity spectrum.

At the other end of that spectrum are the hifi prototypes. These are usually detailed to the very pixel and often already comply with company branding styles. Modern design tools such as Microsoft's Expression Suite or Adobe's much anticipated Thermo make the production of hifi prototypes ever easier. Such tools make prototypes cross over to betas.

Beta versions of software provide early access to intended users so they can evaluate the eventual product. A software beta is a first but thoroughly tested and reasonably stable release of an application and usually implements most of the intended features of that application. It's purpose is the testing of the application "in the field", outside of the environment where the application is being developed. The beta test determines whether the application is ready for production. Betas are often referred to as prototypes.

One step further is putting a beta in production, which effectively means going live with a prototype. Google and Flickr do it, and so do many others. Their applications are characterized by very frequent public releases (weekly, daily, hourly, ...) and are all labeled 'beta': the perpetual betas. These applications are perpetually tested (in the field) and perpetually being improved. The acceptance phase is skipped (which saves much time and money) or perhaps better: has merged with the release phase. To me this sounds like a very sound approach towards web application development.

Internal blogs matter

Like many other companies these days, Capgemini has an internal blogging community. I used to write frequent posts on my own internal blog, but I have been passive for over 6 months. The reason is that I do most of my blogging out in the open these days, which is already taking up much of my time.

I must also admit that I had another reason, besides being too busy blogging elsewhere, for pushing aside the internal blog-o-sphere: the fact that it is only visible from within Capgemini. But I have changed my mind after reading this post on the "Go Big Always" (GBA) blog by Sam Lawrence. I am very much inspired by this post. Thanks for waking me up, Sam!

The internal blogging community of Capgemini is fairly large. People from all over the globe are active in this community. There are blogs that focus on development methodologies, on specific technologies and products, on right shoring experiences, et cetera. However, I am not sure how actively other employees read these blogs and benefit from their contents.

Most people at Capgemini (at least as far as I can see) use good old e-mail for finding and sharing information. They simply direct a question or item of interest at an e-mail group. This usually results in quick answers too. On the other hand, people also complain about receiving too much generally directed e-mail that pollutes their e-mail boxes. Maybe we should use e-mail for specifically directed information only, and use the blogs for generally directed information. That would take a rather large collaborative effort in our case.

But would that really solve anything? Moving information from e-mail boxes to RSS feeds doesn't make much difference to me. I still have to read them, and I still won't have time enough to do that (the number of feed subscriptions I have in my RSS Software exceeds 80...). For me personally, podcasts form part of the solution. I listen to them while I am commuting or mowing the lawn (if I had one). The podcasts that aggregate news and information are usually the best ones.

So, I can only conclude boldly with this: All Capgemini personnel should get iPods. Depending on your role, your skills, your position and your ambitions, your iPod will be automatically synchronized with what you need to hear. We'll probably need to be a little bit further in the development of the third version of the Web to really make this work...

The invisible hand, the sequel

My previous post on The invisible hand created several interesting discussions (thanks Andy, Peter, John, Alex and Mark) and I would like to share some of it with the rest of you. Peter (Evans-Greenwood, CTO Capgemini Australia) brought up the interesting theory of swarm intelligence and I’ll quote Wikipedia to bring you quickly up to date:

“Swarm intelligence (SI) is artificial intelligence based on the collective behavior of decentralized, self-organized systems. … SI systems are typically made up of a population of simple agents interacting locally with one another and with their environment. The agents follow very simple rules, and although there is no centralized control structure dictating how individual agents should behave, local interactions between such agents lead to the emergence of complex global behavior. Natural examples of SI include ant colonies, bird flocking, animal herding, bacterial growth, and fish schooling.”

To extend the list of “natural examples”, I would like to add “Mumbai drivers” as well. If I may. Andy (Mulholland, Global CTO Capgemini) replied on Peter’s comment: “I had not thought of swarm theory for Mumbai traffic but now that it is raised it makes perfect sense”. And it does make sense, really!

“The agents follow very simple rules”: Mumbai drivers honk in all situations to warn others
“no centralized control structure dictating how individual agents should behave”: very true, haven’t seen any speed camera or police controls
And the best one: “local interactions between such agents lead to the emergence of complex global behavior”: As John pointed out in his link that he supplied in the comments, it is the selfishness of the individual that drives a knowledge base, or applied to Mumbai traffic: “The Mumbai traffic participants are selfish in the sense that they do not want THEIR car to be damaged, thus resulting that other cars don't get damaged either.” This all leads to a situation where there are not that many accidents as you’d expect. The selfish drive for self preservation, benefits the whole system.

Alex added a link to a blog entry of the Austrian Economists that did an experiment with speed limits on a highway. On a highway where the speed limit was 50 MPH, everyone was driving 70 and the traffic was flowing rather well. As an experiment, four cars drove 50 MPH just next to each other and thus blocking the traffic, it created a huge traffic jam. If you apply this to Mumbai traffic, you can easily see that there is a much higher throughput possible in this seamlessly chaotic situation. Because they are not following the lanes, speed limits or anything else, but just take every millimeter that is possible and honk their way through traffic.

A question that I still have is whether this selfishness or self-preservation attitude from people always creates an optimum? Or better said, in what situations is this behavior desirable? Could you build your commercial software like this? What I think is that you have to distinct two main categories:

The team or group is more important than the individual: think about commercial software development and sports teams. Of course you need to have expert developers or star players, but in these two cases, the group aspect outweighs the individual aspect. A nice example is a soccer club that has only the best players of the world in the team. When you look then sometimes at their ranking and game play, you see that each individual is brilliant but there are too many egos walking on the field. 11 brilliant soccer players do not make a brilliant soccer team. The same applies to commercial software teams: if you have five superstar developers that can think of the most incredible algorithms, it is no guarantee that your project is finished in time and in budget.
The notion of “group” is actually just a side effect of similar behaving individuals, e.g. Mumbai traffic. No Mumbai trafficker wakes up and thinks “well let’s create a cozy group of mad-driving cars and rickshaws today”. The same applies to economics: a business man’s primary goal is not to create a perfect running economy, but to maximize its business’ profits. But in order to maximize its profits it has to participate in the market workings of supply and demand and thus aid in reaching an optimum. Not because he wants to, but because of selfishness. A good working economy creates a stable environment and thus a higher chance of profits.

To which category does an open source software project belong to? My first reaction is to say the second, but the more I think about it, I’m rather going for the first category. Because when you look at big successful open source projects, they are all managed by either a commercial company, a governing body, some strong community leaders or other way of centrally coordinated effort. True, you see a mixture with the second category in the sense that they often make use of these individuals that are in it out of selfishness. However selfishness in the broadest sense: pride or honor, improving own skills, community recognition or just because they really need that particular feature. Luckily the open source community is mainly driven by the last group that contribute code that was made because of something that THEY needed.

I did put the commercial software development in the first category, but would it be possible to have a commercial project that is driven by selfishness of the individual?

The invisible hand

Only a few people know that I actually love economics, more specifically macro-economics. I love the theories from economists like Pareto, Keynes, Friedman, Ricardo and of course Adam Smith. The latter one’s theory of the so-called “Invisible hand” is one of my favorites since I am quite liberal. Not as extreme as a good friend of mine who has very interesting ideas about a society where the government has almost no involvement at all, I am still a supporter of little government intervention.

Before you point out to me that societies where there is little government intervention are often far from ideal because it does not take care of the less fortunate members of the society, I acknowledge that in real life this does not work out quite as I would like to see. We do not live in a perfect world, where the market is fully transparent, where everyone is honest and is not only focused on money-making. So, often these economic theories do not seem to work quite well as expected.

Why do I tell you that? Not to change the direction of this blog into something like Freakonomics (must read by the way!), but because it relates a bit to my love for self-organizing chaos. Adam Smith’s “The wealth of nations” really focuses on the idea that free markets only appear to be chaos, but there is an “invisible hand” that guides the production and price setting to an optimum.

I am at the moment for three months in Mumbai to lead the RightShore operations from my practice and while observing the traffic, it appears to be utter chaos. People don’t use their reverse mirrors nor direction indicators, but it still “somehow magically” works. Most likely that there are a set of traffic rules, but nobody seem to follow them. How do they manage to drive without constant bumping? Honking and good faith! When you want to overtake someone from the left, you honk. When you overtake someone from the right, you honk. When you think the person before you is going too slow, you honk. When someone is getting too close, you honk. When you… anyway you get the picture.

So, without the need of an enforcing strong hand, each individual seems to take up the responsibility to warn others, by honking, of possible collisions and other dangerous situations. Isn’t this brilliant? When you take a step back from this economic blabla and look at the software industry, you see this idea of not having one central enforcing entity, but shifting responsibility to the participants coming back in similar or reduced forms. Think about distributed source code management tools like GIT or Mercurial or the open source community. The reason why it does seem to work is because they all have an interest in reaching an optimal situation where everything works out nicely, just as the drivers in Mumbai have an interest in not bumping to other cars. True, you often do have a strong “hand” in open source projects, look at Linus Torvalds at the Linux Kernel project, but there are plenty of open source examples where it is more a community-driven project without too many dominating people.

However, I do wonder to what extent this works? It seems to work for a city of 16 million people in Mumbai, but to what extend can you keep on doing this in (open source) software projects? A huge project as the Linux Kernel, would it be possible without having a leader person? And does a leader person necessarily needs to be of a strongly enforcing type? Could this actually work for a commercial software project as well, or is that doomed to fail? Please share your thoughts.

Security Access Permisisons Considered Harmful

Look at the way we set up access permissions today on, say, a windows file. We go into a form and state the exact users and files that will have permission for the file. If we want to set the same permissions on a different file, we have to go through the whole process again, manually.

At home, I have an XP PC, a Vista laptop, a Mac laptop and a network storage drive. My XP PC has 3,000,000 files on it, each file must have its permissions set correctly; my other computers are similar. I have many other applications that control access to my information, not to mention web sites. I have a Capgemini laptop, of course (actually, I’ve just remembered, I have two). Then I have my desktops at client sites; that’s without even starting to think about the clients’ infrastructure.

I have no idea whether my security setup meets the Data Protection Act, or whether it’s sufficient to meet the threats that are out there. In the unlikely event that, by some random chance, I’ve got everything right, if the threat changes, or the interpretation of the Data Protection Act changes, then I’m back to the beginning again.

This should give you some idea of the scale of the security problem we all face. The response we are forced to take, that is, setting access permissions, is rather less powerful than assembly programming. There must be a better way. Ideally, I would want the following:

The capacity to specify an access policy that applies to many different objects simultaneously.

The capacity to specify an access policy in a single place in a single style, which is then interpreted consistently by many different applications and locations.

The capacity to offload security policy setting into the cloud – security as a service.

The good news is, this is now a possibility. The new XACML v2 standard from OASIS describes how a security policy decision point can be separated from the policy enforcement points; along with protocols for them to talk to each other, and a language for specifying rich security policies.

The bad news is, support for XACML v2 in real-world applications is still pretty patchy.

I hope I have now explained why security access permissions, as currently implemented, cannot hope to solve the security problem, and justified the provocative title of this blog entry. XACML-style rich policies are, I believe, a crucial component for building a collaboration-oriented architecture and meeting the de-perimeterisation challenge.