Thursday, April 27, 2006

The Search Box is the New UI

I was listening to Phil Windley's AJAX Progress and Challenges when the bells rang. While describing the JavaScript programming that is taking place inside the Browser's guts, Windley pointed out that browser-based client applications have become O/S indifferent. Operating systems have been finally abstracted out from the entire transaction chain.
And then the inevitable metaphor ("Everything is a metaphor") of the Browser-as-a-Platform was mentioned, triggering a bunch of thoughts in my head on the Browser-as-a-platform interfacing the Internet-as-Platform, thoughts that made me feel dizzy after a while. Something was wrong and I was having a cognitive Ajax dissonance which I will describe now.

Dissonance#1: The Browser

We're living in this Browser paradigm ever since the Internet (and terminals) was invented. Don't you find it strange that everything else is changing but the Browser is still around?
Browsing is efficient when there's a blueprint, a layout. Think about an application's menus or a site's map: the user navigates according to the site/application explicit structure. And that's efficient because the user is supposed to invoke functions. Most of the sites/applications are created to realize functions, so they make their functional layout explicit, enbaling the user to browse and navigate through the functional tree. Many business sites have the following functional layout: about us; products; services; solutions; events; press room. Commerce sites have this functional layout: books; electronics; your cart; wishlist etc;

Users are required to invoke functions in order to get Information and/or set Information.

Now here is the bare truth: Information is locked behind functional bars; users want to get/set Information, but they can do so only by going through the site/application functions. And for this kind of navigation the Browser is a most suitable user interface.

Only that Web2.0 – the same Web2.0 exalting the Ajax Browser (and see the second paragraph in Dion Hinchcliffe's article) – has turned the functional paradigm on its head. With RSS, the site/application Information is unlocked and published to the Global Information River. People can get the Information they want without going through the functional sites/applications. And with Microsoft's SSE and Google's Gdata they can also update the Information River, again without necessarily visiting the site/application.

Now, the Global Information River has no functional layout, so browsing the River will get you nowhere. The Information River mandates another kind of UI, and I think we all know what this interface is: it is search.

The Search Box is the new UI!


This formidable phrase was coined by Adam Gross, Salesforce.com VP of Developer Marketing, while describing the cooperation between his company and Google's Enterprise Search 2.0 – an appliance that indexes not only unstructured data like documents and mails, but also databases of major application vendors, such as Salesforce.com. So if a sales person wants to know details about the customer he's about to meet, he only has to search for it, and…

Strange. Salesforce.com just acquired Sendia, a company specializing in rendering Browsers into all sort of devices. But if we stick to Adam Gross' logic, Sendia shouldn't have been acquired at all. Instead a Voice interface to a Google Search Box which, in its turn, is mapped to Salesforce.com database would've been a better choice for Salesforce's mobile strategy. After all, what the user at the end of the device really wants is not a foxy Nokia interface but real-time Information. If she can get it by talking to the device, she'd be much more productive.

So Google's in this game. What about Yahoo!? Read & listen to Jeff Bonforte, Senior Director of Voice Product Management at Yahoo! about their plans.

Dissonance#2: APIs vs. UIs

Another Browser-based dissonance has to do with mash-ups. Web 2.0 is all about mashing up the site/application APIs. In other words, it's all about a site/application providing access to its functions/Information through APIs. If no APIs are offered the site is practically out of the game. I will redraw your attention to an excellent article in SkypeJournal.com, where the dilemma of whether to develop API or UI is well described. The conclusion is that in a Web2.0 reality, APIs should have precedence over UI.

Conclusion:

I enjoy Ajax UI very much and the Browser-as-a-Platform metaphor is absolutely cool. Only that the Browser is a limited and not that efficient way of interfacing with Information. The more people will become Information Junkies, the less they will find the Browser suitable for their needs. I'm having a dilemma here, so I'm going to take an aspirin.

6 Comments

By Blogger Paul Jardine, at 1:41 PM  

I think you're right about the browser being an 'old fashioned' way of getting information.
I had envisioned MMORPGs as the access mode of the future, which I initially thought didn't tie in with 'Search as the new UI' but on reflection, the online world effectively just overlays structure onto the Global Information River, providing an 'index' to enable better access.
Web 2.0, JAM tomorrow (Just Another Mashup) ;)

By Anonymous Anonymous, at 2:02 PM  

Hi!
Take some XUL to create a un-headacked interface.
Technically ajax is a not a solution. It is a solution for users but not for programmers.

Gabriel

By Blogger Muli Koppel, at 2:05 PM  

Hi Paul

It's a very interesting perspective you're offering: sites and applications as convenient "Lenses" over the Panta Rei. The Browser-as-a-place-of-Order in an unstructured, chaotic Information world. Great perspective.

By Blogger Muli Koppel, at 2:36 PM  

Hi Gabriel

Ajax, XUL - everything's a metaphor. It's the browsing paradigm I'm interested in.

By Anonymous GabrieL, at 2:29 PM  

You are right of course about ajax, i did not finished your article yet - sorry... (as a developer, so i stayed stuck to the Ajax buzz word, which get me on my nerves)
Just to add a testimony about web2, i was a happy web surfer, but I almost stopped hanging around the web since i took "google reader" as my web home page.
In a way i am sad of that, i liked diversity, surprises, meeting with other people way to be. Surprinsingly, in your paradigm ui v. api, i regret the ui. That is why i still think that the universal plateform - the web browser - has its future. Not as the unique way - as in the early years of the web. But i think internet is a neutral place. People come to find some information. And other people come to give information.
How do they meet? Why? When? This is where the magic begins, something out of our control, out of our way to broadcast information, in a place where you hear people talking to each other about this web site, or that one, where you googlise anything, the name of your friends, the names of writters... I mean: creating an api is today a great way to create a market, but do not forget freedom, and pleasure, of the web, do not forget what is out of our scope. You can only find if you have the willing or the pleasure to search.
That is why i am still advocating for xul - ie (oops...) a universal and neutral plateform :-)

By Blogger Muli Koppel, at 9:45 PM  

Hi Gabriel,

Thanks a lot for sharing these thoughts of yours. I think that both Paul and yourself are making clear that the Browser is much more than an Interface, or a Platform.
It is a place of order and it is a place where human socialization takes place. Hence, its importance for us – the human users of the Net. I agree wholeheartedly.

Post a Comment

Monday, April 10, 2006

Identity Auctions at eBAY– Here We Come (or, We Can Remember It For You Wholesale)

I'm not sure whether it's Steve Gillmor's long-time Attention crusade, or whether it is that people simply gave up the idea of protecting their Identity, after the latest DoJ-Giants affair – anyway, it seems to me that another sacred cow has been slaughtered: Identities have become a tradable currency.

Bob Tedeschi's "Every Click You Make, They'll Be Watching You", describes Claria, the company behind the infamous Gator software, and its new PersonalWeb - "a service that will let people download a piece of tracking software and receive a home page filled with news stories and other information tailored to their interests".

This is probably the 1st "Let me track anything you're doing for your own benefit" service, but many will certainly follow. For Steve Gillmor has been doing a terrific job in persuading people that their Identity can be monetized (see Root Vaults, chaired by Gillmor's ex-companion, Seth Goldstein) and that it can yield great advantage for them, the users, in this timeless era we're living in (as presented in his gestures bank concept).

The thing is we always knew – probably ever since the appearance of the Homo sapiens - that our Identity is valuable; it's only that trading in human Identities had been considered a taboo. Identity is not a tradeable currency, and therefore that one ancient exception in which it was traded for a potage of lentils gained a considerable attention...

But this taboo is now obsolete. "We have established what you are, madam. We are now merely haggling over the price". Identity Auctions at eBAY– here we come.

Attention Laundering.

There's one more thing to say on the emerging Identity trading markets – we're about to witness the greatest Attention Laundering ever. Now that the old taboo is no longer an obstacle, the Giants that have been tracking our every move for years will soon open the buried Identity canisters and release our re-engineered virtual selves for trade.

Here's a story, in which I reveal my greedy and dishonest past: In the year 2000 I worked for a startup that created an ad banners placement engine that has been sold to ISPs around the world. I had that idea of creating a Personalized Ad Server, targeting each individual according to his/her accumulated, analyzed and aggregated clickstreams. This involved the creation of a multi-terabytes clickstreams data warehouse, and so I headed north to Boston to meet some world experts in this area. I was naïve enough to think my idea was original, but then one of those experts told me that XXX, one of the largest ISPs in the US, has been collecting, for years already, any click made by their millions of subscribers. "What are they doing with all these clickstreams?" I asked him, and he shrugged and said: "Nothing!" Those illicit clickstreams have been stored inside nuclear-proof canisters that were later on buried deep under the Giants' data centers, until the time will come to open them up.

And that Time, so it seems, has come.

* We can Remember It For You Wholesale is a short story by Philip K. Dick in which human memories (Identities?) are traded. This story was adapted into "Total Recall", hence Schwarzenegger.


0 Comments

Post a Comment

Tuesday, April 04, 2006

Should Your Next CEO Be a Philosopher?

In the previous post, Organizational Architecture for the Real-Time Enterprise, I described an Infra group incapable of coping with endless, unpredictable events. Systems were falling, customers were angry, and employees were eroded and frustrated. Things like that don't happen out of the blue, and therefore an environmental context, which I believe was the root cause of these phenomena, was presented in the first part of our story.

I was called to re-architect this group, and so I thought… why not transforming it into a real-time Enterprise organization?
To accomplish that, several things at the organizational level had to happen: few machines had to be introduced, and the organizational structure had to be modified. As for the machines – those included event listener and processor, services and SOA hub, as well as a utility computing engine, capable of dynamic reallocation of general-purpose resources. As for the organization structure – it became flat: no hierarchies, no managers.

After this intro, we're ready, I believe, for some more details.

(If you haven't read the first part of this story, I assume the following would be somewhat decontextualized).

Goodbye Point-to-Point

As I described in the Socio-Politics of SOA, point-to-point is a powerful social paradigm. It creates trust among individuals – a social texture that is highly important and advantageous in times of crisis, failures, bugs and so forth. And yet, from a management perspective, point-to-point is a nightmare – no formal documentation, difficulties in tracing, monitoring, validating and controlling. And there's no reuse.

The point-to-point links - PM->Storage team; PM->DBA team; PM->Unix team etc. - had to be removed, as it created sort of a black hole, sucking whatever management-related Information into a total oblivion. Hence, the first architectural component introduced was…a HUB.

The full name of the hub was the I/O Hub – input and output hub. Whatever came in and whatever went out, had to go through the I/O hub. Customers' requests and requirements were filed against the hub, and it was the hub that provided delivery dates as well as the actual deliverables.

At this early stage the hub consisted of two-three highly representative and customer-oriented folks (I called them the foreign ministers of the Infra Group), with whom the PMs and whoever else interacted from then on.

The rest of the Infra group went underground.

It is amazing how powerful this simple concept of a hub is, and how much benefit it brings. The Hub is inherently an Agile construct, meaning it is suitable for endless internal optimizations, without affecting its interfaces to the outside world (in our case – to the PMs). All the following functions were added to the I/O hub progressively:

Capturing customer requests; analyzing their impact; performing a cross-infra high-level design (impossible in the point-to-point era); building work plan; invoking services; allocating resources to the services; communicating delivery dates and providing regular progress reports to the customers; verifying internal progress of execution; monitoring delays; verifying quality of deliverables and on and on and on. Endless functions can be hosted by the hub.

With an I/O Hub the management Information is abundant. You can slice it and dice it, have reports or real-time alerts, present it in portals or in management dashboards. The hub is the land of endless possibilities.

Centralized or Decentralized?

For those of you who dislike the centralized nature of the hub and would rather see a scalable, failure-free decentralized architecture, similar to Skype's peer-to-peer, I would say that in order to get from chaos and disorder to a robust decentralized architecture, there must be an interim, centralized, hub phase. Only when management is reinstituted, that it can be deliberately federated and deconstructed, keeping the management principals vivid in the new decentralized reality. In any case, never confuse point-to-point with decentralized architecture. Point-to-point is not architecture.

Service Orientation

Once the human I/O hub was in place, the time has come to introduce the Services layer. While the role of the Hub is to make sure management happens on the organizational level, the role of the Services is to make sure management happens on the functional level. Here're some points that will clarify things a little:

1. Services are the automation starting-point

Services create clear limits. Installing a server is not installing a database. You think "Wow" – that's trivial, but having clear boundaries is not that easy. Actually, most of the organizations I know are seriously suffering from ill defined boundaries, too much gray areas, overlapping responsibilities and so forth. So boundaries are important.
Now remember that this infra group used to work from memory – without checklists. I could tell them (which I did…): "Ok guys, you got one month to create a checklist for whatever you're doing!" but then most probably they would have scratched their heads trying to figure out where to start, and where to focus their efforts; for there are so many things they were doing… from memory. Hence, Services. Once we have defined the Services, it was a straight forward task to create their underlying checklists.

Once the checklists were defined, they went through several cycles of testing until they got the quality seal. This was a great step towards quality assurance of the infra group deliverables.

At this stage, the checklists, like the I/O hub, were executed manually. But now that they finally existed, it was pretty straight forward to launch a "checklist automation project".

Which services to automate first?

Using the management information provided by the I/O hub, this question was easily answered. Automation was first planned for the "most wanted" Services.

2. Services are traceable units of work

Another important point in managing tasks and projects is that Services hosted in a services' hub are traceable units of work. SOA hubs provide natural BAM/BPM/SLM information, eliminating the need for other tools in this space (didn't we say that SOA=aligning IT with Business?)
In our case study, the I/O Hub provided detailed reports (and online Information) on:
A. Services – execution time, num of requests, SLA, problems, most wanted/less wanted services;
B. Customers – who, what, when. Top services per customer and so forth.

Summary: Services create clear functional boundaries; they stimulate automation and consequently quality; and their host – the SOA hub – provides indispensable insight upon the overall performance of the projects and tasks that use them.

SLA and Contracts

Services do not have an intrinsic SLA. This is defined for each Customer-Service relationship. Some customers need Service X to be executed ASAP, while others couldn't care less if Service X would be executed a week after their request. As there's no accounting to tastes, there's no point in trying to "convince" the customers about the "right" SLA for a service. Give them each what they want.

It's time now to execute the Service. But for that we need some Resources.

General Purpose Resources

When examining each line in the different checklists of the different services, it becomes clear the many services rely on the same resources. Scripting is a good example – almost all technical services need scripting. Basic level UNIX administration is also something required by many services, etc. etc.

Apparently, most of us are innately multi-purpose resources. In our case study, it turned out that DBAs have basic, yet solid understanding in system administration; that UNIX administrators have good knowledge in storage administration and vice versa; that most of the group members were scripters; that some were natural project-managers, and that others excelled in problems resolution. Each employee had a variety of skills ranging from "basic" to "expert", skills that were not necessarily related to his/her job title!

So we made a table of all required skills (the required skills were deducted from the Services created in the previous step). Each skill had 3 levels: basic, advanced and expert and each employee was mapped against the different skills' levels.

This is how we mapped our [human] resources and created a platform for dynamic resources reallocations. We made each single-purpose resource (for instance, a storage manager) a general-purpose one by exposing the variety of skills that each employee had.

Finally, to guarantee the future availability of general purpose resources, the HR group was instructed to have a clear preference for multi-purpose candidates.

Execution Time

We have restricted ourselves to a one-week reallocation of human resources. At the beginning of each week, every employee was receiving his/her weekly tasks. Usually, those tasks were in his official domain of expertise, but in other times, he was doing work for other Services that required his skills.

As said before, it was the I/O hub that generated the weekly tasks list.



"The World is Flat" and so is the Real-Time Enterprise

As you remember, the infra group team leaders were super geeks - experts in their domain. In the old, function-oriented organization, these experts got promoted to team leaders' position, thus becoming the endless tasks managers of their teams.

The Department Managers were veterans in their domains, and their function was to manage their managers.

This is a classical hierarchy in an organization where change is predictable, and therefore the structure reflects a chain of command and control. When the CEO says something it filters down through the entire organization's hierarchy. There's Time for that – change is predictable.
But in the real-time Enterprise there's absolutely no Time for going through all the organizations level, translating on the way what the CEO "really" meant. The real-time Enterprise is structured around mission-critical, real-time decision centers. These centers get an event, to which they immediately react. The model used is no longer "chain of command", but rather "sense-and-respond". That been said, it is clear that hierarchies are no longer relevant; moreover, they are a potential obstacle for spontaneous, on-the-spot reaction.

Nevertheless, the managers of the past are critical for the organization of the future. They are not redundant. Like their organization, they are transformed into new kind of roles.

Team Leaders – The Services Engineers

The team leader's new role has two facets: technical and instructive.
The team leader technical role is to be a chief architect, designer and engineer of the services of his/her domain of expertise. She should decide how the service would be implemented (the checklist…), how it would be automated and so forth. Along with this technical responsibility, comes an instructive one. The team leaders of the past become the gurus and the role models of the present. They teach, instruct, assist and mentor newcomers as well as other infra team members. Their role is to ameliorate the general purpose nature of each employee.

Department Managers – The Strategic Thinkers

The department managers become members in a new strategy sub-group. The strategy group is the ruling elite. They decide which services the infra group will provide to their customers; they design, add and optimize the functions of the I/O hub. Differently put, they define how the group as a whole should function.

They have multiple inputs for their endless organizational design: feedback from the customers; feedback from the infra group employees; statistics from the I/O hub and, of course, new technologies from the outside. All are combined to form the always evolving strategy of the group.

If this reminds you of Plato's Republic - well, I'd say it's an adequate association. Productive Workers [general-purpose resources], Protective Warriors [ex-team leaders] and Governing Philosophers Kings [ex-department managers] - are the three classes in Plato's Republic. No wonder many universities around the world started promoting a new kind of studies, the "Philosophy of Technology", using the following slogan: "Should Your Next CEO Be a Philosopher?"
Hmm, I think I'll have a glimpse on that Republic book.

Organizational Architecture Wrap-up

1. I/O hub
Requirements management, customer relationship management, internal PM, task management, resources allocation, and quality control
2. Strategy group (ex dept managers)
Which services, overall processes and procedures, new technologies
3. Experts Group (ex team leaders)
Designing and leading the development of the various Services, as well as being role models and mentors for the other employees.
4. Employees
Human, general-purpose resources executing the services

Challenges

In the flat, ESDR real-time Enterprise, Managers are no longer managing (neither people nor projects); rather they become strategic thought leaders. As noble as this transformation might be, managers usually don't buy it.

The public image of the successful manager is almost always quantitative: how many employees do you have? How many projects do you manage? How big is your… budget?

Any CTO who is not managing (a considerable amount of) people is doomed to have a lower organizational image than his/her colleagues (and I recently heard that venture capitalists are nicknaming the CTO co-founder: "The Pizza Guy". Ask your VC friend for an explanation…).

So managers are automatically reluctant whenever it comes to renouncing on power (and indeed, why should they?). But there's another problem besides ego: not every manager wants or is capable of being a strategic thinker. So to make a (very) long story short – managers are the biggest challenge faced by the new organization. All the other problems that you might encounter in the transformation, such as processes which are not optimized; services suffering from poor quality; resources that are wrongly allocated etc. – all that is normal and gets better over time. People's mindset, on the other hand, is really hard to change.


0 Comments

Post a Comment