I’ve had my Nokia 6233 phone for about 6 months now.  Recently I’ve been wanting to buy an iPOD, but couldn’t really justify the extra gadget just for heading to work and back.  Anyway, in conversation with someone at work, they mentioned they’d been using their Nokia phone as a music player. 

I should point out that we all have the same model of phone here, they get upgraded with our laptops every two year, so there is some excuse (it’s not like I reviewed the feature set it just landed on me), but it struck me that after 6 months there was a whole set of features in the phone I’d never explored, even when the phone could address a need I had.

Sitting down with another person with the same phone today, I was telling them how excited I was about this (I bought a 2Gb micro SD card and now have some 20 cds worth of music or more loaded up).  Sure it’s not quite the iPOD experience, but it’s a big step up from where I was at.  They didn’t know how to do it, and pulled out their phone only to find they’d configured theirs using yet another set of options I didn’t know about.

It got me thinking about how yet again, tools and software are so feature rich that it’s just difficult for one person to know how to use all aspects of it.  I once heard a quote something along the lines that each person only uses 10% of the features available to them in Microsoft Word or Excel.  The problem is that everyone uses a different 10%.

What this leads to is tools which do many things — they are feature rich, but they don’t do all of them well — leading to them being both feature rich and poor at the same time.  I call them the Rich - Poor.

The Nokia is a perfect example of this — I really love having my music on the go with me, but for listening to music, an iPOD, with its navigation features built into the device is vastly superior.  With the Nokia, I get 150 tracks in sequential or random order.  I can build play lists, but I have to do them manually on my PC first and can’t just choose to listen to “jazz” or a specific album on the go.

Another story I was reminded about was the Firefly.  This is a great example of a Poor - Rich product.  What’s fascinating about this is that the product designed for 8 - 12 year olds became popular with senior citizens in the US, because of it’s limited (and therefore easy to understand and access) feature set.  Catching on to this trend the Jitterbug quickly followed.  A simple set of features, but a depth and richness in the market because it does them well and htis one need in a clear, specific way.

In the software world, we also see this becoming clearer with the move to services and WEB 2.0.   Instead of Rich - Poor applications, we are now getting Poor - Rich services, services that a feature poor in terms of the diversity within the one application, but rich because of the complexity and ability that the service provides.

Of course it’s no suprise this trend has already started, but the next two years is going to be a facsinating time as instead of Rich - Poor apps, we get a true diversity on the Internet with Poor - Rich apps to meet every niche popping up faster and faster as services become more prolific and the tools to plug them together move to new levels of maturity. 

For most avid blogophiles, RSS/ATOM is a simple means of publishing content in a format that content aggregators can easily read and interpret to provide us with news feeds when and where we need them.  It’s all about the article feed - or is it?

While it’s clear the predominant use of RSS/ATOM is really driven around article feeds, actually there is nothing to prevent the underlying payload from being any form of data that we like.  Data exposed by RSS/ATOM has some interesting architectural implications.

1. The most interesting one is that properly formatted and consumed RSS/ATOM feeds understand WHEN they were relevant and provide means to know WHAT you’ve already read.  While this could be implemented into a direct call Web Service, it’s nice that it’s already built into RSS/ATOM and abstracted away from the calling application. 
2. Interfaces become simpler — while applications need to understand the data, the exposed service is clearer.  Reading a RSS/ATOM feed is well understood without needing to know all the properties, use WSDL or other description services you can access the available information.

I don’t believe that SOAP based web services will be replaced, however there are opportunities to look at the use of RSS/ATOM for moving data when a complex service interation is not required, which is a typical issue most first time SOA efforts come up against.   Even then, services like Yahoo pipes, will provide a mechanism for extracting a interacting across multiple RSS/ATOM feeds.

In the services based world, we should be de-constructing objects to their simplest deliverable form, then aggregating them to maximise re-use where needed.  For data transfer options on a subscription basis, RSS / ATOM looks like a good choice.

Interestingly, ATOM is in fact one technology of choice for the underlying data synchronisaton capabilities for Lotus Expeditor

I predict it’s probably only a matter of time until Yahoo has a Pipes Appliance (something like the Google search appliance — a “black box” that can be installed on your own network) which Enterprises can use as a glue between syndication services within their domains.

If you’re considering a SOA strategy, then RSS/ATOM syndication is one tool in the box that can help with data synchronisation across applications, leaving your Web Service designers to focus on the real value of services which is complex, business services replication.

For some SOA implementations, particularly those not needing compensation, this is one more stragtegy to help remove the need for process orchestration services, allowing applications to use RSS/ATOM to pull data from one place to another.

Touchstone popped this up from the blogosphere:

Every company innovates until it finds a cash cow. At that point only innovation that supports the cash cow is promoted. Further, any innovation that threatens or does not support the cash cow languishes or is actively killed. Eventually, most of the true innovation ceases as the innovators leave and start new companies and the cycle repeats. From The Walrus and The Carpenter

Certainly at first glance there is some merit in this. But is it really true? After all, IBM originally created calculators (although there is a good argument that the computers of today just do what these machines did but faster), but at some point ended up a leading hardware and software company — in fact they define their business principle as innovation.

My view on this is that I think it’s true to say that there are very few (if any) companies that change tack once they hit on their Hedgehog Concept (from Jim Collins in his book Good to Great). But does this mean they don’t innovate?

No.

Google continue to innovate and produce new web based solutions, some centered around search, others outside of this. But then their hedgehog idea would be something along the lines of being the worlds leading on-line software company. They don’t innovate around cars.

The challenge for all businesses is to ensure that having a sound hedgehog concept — knowing what you are good at — doesn’t detract from allowing news ways of doing what you are good at to creep into vision. Many of us would be familiar with the project mentality which is that when under pressure to manage costs, time and scope, the natural reaction is to do things the same way I did them last time. While sound project and business practice, it’s the biggest “anti-innovator” within corporates today in my view.

This is where Enterprise Architecture can help. I’ve created this diagram to show how I try explain the relationship between Architecture and Innovation.

Sound architectural practices are key to innovation. Without a view on the future, and a drive to ensure that projects comply and take advantage of newer technologies, innovation will always be constrained. Staying too focussed on what you’re good at, and not challenging the boundaries and introducing managed risk means you will never be innovative. Good Enterprise Architecture can help.

I found this Wall Street Journal video here at The Lost Remote.  One of the things I’ve been working on at the moment is a retail sector publication on trends and issues for 2007.  This video sums up succinctly the message I’ve been trying (like many others) to get across - the world of communication (as in Internet and Mobile Phones) is fundamentally changing.

Apart from being an entertaining little video, it issues some real challenges which is to get our heads around some of these types of features.  Particularly for retail (ie consumer focussed sectors) understanding where the internet and mobile technology is going will be key to early mover advantage and future success.  Taking advantage of the application driven nature of the Web 2.0 and plugging services together with proprietary systems is the compelling challenge for companies today — even if they don’t realise it!

From an Enterprise Architecture point of view, an SOA view of the world is becoming even more critical.  It’s all a service, wether it’s an internal or external application, the boundaries are changing.  With a strong services focus internally, then mashups between internal and external apps become compelling value adds for consumers and the companies that serve them.

Here’s a simple example, using Plazes, another interesting startup I’ve come across recently.    There’s a similar service shown in the video.

Plazes is at first glance locating you on a map. Kind of neat, but when you explore it under the hood a bit you realise it’s also a locater service for friends and others in your area.  For a retailer, the scenario could play out like this.  Set up Plazes, place your retail outlets, let your customers hook up as friends then use the Plazers service to let you know when your friends (ie. customers) are near your location.  This kind of location mashup could be put together quickly with a prior investment in SOA internally, enabling you to then link the friends to your backend systems, work out what they’ve purchased recently then contact them to tell them that there is a special offer available now if they come into the store.

What the Web 2.0 evolution is doing is removing the requirement for us to wait for big vendors or vertical applications.  Enterprises should be acting now to ensure that they are ready to grab the best of the web and put it together in innovative ways for their customers. 

That means sound SOA strategy so that agile developers can pull together the systems they need to create compelling applications.