Saturday, May 17, 2008

Operating Systems are becoming less important to Consumers

Even a few years ago when buying a computer I was only concerned that it would run a Microsoft OS and that I could put a small Linux partition on it too. The thought of buying an Apple Mac never even crossed by mind.

A key consideration used to always be that there were lots of applications I wanted to run and that in general they were only built to run on the Microsoft OS. In today's world however I no longer think this is the case. Sure there are some apps that are only built to run on one Operating System, but with more and more services moving into the cloud, the Web browser is increasingly becoming the key application many people use.

For servers the Operating System has a larger role to play, but for standard consumer computing it is less important.

Platforms such as Adobe AIR and JRE are also aiding this shift away from the Operating System being so important. These platforms are enabling the ability for applications to be written once and run easily on multiple Operating Systems (or in some cases with a little bit of tweaking but not much).

The role of the consumer computer is changing, in many cases it is only to put "stuff" in the cloud and get "stuff" out of the cloud. With Platforms evolving that can reside on multiple Operating Systems, applications are truely becoming portable.

Familiarity, Marketing & Cost are also key factors that affect Consumer choice. It will be interesting to watch this space.

Thursday, May 15, 2008

Are Portal Servers dead?

Several years ago I was a big fan of Portal Servers (in particular for internal use), and I thought that were going to take off as the standard for public-facing sites (in particular with the release of JSR 168). This however has never eventuated.

I have therefore been asking the question for the past few years of whether the use of Portal Server technologies for public-facing sites is worthwhile, and if so for what sites (or subsets thereof). I am not questioning that the business concept of B2C, B2B, B2E, etc. portals is required, but rather whether the technology platform of Portal Servers for public-facing sites is overkill.

Portal Servers typically perform a number of primary functions (but there are other alternatives), some of which an organisation may not care about:
  • Integration with Authentication / Authorisation framework
  • Templating
  • Personalisation
  • Facilitate application/portlet reuse
  • In-context content management
  • Analytics & Reporting
  • Search
  • Ability to delegate control over part of a site / page

For intranet sites, I think Portals have a place, but I am not as convinced for other sites. So what do you think? Where do you think it makes sense to use Portal Servers (if anywhere)?

Sunday, May 4, 2008

Cultural differences

Understanding how people work and what motivates them is important to getting the most out of them and having a good working relationship.

I have been working with an offshore company for the past 6 months in New Zealand, with whom we have partnered to do some work to build a technology solution. Over these past 6 months I have observed some differences in the way they operate than what I have previously experienced working with New Zealand companies, and once I had identified these differences this has made it easier to communicate.

Having different cultures brings different dynamics to a project, which is great in terms of having people who look at a problem space from a different perspetive; these are my observations with this particular company and the people we have on the ground in New Zealand.

1. Safety in numbers.
In general, with many of the people I am dealing with (in particular the technical people, not so much with the Business Analysts), I have observed that they are not willing to voice their concerns in a 1 on 1 situation. They are however very vocal in a 1 to many environment where they can use the "power of the mob" behind them. Previously I have in fact observed the opposite with some other cultures.

2. Don't document unless it's 99% correct.
I have heard numerous complaints from the New Zealand team about lack of quality of documentation, but when I stepped back and thought about it, it became apparent that the offshore team (in general) were not willing to document anything unless it had been agreed already as being correct by:
a) the Business Owners, and
b) their Company (i.e. the Company is acknowledging they can implement it and will stand behind the solution).

I am used to Solution Architects documenting assumptions, passing this off to a Business Analyst to confirm / deny, and in parallel continuing to drive detail into the document. This is not the model which the offshore team I am currently working with adher to, so understanding this and continually encouraging them to work in this way is the current plan of attack. I have now also changed my approach to provide them with working assumptions to work to, whilst "behind the scenes" work is done to get the assumption ratified.

3. Only take something as being agreed if this has come from somebody high up the chain of authority.
Another common complaint I hear is that the same question is being asked yet again. Until this question is answered by or signed off by somebody who is deemed by them as having sufficent authority, it appears that they will continue to ask the question.

4. Only document as much as is required to keep people happy
All too often the New Zealand culture for IT projects in corporates is to document the solution up front in minute detail before commencing to build; this obviously has its pros and cons. With this particular project we are following an Agile-like methodology, and from what I have observed so far, I think they are working on the assumption that once they build something and present it back to us that:
a) we will be changing our mind about some things, and
b) testing will identify any problems.
With this in mind there is indeed a reasonable amount of detail being documented in some areas, but other areas are reasonably open for interpretation, and therefore it is expected through multiple iterations these areas will be ratified; which in many ways I think is actually a good approach.