Dhara Consulting Group

Data Synchronization among Federal Enterprises

Sastry Dhara — Mon, 22 Sep 2008 01:30:00 GMT

One of the common causes for sub-optimal performance of large-scale enterprise systems is lack of
data synchronization. Our recent experiences with a large Federal Government Agency brought this fact to us with increasing clarity.

Imagine a large network of hospitals, where a patient can go to any one of 130 medical centers. Imagine also that this network of hospitals can be connected to the external entities such as pharmacies, private hospital chains and the like.

Imagine further that there are approximately 26 million patients in the network and the objective is to maintain a unified patient record that keeps the most comprehensive data about the patient all the time, including radiology reports and drug interactions.

As you can see, the problem at hand requires a lot of synchronization of data across multiple data sources. It is very challenging indeed!

This is an area where the Federal Agencies can benefit from the good work done in the private sector. One of the premier not-for-profit organizations named GS1, based in Brussels, Belgium has been successfully implementing the concept called GDSN (Global Data Synchronization) across large enterprises in the world. For more information, visit:
GDSN

Data Synchronization and Data Normalization are areas that require increasing attention from the computing industry.

Sastry Dhara

Global Financial Crisis and how belt tightening in IT can help

Sastry — Sun, 06 Jul 2008 01:09:00 GMT

Global Financial Crisis and IT Sourcing

Since the third week of June 2008, the DOW Jones and other major financial markets went into a tail-spin. Watching our individual portfolios melt away takes tremendous courage. Knee-jerk reactions such as panic selling will only exacerbate matters.

Switching gears from an individual perspective to a corporate view, the IT Executives must be on the prowl for some cost-saving opportunities. With the overall IT Services sector reeling under intense pressure, it is now time for Corporations to introspect their sourcing strategies. Most such sourcing agreements may be relics of the past and may not address the changing scenarios of this year.

At Dhara, we realized the importance of sourcing strategies and have assembled a top-notch team for sourcing. Our expert team of Sourcing professionals have managed the entire process of RFI, RFP and RFQ. Our independent and objective assessment will help corporations reduce costs and improve efficiencies.

For more information on how we can help your organization optimize your sourcing strategies. please visit us at www.dharacg.com or send email to: sales@dharacg.com

Sastry

2012

Sastry — Wed, 19 Mar 2008 14:58:00 GMT

Fictional Scenario: How Google beat Amazon and eBay to the semantic web. This story was originally written in 2008

It's hard to believe Google - which is now the world's largest single online marketplace - came on the scene only a little more than 12 years ago, back in the days when Amazon and Ebay reigned supreme. So how did Google become the world's single largest marketplace?

Well, the short answer is “the Semantic Web” (whatever that is - more in a moment). While Amazon and Ebay continue to have average quarterly profits of $1 billion and $1.8 billion, respectively, and are successes by any measure, the $17 billion per annum Google Marketplace is clearly the most impressive success story of what used to be called, pre-crash, “The New Economy.”

Amazon and Ebay both worked as virtual marketplaces: they outsourced as much inventory as possible (in Ebay's case, of course, that was all the inventory, but Amazon also kept as little stock on hand as it could). Then, through a variety of methods, each brought together buyers and sellers, taking a cut of every transaction.

For Amazon, that meant selling new items, or allowing thousands of users to sell them used. For Ebay, it meant bringing together auctioneers and auction buyers. Once you got everything started, this approach was extremely profitable. It was fast. It was managed by phone calls, emails, and database applications. It worked.

Enter Google. By 2002, it was the search engine, and its ad sales were picking up. At the same time, the concept of the “Semantic Web,” which had been around since 1998 or so, was gaining a little traction, and the attention of an increasing circle of people.

So what's the Semantic Web? At its heart, it's just a way to describe things in a way that a computer can “understand.” Of course, what's going on is not understanding, but logic, like you learn in high school:
If A is a friend of B, then B is a friend of A.
Jim has a friend named Paul.
Therefore, Paul has a friend named Jim.
Jim has a friend named Paul.
Therefore, Paul has a friend named Jim.

Using a markup language called RDF (an acronym that's here to stay, so you might as well learn it - it stands for Resource Description Framework), you could put logical statements like these on the Internet, “spiders” could collect them, and the statements could be searched, analyzed, and processed. What makes this different than regular search is that the statements can be combined. So if I find a statement on Jim's web site that says “Jim is a friend of Paul” and someone does a search for Paul's friends, even if Paul's web site doesn't have a mention of Jim on it, we know Jim's considers himself a friend of Paul.

Other things we might know for sure? That Car Seller A is selling Miatas for 10% less than Car Seller B. That Jan Hammer played keyboards on the Mahavishnu Orchestra's albums in the 1970s. That dogs have paws. That your specific model of computer requires a new motherboard and a faster bus before it can be upgraded to a Pentium 18. The Semantic Web isn't about pages and links, it's about relationships between things - whether one thing is a part of another, or how much a thing costs, or when it happened.

The Semweb was originally supposed to give the web the “smarts” it lacked - and much of the early work on it was in things like calendaring and scheduling, and in expressing relationships between people. By late 2006, when Google began to seriously experiment with the Semweb (after two years of experiments at their research labs), it was still a slow-growing technology that almost no one understood and very few people used, except for academics with backgrounds in logic, computer science, or artificial intelligence. The learning curve was as steep as a cliff, and there wasn't a great incentive for new coders to climb it and survey the world from their new vantage.

The Semweb, it was promised, would make it much easier to schedule dentist's appointment, update your computer, check the train schedule, and coordinate shipments of car parts. It would make searching for things easier. All great stuff, stuff to make millions of dollars from, perhaps. But not exactly sexy to the people who write the checks, especially after they'd been burnt 95 times over by the dot-com bust. All they saw was the web - the same web that had lined a few pockets and emptied a few million - with the word “semantic” in front of it.

. . . . .

Semantics vs. Syntax, Fight at 9

The semantics of something is the meaning of it. Nebulous stuff, but in the world of AI, the goal has long been getting semantics out of syntax. See, the trillion dollar question is, when you have a whole lot of stuff arranged syntactically, in a given structure that the computer can chew up, how do you then get meaning out of it? How does syntax become semantics? Human brains are really good at this, but computers, are dreadful. They're whizzes at syntax. You can tell them anything, if you tell it in a structured way, but they can't make sense of it, they keep deciding that “The flesh is willing but the spirit is weak” in English translates to “The meat is full of stars but the vodka is made of pinking shears” or suchlike in Russian.

So the guess has always been that you need a whole lot of syntactically stable statements in order to come up with anything interesting. In fact, you need a whole brain's worth - millions. Now, no one has proved this approach works at all, and the #1 advocate for this approach was a man named Doug Lenat of the CYC corporation, who somehow ended up on President Ashcroft's post-coup blacklist as a dangerous intellectual and hasn't been seen since. But the basic, overarching idea with the Semweb was - and still is, really - to throw together so much syntax from so many people that there's a chance to generate meaning out of it all.

As you know, computers still aren't listening to us as well as we'd like, but in the meantime the Semweb technology matured, and all of a sudden centralized databases - and Amazon and Ebay were prime examples of centralized databases with millions of items each - could suddenly be spread out through the entire web. Everyone could own their little piece of the database, their own part of the puzzle. It was easy to publish the stuff. But the problem was that there was no good way to bring it all together. And it was hard to create RDF files, even for some programmers - so we're back to that steep learning curve.

That all changed - suprisingly slowly - in late 2009, when with little fanfare, Google introduced three services, Google Marketplace Search, Google Personal Agent, and Google Verification Manager, and a software product, Google Marketplace Manager.

. . . . .

Google Marketplace Search

Marketplace Search is a search feature built on top of the Google Semantic Search feature, and it's likely nearly everyone reading will have used it at least once. You simply enter:

sell:martin guitar to see a list of people buying Martin-brand acoustic guitars,

and buy:martin guitar to see a list of sellers.

Google asked for, and remembered, your postal code, and you could use easy sort controls inside the page to organize the resulting list of guitars by price, condition, model number, new/used, and proximity. The pages drew from Google's “classic,” non-Semantic-Web search tools, long considered the best on the Web, to link to information on Martin models and buyer's guides, as well as from Google's Usenet News archive. Links to sites like Epinions filled in the gaps.

So where did Google Marketplace Search get its information? The same way Google got all of its information - by crawling through the entire web and indexing what it found. Except now it was looking for RDDL files, which pointed to RDF files, which contained logical statements like these:

(Scott Rahin) lives in Zip Code (11231).
(Scott Rahin) has the email address (ford@ftrain.com).
(Scott Rahin) has a (Martin Guitar).
[Scott's] (Martin Guitar) is a model (245).
[Scott's] (Martin Guitar) can be seen at (http://ftrain.com/picture/martin.jpg).
[Scott's] (Martin Guitar) costs ($900).
[Scott's] (Martin Guitar) is in condition (Good).
[Scott's] (Martin Guitar) can be described as “Well cared for, and played rarely (sadly!). Beautiful, mellow sound and a spare set of strings. I'll be glad to show it to anyone who wants to stop by, or deliver it anywhere within the NYC area.”
What's important to understand is that the things in parentheses and brackets above are not just words, they're pointers. (Scott Rahin) is a pointer to ftrain.com/people/Scott. (Martin Acoustic Guitar) is a pointer to a URL that in turn refers to a special knowledge database that has other logical statements, like these:
(Martin Guitar) is an (Acoustic Guitar).
(Acoustic Guitar) is a (Guitar).
(Guitar) is an (Instrument).

Which means that if someone searches for guitar, or acoustic guitar, all Martin Guitars can be included in the search. And that means that Scott can simply say he has a Martin, or a Martin guitar, and the computers figure the rest out for him.
Actually, I just lied to you - it doesn't work exactly that way, and there's a lot of trickery with the pointers, and even the verb phrases are pointers, but rather than spout out a few dozen ugly terms like namespaces, URIs, prefixes, serialization, PURLs, and the like, we'll skip that part and just focus on the essential fact: everything on the Semantic Web describes something that has a URL. Or a URI. Or something like that. What that really means is that RDF is data about web data - or metadata. Sometimes RDF describes other RDF. So do you see how you take all those syntactic statements and hope to build a semantic web, one that can figure things out for itself? Combining the statements like that? Do you? Come on now, really? Yeah, well no one does.

So Google connects everyone by spidering RDF and indexing it. Of course, connecting anonymous buyers and sellers isn't enough. There needs to be accountability. Enter the “Web Accountability and Rating Framework.” There were a lot of various frameworks for accountability, but this one was certified, finally, by the World Wide Web Consortium, before the nuclear accident at MIT, and ECMA, and it's now the standard. How does it work? Well:

On Kara Dobbs's site, we find this statement:

[Kara Dobbs] says (Scott Rahin) is (Trustworthy).
On James Drevin's site, we find this statement:
[James Drevin] says (Scott Rahin) is (Trustworthy).
And so forth. Fine - but how do you know how to trust any of these people in the first place? Stay with me:
On Citibank's site:
[Citibank] says (Scott Rahin) is (Trustworthy).
On Mastercard's site:
[Mastercard] says (Scott Rahin) is (Trustworthy).
And inside Google:
[Google Verification Service] says (Scott Rahin) is (Trustworthy).
and if
[Citibank] says (Kara Dobbs, etc) is (Trustworthy).

then you start to see how it can all fit together, and you can actually get a pretty good sense of whether someone is the least bit dishonest or not. Now, this raises a billion problems about accountability and the nature of truth and human behavior and so forth, but we don't have the requisite 30 trillion pages, so just accept that it works for now. And that a lot of other stuff in this ilk is coming down the pike, like:

[The United States Social Security Administration] says (Pete Jefferson) was born in (1992).

Which means that Pete Jefferson can download smutty videos and “adult” video games from the Internet, since he's 19 and has a Social Security number. That's what the Safe Access for Minors bill says should happen, anyway. And don't forget the civil liberty ramifications of statements like these:

[The Sherriff's Department of Dallas, Texas] says (Martin Chalbarinstik) is a (Repeat Sexual Offender).
[The Sherriff's Department of Dallas, Texas] says (Dave Trebuchet) has (Bounced Checks).
[The Green Party, USA] says (Susan Petershaw) is a (Member).

Databases are powerful, and as much as they bring together data, they can intrude on privacy, but rather than giving the author permission to become a frothing mess lamenting the total destruction of our civil liberties at the hand of cruel machines, let's move on.

Anyway, when you think about it, you can see why Google was a natural to put it all together. Google already searched the entire Web. Google already had a distributed framework with thousands of independent machines. Google already looked for the links between pages, the way they fit together, in order to build its index. Google's search engine solved equations with millions of variables. Semantic Web content, in RDF, was just another search problem, another set of equations. The major problem was getting the information in the first place. And figuring out what to do with it. And making a profit from all that work. And keeping it updated....

. . . . .

Google Marketplace Manager

Well, first you need the information. Asking people to simply throw it on a server seemed like chaos - so enter Google Marketplace Manager, a small piece of software for Windows, Unix, and Macintosh (this is before Apple bought Spain and renamed it the Different-thinking Capitalist Republic of Information). The Marketplace Manager, or MM, looked like a regular spreadsheet and allowed you to list information about yourself, what you wanted to sell, what you wanted to buy, and so forth. MM was essentially an “logical statement editor,” disguised as a spreadsheet. People entered their names, addresses, and other relevant information about themselves, then they entered what they were selling, and MM saved RDF-formatted files to the server of their choice - and sent a “ping” to Google which told the search engine to update their index.

When it came out, the MM was a little bit magical. Let's say you wanted to sell a book. You entered “Book” in the category and MM queried the Open Product Taxonomy, then came back and asked you to identify whether it was a hardcover book, softcover, used, new, collectible, and so forth. The Open Product Taxonomy is a structured thesaurus, essentially, of product types, and it's quickly becoming the absolute standard for representing products for sale.

Then you enter an ISBN number from the back of the book, hit return, and the MM automatically fills in the author, copyright, number of pages, and a field for notes - it just queries a server for the RDF, gets it, chews it up, and gives it to you. If you were a small publishing house, you could list your catalog. If you had a first edition Grapes of Wrath you could describe it and give it a lowest acceptable price, and it'd appear in Google Auctions. Most of the smarts in the MM were actually on the server, as Google interpreted what was entered and adapted the spreadsheet around it. If you entered car, it asked for color. If you entered wine, it asked for vintage, vineyard, number of bottles. Then, when someone searched for 1998 Merlot, your bottle was high on the list.

You could also buy advertisements on Google right through the Manager for high-volume or big ticket items, and track how those advertisements were doing; it all updated and refreshed in a nice table. You could see the same data on the Web at any time, but the MM was sweet and fast and optimized. When you bought something, it was listed in your “purchases” column, organized by type of purchase - easy to print out for your accountant, nice for your records.
So, as we've said, Google allowed you to search for buyers and sellers, and then, using a service shamelessly copied from the then-ubiquitous PayPal, handled the transaction for a 1.75% charge. Sure, people could send checks or contact one another and avoid the 1.75%, but for most items that was your best bet - fast and cheap. 1.75% plus advertising and a global reach, and you can count on millions flowing smoothly through your accounts.

Amazon and Ebay - remember them? - doubtless saw the new product and realized they were in a bind. They would have to “cannibalize their own business” in order to go the Google path - give up their databases to the vagaries of the Web. So, in classic big-company style, they hedged their bets and did nothing.

Despite their inaction, before long all manner of competing services popped up, spidering the same data as Google and offering a cheaper transaction rate. But Google had the brand and the trust, and the profits.

It took 2 years for over a million individuals to accept and begin using the new, Semweb-based shopping. During that time, Google had about $300 million in volume - for a net of $4.5 million on transactions. But, just as Ebay and Amazon had once compelled consumers to bring their business to the web, the word-of-mouth began to work its magic. Since it was easy to search for things to buy, and easy to download the MM and get started, the number of people actively looking through Google Marketplace grew to 10 million by 2010.

. . . . .

Google Personal Agent

Now, search is not enough. You need service. You need the computer to help you. So Google also rolled out the Personal Agent - a small piece of software that, in essence, simply queried Google on a regular basis and sent you email when it found what you were looking for on the Semweb.

Want cheap phone rates? Ask the agent. Want to know when Wholand, the Who-based theme park, opens outside of London? Ask the agent. Or when your wife updates her web-based calendar, or when the price of MSFT goes up three bucks, or when stories about Ghanaian politics hit the wire. You could even program it to negotiate for you - if it found a first-edition Paterson in good condition for less than $2000, offer $500 below the asking price and work up from there. It's between you and the seller, anonymously, perhaps even tax-free if you have the right account number, no one takes a cut. Not using it to buy items began to be considered backwards. Just as the regular Google search negotiated the logical propositions of the Semweb, the Personal Agent did the same - it just did it every few minutes, and on its own, according to pre-set rules.

. . . . .

Google Verification Service

Finally, Google realized they could grab a cut on the “Web of Trust” idea by offering their own verification and rating service, $15 a year to answer a questionnaire, have your credit checked, and fill in some bank account information. But people signed up, because Google was the marketplace; the Google seal of approval meant more than the government's.

. . . . .

A Jury of Your Peer-to-Peers

Since all the information was already in RDF format, Google's own strategy came back to bite it. Free clones of Google Marketplace Manager began to appear, and other search engines began to aggregate without the 1.75% cut, trying to find other revenue models. The Peer-to-Peer model, long the favorite of MP3 and OGG traders, came back to include real-time sales data aggregation, spread over hundreds of thousands of volunteer machines - the same model used by Google, but decentralized among individuals. Amazon and Ebay began automatically including RDF-spidered data on their sites, fitting it right in with existing auctions and items for sale, taking whatever cuts they could find or force out of the situation.

In 2011, Citibank introduced Drop Box Accounts for $100/month, then $30, then $15, and $5/month for checking account holders. The Drop Box account is identified by a single number, and can only receive deposits, which can then be transferred into a checking or savings account. They were even URL-addressable, and hosted using the Finance Transfer Protocol. Simply point your browser to account://382882-2838292-29-1939 and enter the amount you want to deposit. There's no risk in giving out a secure drop box number, and no fee for deposits. Banks held the account information of depositors in federally supervised escrow accounts. Suddenly everyone could simply publish their bank account number and sell their goods without any middleman at all.

Feeling the pressure, and concerned, just as the music companies had been ears before, that their lead would slip to the peer-to-peer market, Google dropped its fees to 1%, allowed MM users to use Drop Box accounts, and began to charge $25 a year for the MM software and service for sellers, while still making it free for users. After a nervous few months, Google found that the majority of users who sold more than 10 items per year - the volume users - were glad to buy a working product with a brand name behind it; the peer-to-peer networks were considered less trustworthy, and the connection to Google advertising. Google also realized that they could also offer Drop Box accounts, and tie them to stock and money-market trading accounts, which opened a can of worms that we'll skip over here. If you're interested, you can read The Dragon in the Chicken Coop, by Tom Rawley.

Google's financials can, of course, be automatically inserted into your MM stock ticker; right now they're trading at 25,000 times earnings, heralding news of the “New New New New Economy.” You'll get no such heralding here; while they've pulled it off once, the competition is fierce. Google was the dream company for a little less than the last decade, but they're finally slowing down, and it's high time for a new batch of graduate students too itchy to finish their Ph.D.'s to get on the ball. And I'm sure they will.

. . . . .

A Semantically Terrifying Future?

The cultural future of the Semantic Web is a tricky one. Privacy is a huge concern, but too much privacy is unnerving. Remember those taxonomies? Well, a group of people out of the Cayman Islands came up with a “ghost taxonomy” - a thesaurus that seemed to be a listing of interconnected yacht parts for a specific brand of yacht, but in truth the yacht-building company never existed except on paper - it was a front for a money-laundering organization with ties to arms and drug smuggling. When someone said “rigging” they meant high powered automatic rifles. Sailcloth was cocaine. And an engine was weapons-grade plutonium.

So, you're a small African republic in the midst of a revolution with a megalomaniac leader, an expatriate Russian scientist in your employ, and 6 billion in heroin profits in your bank account, and you need to buy some weapons-grade plutonium. Who does it for you? Google Personal Agent, your web-based pal, ostensibly buying a new engine for your yacht, a little pricey for $18 million, sure. But you're selling aluminum coffeemakers through the Home Products Unlimited (Barbados) Ghost Taxonomy - or nearly pure heroin, you might say - so you'll make up the difference.
Suddenly one of the biggest problems of being a criminal mastermind - finding a seller who won't sell you out - is gone. With so many sellers, you can even bargain. Selling plutonium is as smooth and easy and anonymous (now that you can get Free Republic of Christian Ghana Drop Boxes) as selling that Martin guitar. Couldn't happen? Some people say it can, which explains the Mandatory Metadata Review bill on its way through Congress right now, where all RDF must be referenced to a public taxonomy approved by a special review board. Like the people say, may you live in interesting times. Which people? Look it up on Google.

Acknowledgments: Paul Ford. The original content was inspired by an article that appeared on http://www.ftrain.com

Author: Sastry Dhara
www.dharacg.com

Free with purchase

Sastry — Sat, 15 Mar 2008 00:13:00 GMT

In recent entires on sourcing, we have looked at how sourcing offshore can be successful. But, in considering where to source products and services, we believe it is time to look again at risk. As I was reading the paper this morning, I saw an article in the local paper about the infestation of devices like iPods with viruses. Then when I read my email, my daily feed from MIT Technology Review gave more detail than the paper – (MIT Technology Review). The latest threat of viruses in devices leads to a concern that we all should be aware of. Certainly one of the risks of doing offshore development has always been the protection of Intellectual Property, now it appears that the stability of the development environment is at risk.

This latest threat though is more concerning than IP and piracy. Certainly, it causes anyone to wonder – in a country growing as fast as China or India is, what is the evolution of the control mechanism in place to prevent this infestation of viruses into the environments in which our code is being written in and what is the secondary infection potential for files being sent to us by our “trusted providers”. I spent a lot of time in retail – but I am not interested in “free with purchase” in this case.

I remember an article that I read three years ago in a news magazine. It was when people were first starting to talk about the “China” Cost. The article pointed out two facts that surprised me – more Chinese were being added to the work force every year due to migration to the cities than were in the US work force. That got my attention at the time. The other statistic that I saw was that the span of control of management in China was in the hundreds of people. I wondered at the time – how long can this last? Well, if the trends in the quality of products being produced is any indication – not much longer. As workers begin to get paid more, and their ego grows with that money, the need for supervision increases – not decreases. Is this being done?

It would seem that the whole idea of offshore creation of goods and services is beginning to look a lot like the sub-prime investments. Three years ago they were both great ideas. But how sustainable were either of them? What is the effect of the offshore work product in areas like corporate IT governance? We have always been concerned about copy right violations and the pirating of software, now it appears that there are other concerns as well.

I am not an alarmist – but I have gotten very conservative over time in my approach to business and technology – and as a result we have built our company – as many companies in America are now finally doing - around sustainability. In looking at sourcing solutions, it might be self-serving on our part to ask it – but how sustainable is this notion of offshore development? The dollar is in free fall – maybe we in America should begin to look at developing solutions for “our” offshore.

Fred Geiger
www.dharacg.com

Just in Time

Sastry — Wed, 12 Mar 2008 21:25:00 GMT

Back in 1999, which seems a lot longer to me than 9 years ago, I (Fred) was introduced to a “concept” that was being developed by the Uniform Code Council (now GS1-US) – the organization responsible for the administration of the numbers behind the bar codes (UPC) on the shelves of retailers – called data synchronization.

What if the semantic web concepts been well defined around then?

Back in the day – so to speak – we believed that there were about 10 to 15 attributes about an item that were required to identify an item uniquely. These attributes included dimensions, descriptions and the like. The original working group for the data synchronization effort defined about 60 attributes that would be synchronized between supplier and customer of the product in the supply chain.

Once the larger community, got involved there were hundreds of attributes needed or desired. Many of these attributes – like price – were specific to a trading relationship at a point in time. Many of them – retailer buyer name for instance were specific to the retailer and known only by the salesman calling on the account. In all cases, it was pushed back to the supplier to go find or create all of the data.

What has ensued in the fast moving consumer goods industry has been a very long effort to reach consensus on what items are required for the data synchronization effort to take place. To date, only a fraction of the items in the supply chain have been synchronized using the standardized data synchronization process called GDSN.

This process uses “data pools” and a global registry to send data between supplier and retailer. Despite this process, and all of the time and work spent in developing it, additional attributes are needed by retail systems that are specific to the trading relationship. These are often entered through retailer specific portals or other means. So the all encompassing solution of standardized data synchronization still does not provide a complete source of data for items it he supply chain – until the retail (or channel) specific items are included.

Simplistically GDSN looks like this:

We believe that if the semantic web or the “semantic plane” that we discussed last week (link) had been in place, that the whole process of data provisioning – whether through GDSN or specific point to point communications could have been (and still can be) much easier. While this technology is still being developed, we believe that the time to look at how synchronization of master data can be improved is now.

This semantic plane for the supplier needs to understand the knowledge about the specific requirements for a specific customer and where to find the different pieces of data (attributes) for each request. We like to think of this as Just In Time synchronization or JITS.

JUST IN TIME SYNCHRONIZATION (JITS) CONCEPTS

Just In Time Synchronization (JITS) is a similar concept to GDSN, with a significant difference:

SYNCHRONIZE JUST IN TIME, AND ONLY THE SUB-SET OR SUPER-SET OF DATA THAT NEEDS TO BE SYNCHRONIZED.

By reducing the frequency and amount of data that is synchronized at a given time, the demands on IT infrastructure and the concomitant costs are dramatically reduced. This will drive better industry adoption.

In order to translate this vision into a reality, the existing GDSN Process needs to be reviewed – to reduce the complexity of item definition and to render sub-set updates possible.

Each supplier can implement their own Data Pool at minimal cost and Retailers can connect to Data Pools, by following open technology standards (OASIS, IETF, GS-1).

By dramatically reducing the cost of synchronization and making it easier to understand, the Small to Medium Enterprises (SME) can also participate in the JITS Process.

This JITS concept does not replace GDSN – nor does it require GDSN. It is important to remember that most retailers are not using GDSN and still need master data and need to have it available for “synchronization”. Many retailers only need to synchronize what they buy once because they only buy it once and the attributes are never updated. An example of this is Fashion Retailing, which in many cases is an “in and out” business, and has resisted any efforts in this area because of this fact. A skirt that my wife might buy this year – unless it is a classic timeless line – will be a different color and different style than what she bought last year. Why? Because the skirt she bought last year – or maybe last month – is not made any longer. Computers are the same – as are Digital Cameras – they are updated many times a year, with new capabilities and new specifications. Evergreen data synchronization is simply not needed for these items – simple data harmonization suffices. In a completely dynamic world such as ours, seeking true and complete data synchronization is an exercise in futility. What one should strive at is harmonization of relevant data using Semantic Web technologies.

An industry like fashion is actually a great example of how the semantic plane of knowledge can be used. The fashion buying decision starts with product specifications – those specifications grow in complexity until a product is ordered. Having the knowledge about the supply of items and the costs that could go into it and sharing that efficiently with a global manufacturing base would be much more interesting for the master data process for that industry. Other social networking tools can be used as well to drive to consensus on what can be built and at what price.

We think it is time for individual companies to look at how the processes of sharing master data with their suppliers and customers at all points in the product lifecycle can benefit from the concepts of JITS, Semantic constructs and social networking tools. At Dhara, we are open to using the social networking tools of “Web 2.0” to carry this conversation forward. If you are interested in this as well, please email us at semanticplane@dharacg.info.

Fred Geiger and Sastry Dhara
www.dharacg.com

Mobile Workflow

Sastry — Mon, 10 Mar 2008 11:47:00 GMT

There is an interesting article in today’s Wall Street Journal on breaking down the walls around IT. For us, at Dhara, it makes perfect sense – especially when it is done in the context of the mobile workforce. The article concludes that CIO’s need to make decisions and create implementations on how to allow the knowledge of the business to be available to the business users of the company, and not locked away behind the “glass wall”. This fits into our series that we started last week on the use of tools from the social networking space, and it really fits into our Wednesday series on what we are referring to as a Semantic Plane on top of the data sources of the business.

We will continue to look at social networking tools and Web 2.0 and the Semantic Web as we go forward, but we think that the food for thought from the Journal’s article makes it important to describe our belief on the mobile services that are needed for enabling business systems. It is our hope that this discussion will be valuable to the CIO in making determinations of what and how to implement this type of mobile computing technology.

From my own experience in the position of CIO, I was successful when I was applying new technology to business problems and driving that business advantage into the marketplace. The company that I worked for in the 1990’s was an early adopter of distributed forms to our widely distributed chain of retail stores. Because of the technology that we had in place we were able to deploy new structured forms to the stores and collect information and have it posted to a central database on an overnight basis. Without this technology foresight and implementation, we would not have met the demands of our bank group during a difficult business transition. The survival of the company depended on the ability to remotely collect the cash paid outs by each store and consolidate and report it on an overnight basis. If that request was made today – it would probably be “real-time”.

This technology was “cool” back in the early 90’s and most retailers were years away form adopting it. Today, this forms entry technology has evolved into the underpinning of technology like Adobe AIR and Microsoft Silverlight. And most companies are “years away” from adopting it for the mobile workforce as an entry mechanism for enterprise systems. Last Thursday, Apple announced the 2.0 SDK for the iPhone that will allow much tighter integration into the corporate infrastructure. Will the CIO’s office push this type of technology to enable the wireless workforce to complete information requests and have them seamlessly integrate into existing corporate infrastructure – or will it stonewall it? This push, of course, has to be done before a company gets into a “distressed situation”.

If we go back to the WSJ article – our read of it – is that the CIO should be the person inside of the company that is driving this technology – and others for business advantage.

Today’s CIO is besieged by the economy which is in a tail-spin, as well as rising costs of IT, and the increased need for “compliance”. Typically, when the economy is in recession and unemployment edging higher, one would expect IT resources to be abundantly available and at lower prices. The converse is true in today’s US economy because of a continuing shortage of creative IT professionals.

The most optimal approach for a CIO to take will be to look at all-round efficiencies in IT operations. Considering the fact that a majority of key decision makers are usually mobile and need access to corporate networks while on the move, a mobile access point for corporate business systems is essential.

The mobile phone industry is already pushing software applications onto the phone. Citibank boldly advertises that a cell-phone is all you need to cater to your banking needs. Apple’s iPhone is not far behind in this approach.

Europe and Asia are much farther ahead in the area of mobile computing than USA. This gap needs to be bridged soon.

The advent of 4G technologies is bringing that dream to reality soon. 4G technologies are sometimes referred to by the acronym "MAGIC," which stands for Mobile multimedia, Anytime/any-where, Global mobility support, Integrated wireless and Customized personal service. (for more information on 4G, Click here ).

The day when a cell phone is the only remote computing device any one will ever need, is not to far off.
In order to be not left behind, one should look at technologies like Adobe’s AIR and Micorsoft’s Silverlight. The time to lay down the plans for integration strategies and technology plans is here now.

If you need assistance – or another set of eyes to look at this area in your business, please contact sales@dharacg.com.

Fred Geiger
www.dharacg.com

Knowledegable Master Data

Sastry — Wed, 05 Mar 2008 14:41:00 GMT

We have been discussing master data over the last few weeks and our belief that there are ways to improve the access to the specific data for a specific customer.

In the retail industry, we (the industry in standards efforts) made a very difficult improvement to the use of standardized codes and numbers. People not familiar with the specifics of retail data will still recognize the bar codes that are on products in supermarkets, mass merchants, category killers and department stores – basically everywhere. Getting order and integrity to the use of standardized codes has been a major success story in business history.

Other industries believe that they do not have the need for such specific standardized product identification. Although, last week when I was trying to find a particular type of Matt board to frame some of my photography, I wish that everyone did identify their products this well. It took quite a while to find “very white” board that matched what I was looking for – even though I know it was a specific model number from a specific manufacturer.

And where do I find an eSATA interface card for my Power Mac G5 that is a few years old – what is the specific card that works for the specific drive that I want to attach to my computer? The clerks at the stores that I have been too, have just looked at me and said – “What?”

Regardless of whether standardized codes are used for product identification, we believe that data quality – and customer satisfaction - can be improved if the knowledge about the use of the product is available and machine readable so that the products can be searched and the proper attributes delivered to the customer. Of course machine readable data is also searchable be the staff. I knew the card that I wanted had not shipped as yet; I was just having fun with the store staff of the retailer. The point is he did not have access to the knowledge. If he did, I would buy it form them when available – as it is I will buy it on-line.

Fortunately, there is significant progress being made in the storage and retrieval of knowledge about the products that are in the supply chain. This knowledge, properly stored and retrieved can eliminate much if not - all of the - quality problem that comes up with trying to use data from multiple systems fit it into customers requests for information.

In my Matt board example, the distributor that answered my text based inquiries first got the order – not a big deal it was about $300 – but the last time I looked getting a sale is better than losing a sale. For that industry – one that is “artistic” in nature - human (even text email messaging) interaction is essential. I needed to ask questions of the “knowledge plane” of those companies – the customer service department. In the world of data provisioning, staging and alignment – that request is automated and needs to be packages into to standardized or defined messages.

The technology for the storage of this knowledge about the data is in development and use is under discussion. We believe that it is time to start looking at how a knowledge plane above the relation and distributed data about master data can solve the problem of “dirty data” or incomplete data in the data synchronization efforts in the b2b supply chain.

We like to think of this “knowledge plane” as the semantic plane – and it sits on top of disparate data sources – like price information, ingredient or bill of materials, image, warranty, detailed specifications and the like.

The knowledge about the items is stored in that plane. When a price request by a customer is submitted the information for that customer is created based on knowledge about the programs in place, contracts for that customer, supply of the item, transportation surcharges and anything else specific to the supply chain in use.

When an image is requested the image for the particular version of the product that the customer needs and the use case for the image and the dimension data is fulfilled – so the plan-o-gram image (the small images used for in-store “maps” of the shelf in a Supermarket or Mass Merchant) – represents the product currently being shipped to the customer – not last years image and size data – or next years but the current one. Of course the customer should be able to request either. Also, if a high resolution EPS (Encapsulated Postscript File) is needed for an ad, it needs to be the one for the product that will be found in the supply chain when the ad is running.

Other examples, I am sure come to mind, but I believe that the point is clear. All of this data is in different systems – and usually in different locations. There are different security mechanisms in place for much of the data. But the knowledge of what is the authentic source of information for a particular request is probably distributed around the enterprise in the heads of associates. The semantic plane will store that knowledge and to the degree possible answer the request accurately. When not possible there are other Web 2.0 social networking tools that can alert the person that has to figure out the request and put together the data construct for the customer request. One of these tools – Twitter was discussed on Monday in our Blog.

We believe that concepts like the Semantic Plane and the use of social networking tools inside of the Enterprise can bring about a significant improvement in the quality and accuracy of the data being offered to customers. For more information about this approach please contact us at sales@dharacg.com.

Fred Geiger
www.dharacg.com

Social Networks

Sastry — Mon, 03 Mar 2008 22:13:00 GMT

As part of our CIO focus at Dhara, we like to keep current on trends in the IT Industry. Last year when we began to look at Web 2.0, it was apparent that some of the mash-up techniques had legs inside of the enterprise. In discussion with our stakeholders and contacts in large US companies, it was also apparent that CIO’s were trying to get their hands around the social networking component of “Web 2.0”.

Last week I saw a survey one the plans to deploy social networks inside of the enterprise, and it is apparent that the vast majority of CIO’s are open to this, and that about the same number are concerned about security implications – as soon as I verify that we can link to this survey, I will edit this post and include the link.

So, many believe that it is time for companies to look at the use of the social networking components of the Web 2.0 technology base. We assume that IT people want to determine how they can be used inside of the enterprise to decrease the need for physical travel and increase the contribution of team members to the finished product – which is always important in any systems development lifecycle.

This week we are looking at one of those tools – and the potential impact to the CIO’s office. The tool is Twitter (http://www.twitter.com) which is a tool that allows messages to be routed to a cell phone or sms client. While the product’s stated intention is to keep track of people using a “publish – subscribe” model, the ramifications for business use are great – which means that your users and probably some of your staff has been using it already.

Basically a user searches for his or her buddies and subscribes to information that they post and these subscriptions can be filtered. This type of model ahs been used for business applications like data synchronization for close to ten years now. But the use of it using chat clients and cell phones and allowing individual users to set it up should be looked at from a corporate risk perspective if it has not already been done. How many messages are being sent to your cell phones now? And at what cost? Do you have a policy regarding its use?

An interesting application though offers potential for use as an alerting mechanism. On Tech TV last week, a Twitter user talked about the use of Twitter to route messages to him from his plant telling him that it needed watered – and the plant was even polite enough to thank him for doing so. So putting a monitoring mechanism on his plat that is Internet enabled and creating alerts is a cool idea – one that had me thinking about monitoring my home and sending me messages to that I could subscribe to in a variety of form factors. It also made me remember how many different alerting mechanisms we had in the last environment that I had to manage and how much the infrastructure cost.

At Dhara, we are looking at the infrastructure used by Twitter and will report back on how we are able to apply this technology safely in our environment as we go forward. In the meantime, if you would like to discuss projects like these, please feel free to email us at sales@dharacg.com

Fred Geiger
www.dharacg.com style="font-family: Verdana;">

Sourcing Pitfalls

Sastry — Fri, 29 Feb 2008 14:00:00 GMT

Last week in my Blog entry on sourcing, I gave a success story. This week I want to focus on some of the pitfalls of development off shore. No, this is not a failure story, but it expands on the explanation of some of the areas that are barriers that have to be overcome or avoided.

It is tempting to focus on the cost of development and look at the hourly wage of the resource. When you compare twenty dollars and hour or less to numbers four to five times that number, it is easy to set expectations for savings that are unrealistic. One of the consistent temptations for technologists is what Chairman Alan Greenspan of the Federal Reserve referred to as “irrational exuberance”. The times that I have gotten into trouble in my career are the times that I believed my own hype and oversold the benefits of a proposed project or direction. Kind of like the economy did back at the turn of this century when the bubble burst.

In many companies in America, change happens at a very fast pace. We, in America, pride ourselves on our flexibility. I remember my frustration thirty years ago trying to mange development projects in the then common “waterfall” methodology. For those of you that learned about the sixties and seventies in textbooks – or on the History Channel, the waterfall methodology was one in which projects progressed sequentially until they finished by “falling over the waterfall”. It was aptly named – often times it was like going over the falls in a barrel because the requirements changed over the lifecycle of the project. And they were discovered at implementation. It turns out that the requirements that were signed off on in the first phase of the project – the requirements phase – changed in the months (or years) that it took to get the product complete and installed.

Today, it is often easier to develop systems using a variety of iterative construction techniques – but these are best applied when the project team is very close to the users. In the fast pace change of America, it is common for systems to be changed significantly during the development effort – especially if the methodology supports rapid prototyping and extensive user reviews.

Implementing these techniques with facilities that are half way around the world and in which language and culture are different can produce business systems that do not meet the real user need – because that need was lost in nuance. We in America understand our culture – we understand that the newspaper headline of “Bucs bomb birds” during football season indicates a good day for the Tampa Bay Buccaneers (aka “Bucs”) and a bad day for Philadelphia Eagles (aka “Birds”). Of course if the World Series was going on and however unlikely it would seem right now, the Pittsburgh Pirates beat the Baltimore Orioles – what was the real story – football – or baseball? You have to understand the nuance of the comment and the context of it.

We in America, understand the nuance of the way that we communicate, people not familiar with our culture do not. They do not. Even here in the states, it is not uncommon for a new analyst or programmer to not understand jargon – I remember a new analyst in my own career in technology who did not understand what a PO (purchase Order) was and was afraid to ask. Here the answer was provided after the meeting and the requirements were captured. How does that happen off shore?

Well, it can happen, but it has to be planned for. We used a daily call to make sure that all questions are answered. Often times that meant that we had to create and answer the question. In America we are “in your face” people. Other cultures want to save face, and not look foolish. I learned that yes does not mean yes. In some cultures it means that the person understands – not that they agree. In other cultures – it can mean that they do not want to argue – they might not even understand. For an excellent primer on cultural differences the book Kiss Bow or Shake Hands by Terri Morrison and Wayne A. Conaway helped me greatly.

So in addition to making sure that we were clear in requirements, we avoided areas that were fuzzy. We created those components in the states where people were closer and could interact with the users of the products or services.

In order to put together a project team to support this type of project we found that we needed two teams in Asia of five to ten people, a full time manger in the states who worked across the two Asia teams and provided direction and issue resolution and a team in the States to define requirements, and test criteria as well as perform the integration testing and implementation. I would recommend that your on-shore team also fully understand the technology that has been developed so that critical issues can be fixed – especially during Asia holidays and weekends that do not map to our own. When a problem arises – make sure you have an answer to “who are ya goin call?”

All of this points to an interesting realization – if you do not have a large project – the cost benefit of going off-shore is not really realizable – perhaps savings can be had by engaging a company that provides local support in an affordable fashion. Next week we will look more closely at trends in this area.

Fred Geiger
www.dharacg.com

Master Data Lifecycle

Sastry — Wed, 27 Feb 2008 22:43:00 GMT

One of the challenges in preparing master data requests that are issues by customers is the notion of the “lifecycle” of the product sold to the customer. This is particularly true in mass merchant and supermarket retail where an item is sold in the stores to consumers and is always “stocked” in the same section of the store, or at least it is supposed to be in stock when you go to look for it. Out of stock conditions drive everyone in the supply chain crazy.

Products change from time to time; for example, formulas change. High fructose corn syrup used to be “good, but now many people believe it is bad; out with the sugar and in with the corn syrup; and out with the corn syrup, in with the next new thing. So, when master data includes ingredients and images, the information for the product in the stores and the retail distribution system is different from the information for the products in the supplier’s warehouse. Thus, the information about new shipments is different from the information about old shipments, which causes some orders sent to or from multiple distribution systems to change.

In other cases, the country of origin (also with master data, often times) changes which can cause differences in the product formula, as with fabric content, for example, in fashion items. So as an item’s sourcing moves from Mexico to China, or from Ohio to China, there are differences in master data.

Regardless of where the” knowledge” about this is stored, someone, somewhere, in the organization of the supplier “knows” when this is happening. Unfortunately, “systems” in place, built perhaps when China was never considered for sourcing items, do not have this knowledge. So when a customer asks for “synchronized” data, or when a customer makes an information request for a radio frequency identification (RFID) tag, sourcing the correct information is often times problematic.

At Dhara, we have been working in this space (master data staging) for ten years, and as we have reported in this blog, we believe that mashing up the various sources of data for the fulfillment of the information requests is essential. We believe that discovering and storing knowledge about the requested data is an essential step in the proper fulfillment of the information request.

When we talk about knowledge, what are we talking about? Well, some examples might help. What warehouse is used for each customer request? What warehouse is used for backfilling requests that cannot be handled by the prime warehouse? Who sources each warehouse? When a sourcing is changing, how is it staged and whose orders are affected? What is the schedule for the change of formula in the product? What lots are affected, and who is getting those lots? Does an order for a customer span lots?

This is not just about the fulfillment of information about business-to-business requests. This information should be available for business to consumer requests. My spouse and I have used the Internet for much of our shopping for some time now. In buying things that are fashionable, it would be very helpful for us to know that a pair of jeans that one of us bought is being sourced in the same place the next time we go to buy them. There seems to be something “unstandard” about sizes between different sources of products. The consumer might not know to ask, but she realizes that there is a difference when the next pair of the “same” jeans does not fit as well as the last pair. In this case, the knowledge of where the last order was sourced from, and information about the fulfillment from the same source for the next one, is really needed by the operating system’s supplier–the consumer should not have to know that.

There is new technology for storing this knowledge inside of computer systems, and next week I plan to look at the use of a semantic plane inside of the supplier’s systems, which processes source information requests for master data.

Fred Geiger
www.dharacg.com

A Balanced Approach

Sastry — Mon, 25 Feb 2008 16:04:00 GMT

Today I want to discuss a balanced approach to senior IT engagements, which are usually with the CIO. Most small firms that offer services only offer them to the principal in the firm as the lead, who is usually the founder. Most large firms manage the engagement at a senior level, but fairly inexperienced people do the actual work. In choosing a service provider to look at a strategic situation, or when doing an audit of a critical problem, it is very important to go outside of the comfort zone of your “vendor list” and choose a partner that can get the job done—someone who tells you the factual truth and resists pandering you.

Some experiences that I have had from my own background clarify my point here. I once engaged someone from a small firm to be a long-term advisor to me when I was new in my CIO position. This person was generally very good, although the person did charge me for the same stories over and over again. The person was very good at conducting requirements specification sessions, and she could handle an eight-hour session without taking notes. In fact, she could recite most of what she heard in the sessions and then create a fairly accurate requirements specification (back in the waterfall methodology days—lots of paper). Since many people edited and reviewed the document, we had a 90% document accuracy rate, which was a great first step. Employing her services in this way was beneficial.

She was not, however, a retail operations guru, and one member of our senior management team asked her to review some store operations procedures. She called me at home (pre-cell phone era) and reported that she uncovered a major problem that she needed to act on immediately—we had a gun control problem. Well, we did not have guns and we did not sell guns, but this very intelligent person believed she had uncovered a major problem that she had to act on at midnight. I told her the store folks were talking about pricing guns, which today would be hand-held wireless terminals for pricing. Store employees use these to put price tags on merchandise. She, however, insisted that I was wrong, and that she was going to take this major problem forward. I told her it might support her credibility with the staff if she went back to the source and got the facts straight. She did, and she continued to look brilliant to our senior team.

Another example focuses on architectural review. If you ask pure software architects to review the architecture of a system, they are going to come back to you with a component review. In the process, they point out the inefficient way that the code components are built and the standards that are applied, and those that are not. But if you have business architects do the same review with the same instructions, you get a review of the interfaces between the systems, including interface deficiencies, and the like. Often times you need both.

I have seen return codes in a multi-tier system that were not properly trapped in a record update process cause a 0.1% failure rate on record updates. The business architect would have missed this problem because it was inside the component in the last application that processed the record. The software gave back a return code, but it was an inaccurate one. The system’s integration test passed the system because the error code was “forced” into the test bed using dummy data—in other words, it was not a full integration test, and the provider of the defective component was not part of the implementation effort. This is a common shortcut because of the use of multiple providers of software components. There is simply no substitute for a full integration test that accurately simulates all potential failures.

Having been in the industry for thirty years, I could go on and on about such things as relative files that lost their pointer for six records and returned the wrong record; memory leaks in Java virtual machines that, at one release of the operating system, caused major slowdowns; and comments from a major systems implementation vendor like, “I am not sure why he fired us. This is the first time we did not have to back it out of production.”

My point is, select your high level service providers wisely. Make sure that they have the experience needed to do quality work for you. Make sure, too, that they tell you what you need to hear, and not what you might want to hear. If the vendors in your Rolodex, or on your “list”, are unable to offer you quality and honesty, then you need to find people who can.

Having worked on both ‘sides’, first as a CIO, and then as a service provider (software and services) in the IT Industry, I have a perspective that affects the way that we, at Dhara, offer high-level assistance to a firm’s CIO. In our company, we also have the experience of working in many environments. One of our other principals has extensive experience in architecture and engineering, another has experience in marketing and executive management, and as I have indicated, I have extensive senior IT management and product development expertise. We only do SmartCIO engagements when they can be lead by one of these people, assisted by the others, as needed. For more information about our services, go to http://www.dharacg.com , or email us at sales@dharacg.com.

Fred Geiger
www.dharacg.com

Sourcing

Sastry — Fri, 22 Feb 2008 17:26:00 GMT

At Dhara, we focus on three primary areas of service to our customers. These service areas include Strategic Support for the CIO, the implementation of new technology to improve the business, and general sourcing for projects. In my blogs each week I want to dedicate at least one entry to each of the above areas. On Fridays I plan to discuss sourcing issues and opportunities.

I am a firm believer that in order to speak about trends, or issues, it is critical to have actually operated in the space. In my long IT career, I have managed development areas that included out-sourced providers at the project level, the enterprise level, and as staff extensions to fill in the missing resource needs for our core resources. My typical span of control for technology development, support, and operations has usually been in the fifty-to-two hundred associate range. This will give you—the reader—an understanding of my bias when reviewing my Blog entries.

As an outsourced service provider, we of course believe in the wisdom of outsourcing. As a business, we believe in win-win sustainable solutions to problems when we create partnerships with our stakeholders.

Much has been written about the value of offshore development facilities. One area that I have managed that has produced extremely good value is that of prototype development for new product concepts. Assuming that you have control of your offshore facility’s intellectual property from an ownership and risk management perspective, the development of new tools and technologies can be very effectively done.

In my own experience, we developed concepts of products in the States, with a very high degree of rigor. This rigorous approach allowed our offshore engineers and architects to develop component specifications that our onshore team reviewed and approved. It allowed software construction to be done in a rapid development methodology that allowed our onshore staff resources to review components as they were being constructed. We were able to specify changes that needed to be made and see the results quickly.

To manage the process we utilized a “follow the sun” development approach. This allowed work to be completed overnight by us in the States and during the day in our facilities in the Pacific Rim. It required a hand-offs policy at the end of our day and the beginning of the Asian day, and it was very effective for us.

One of the biggest benefits for us is that it isolated our mainline staff to develop “test” concepts. One of the things that every large development organization tries to do is to isolate mainline business support from things that might never happen. In this way people do not fight to protect their turf when they think that their jobs might be threatened. So, instead of creating "skunk works", projects done in semi-secret mode and not impacted by existing systems or thinking, here in the States, we simply were able to isolate the effort off shore. Skunk works were named for the secret nature of the effort—in my experience they usually ended up creating more of a skunk like smell, rather than any tangible results. By clearly defining the offshore work as a prototype development, we were able to limit the distraction to our mainline staff. By developing the prototypes with rigorous design and building components, we were able to deliver working modules that were potentially reusable in the future for development of the actual products.

These projects were successful because of the design and management rigor that was employed. They would have been unsuccessful if we had simply created a high level concept in U.S. English in a three-page overview and had said, “Buy us one of these”. The cultural and language differences would have been a disaster. If you have not been to a third world or emerging economy culture, it is impossible to understand the environment in which people are working.

Over the years I have been to the Pacific Rim on numerous occasions, but I had never been to India until last year. I had seen a number of pictures of Bangalore and had read about it being the “Silicon Valley” of India. As I got off of the plane in Bangalore, I realized that I had seen the ‘demo’ version of Bangalore, and that the reality of that city was far closer to that of Manila than to San Jose. It was also the most peaceful I had ever felt in the world—probably because I felt genuinely welcomed there.

My point is simple, the cultures and languages in Asia were different from those in the U.S. We were successful in our development because we took these differences out of the equation by eliminating colloquialisms from our language and expectations from our minds.

I remember being in Paris a few years ago, and the limo driver asked me if I was American. I hesitantly answered, “Yes.” He said that, for an American, I spoke awfully good English. I realized then that, to be successful in any offshore endeavor, those traveling overseas need to have excellent English language communication skills.

In the coming weeks I will discuss other sourcing issues, based on my experienced point of view. I will also explore new trends that can be applied to make sure that the promise of lower costs and higher quality is realized in your sourcing efforts.

Fred Geiger
www.dharacg.com

Master Data

Sastry — Wed, 20 Feb 2008 15:52:00 GMT

At Dhara, we have been involved with “master data” initiatives and storage mechanisms for over eight years. We think that the master data problem can be solved once and for all with new technologies.

My personal involvement with master data began thirty years ago, although I had never heard of the term “master data” until years later. Back in the early eighties, I was working in the supermarket IT services industry, and we were trying to arrive at a unit price for the items in a shipper, which is a floor display stand heavily used for seasonal items like cookies, make-up, suntan lotion, toys, and spices. The problem was that the shipper’s price was tied to the retail value of one of the items. Consequently, if all of the retail items totaled $299.99, then one of the items sharing the same product bar code would be assigned a price of $299.99, instead of its correct price of $1.99. This occurred because the common practice at the time was for one of the items in the shipper to have a bar code with the same number that was on the external carton .

Twenty years later, an industry initiative for data synchronization was charted so that problems like that could be solved elegantly. It sounded very simple. It was not. We discovered that an item’s data components could change based on the geography of the shipping point; the retailer or distributor to which items were being shipped; and in the case of multi-national products, the geography of the source item(s) and the shipping route to the destination. As a result, massive amounts of money were invested in trying to solve the problem of data integrity.

In all of the other industries, like the high-tech ones, in which I worked, the problems were similar. In addition, the inclusion of more points of distribution added complexity to the situation because third parties often did the final assembly of the products, and different third parties might handle multiple combinations of separate components before the final item was sold to the ultimate consumer.

At Dhara, we are looking at applying the technology of the semantic plane to the problem of master data provisioning. Each Wednesday, over the coming weeks, we are going to be exploring this topic in our Blog. But for now we wish to convey the idea that the rules for obtaining information about a customer’s data must be dynamic and this knowledge base must be maintained by factoring in elements such as the quantities purchased, the available supply, and the context of use. Other factors, such as the availability of promotional programs, time, geography, and transportation costs should also be described in a knowledge base that can be queried.

In the 80s, being able to differentiate between a shipper versus a consumer selling unit would have provided the information necessary to determine the price. Unfortunately, the technology to accomplish that did not exist at the time. Since then we have had to create kludges and a whole new system of numbering standards in order to “solve” a simple problem.

If your organization still has a master data problem, and you would like to discuss it with us, please see our website at dharacg.com, or contact us by email at info@dharacg.com

Fred Geiger

www.dharacg.com

Semantic Web and Air Travel

Sastry Dhara — Wed, 14 Nov 2007 04:06:00 GMT

semantic web and predictable air travel

Imagine a scenario where you are preparing to make travel plans, for business or pleasure. If you had a crystal ball and could predict the probability of arriving at a destination on time, you could manage your time much better than you do now. Unfortunately, that is not the case today, despite the tremendous advances made in weather predictions, traffic delays at airports and road congestions due to construction etc.,

Put in simple words, such a scenario would represent a better world where an event takes place just-in-time, just-as-predicted and just-about-right

However, humanity has now at its finger-tips the tools to predict, to a high degree of accuracy, the natural disasters and weather patterns. We have several disparate tools to predict events. However, we do not yet have a composite tool to put it all together.

Consider, for example, the question posed by this curious user about lack of mash-ups for Air Traffic delays:

http://paul.kedrosky.com/archives/2007/10/03/air_traffic_mas.html

Orbitz has made a note-worthy collaborative effort to provide such a mash-up, which relies on user updates. See below:

http://updates.orbitz.com/

Absent reliable user updates, however, this tool lacks the predictability and reliability.

The following weather mash-up sites provide information about weather across several geographies:

http://www.accuweather.com/maps-satellite.asp?partner=accuweather&traveler=0&site=CO_&type=ei&anim=1&large=0

http://www.weatherbonk.com/weather/summary.jsp?where=usa&_id=&_className=weathermaps.weather.user.WeatherRequest

What is missing is a mash-up or tool that provides semantics to all these inanimate data sets. For example, a web-site that accepts a user’s question:

"I am traveling to Bentonville, AR on 11/27/2007, leaving from Cincinnati, OH at 13:00 hours, flying non-stop using General Aviation facilities in my Cessna Citation. What are my chances of arriving at my destination by 17:00 hours?"

We have the current technology to answer the above question in a more or less accurate manner. However, we do not yet have the ability to analyze the question, interrogate various mash-up tools to gather answers to sub-sets of the question and stitch it all together.

This is where we transition from inanimate Web 2.0 mash-ups to intelligent systems that give semantic meaning to the data provided by such mash-ups.

Given the finite nature of relevant questions in any particular domain, air traffic and travel in this case, it is possible to parse the questions into sub-sets and get answers to those questions using existing tools (mash-up) and mash together the results of those mash-ups.

Take for example. OWL Specification from W3C:

http://www.w3.org/2004/OWL/

and comments on how OWL is relevant:

http://www.xfront.com/why-use-owl.html

The example above describes how the computer can arrive at a logical conclusion that is not explicitly stated in the data presented to it. Similar conclusions can be drawn on predictability of air travel using disparate sets of data relating to weather, traffic delays and airport information.

That day is not too far off.

Sastry Dhara

www.dharacg.com

Financial Mash-up

Sastry — Thu, 27 Sep 2007 21:07:00 GMT

Like most folks that start a blog, I thought – gee – this is pretty cool, I can talk all about a particular topic – like mash-ups in retail and enterprise systems, and really dive deeply into it.

After a few weeks if that, it became – so now what. So now, that I have figured out what – here it is. We are going to expand this blog to include entries from others. The first author that I am adding is Sastry Dhara the founder of Dhara Consulting Group Link. In this entry Sastry speaks about Mash-ups in financial services.

Thanks to Sastry for this entry.

Fred Geiger

FINANCIAL SERVICES MASH-UP APPLICATION

A leading Private Equity firm, which managed to remain surprisingly sparse in implementing the Web technologies, recently had a new CIO in charge of IT operations. The new CIO was grappling with an existing culture, which was eerily similar to the early 1990s, when the emergence of Web technologies was viewed with skepticism and amusement.

The company’s web-site was built ten years ago and no changes were made since then. They continue to rely heavily on mainframe processing of transactions. None of the bridge-technologies such as exposing CICS transactions as Web Services or executing CICS transactions through message queues is implemented. In addition, there are approximately 25 business divisions within the company, each having its own P&L and utilizing approximately 250 reports daily from 50 different data sources. None of the data that comes form the 50 data sources daily is persisted, which automatically eliminates any possibility of data warehousing. Some of the reports provide data regarding the same CUSIP or ticker symbol. No one person in the Company has a comprehensive idea about all the data feeds and their usage. The Company continues to stay profitable because of their well established business units and practices. However, unnoticed by them, they are losing the competitive edge in the market because they are not assimilating and interpreting data at near-real-time speeds, something their competition probably does.

A solution to this predicament? Enter Web 2.0 Mashups!

The first step will be to persist the data as it comes from the data source as a daily feed, either onto a file-system or into a database. The second step will be to analyze the common attributes between various data sources and identify them as such. There is no need to have a complex database schema with primary-key and foreign-key relationships. The final step will be to build a mash-up application, linking various data sources together, into a single Web Application (Create Read Update Delete – CRUD). With this simple Web Application, the entire Company is rendered cognizant of the multitude of data feeds and their correspondence to one another. The Company enters into the Web-20 world and bridges the gap with its competition.

The new CIO is smiling again!

Sastry Dhara

Small and Medium Enterprises and the mash-up

Sastry — Wed, 22 Aug 2007 00:10:00 GMT

Over the last two weeks, we have been engaged in the sales process with a number of small and medium enterprises. It is striking how common the need for "mash-ups" of different data sources is in companies of this size in the market.

Often times, it is the small companies that have not invested in large scale infrastructures that can best leverage new and emerging technology. I had the privilege of working in a new company in the 1980's and we had no systems in place other than manula systems becasue we only had a few stores. As we grew, we were able to leverage first the Personal Computer and then Unix based in store processors over a distributed network, years before other companies were able to do so.

It seems that small and emerging companies have both an opportunity and the means to easily leverage the power of Web 2.0 technologies in the application of technology to business problems.

What are some areas the today's small and medium emerging companies can utilize web 2.0? We will be looking at these areas in the weeks to come form time to time. If you have an idea please comment.

Fred Geiger Dhara Consulting Group Website

Apple Announcement

Sastry — Wed, 08 Aug 2007 22:58:00 GMT

As we reach the middle of the week - and the northeast swelters, we continue looking at examples on the web of potential mash-up ideas and trends. While our focus is on Enterprise mash-ups - Apple has created quite a stir over the last few weeks - first at the developers conference in June with the notion of Web Widgets that could be created on the dashboard of OS-X Leopard when it ships in October, and now by offering those same Web Widgets for use in iWeb.

For a detailed view into Widgets look at Steve Jobs Apple WWDC video WWDC link here - widgets are part of the dashboard feature towards the end of the Leopard feature review.

It is worth looking at the Apple product announcements - because these announcements will increase the creation of both the underlying web widget services and the creation of more and more complex and useful mash-ups - created by virtually anyone. This is bound to increase the tools and understanding for the use of this technology much the same way as he use of HTML back in the 1990's and email earlier in the 90's influences the deployment of new corporate infrastructure - see last Monday's blog.

The Web 2.0 Apple experience begins with the improvements to the Apple .Mac on-line service. These improvements create a collaborative environment for photo and movie sharing around the theme of events - like a little league game in which all of the parents contribute their photos into a community mash-up. The same could occur in a semi-private environment of a family reunion in which all members of the family share their photos and they are mashed into one gallery.

There are very interesting improvements to the iMovie and iPhoto products to help deal with this new power - but they are outside of our scope - they are fun to consider though - check them out.

The improvement dead smack in the middle of mash-ups is in the iWeb product - which allows an ever increasing number of website evergreen feeds to be put into browser window. This technology could go along way to creating the home mash-up idea in last Friday's blog entry. These feeds can be cliped into iWeb and displayed in mash-up form. And it can be posted on-line to a website or to .Mac.

Fred

Enterprise Mashups

Sastry — Tue, 07 Aug 2007 14:33:00 GMT

As we continue this week with interesting mash-up related information and examples on the Internet, today we look to Business Week and its excellent series on technology from the CEO's perspective. When I listened to this podcast last fall, I was struck with how important the use of Web 2.0 concepts inside of the Enterprise.

The series is updated monthly and can be subscribed to as a podcast. The Enterprise Mashup edition can be found here - Business Week link - and if you go there you will see a number of related topics including use of the Semantic web, Corporate Wiki's and the Virtual Workplace. We will be discussing all of these in this blog in the months to come.

Fred

Interesting Site

Sastry — Mon, 06 Aug 2007 21:37:00 GMT

Today's post will be short and sweet. This week, we are going to look at some sites on the Internet that present interesting uses of Web 2.0 technology. These sites - IMHO - are done in a way that could be applied to the Enterprise. I will leave it to our growing readers to fill in how - since the purpose of this blog is to discuss how Web 2.0 can be used by companies inside of the Enterprise - or to present information to customers via portals and other technologies that combines Enterprise data with other information in a "mash-up fashion".

Today's site is www.redfin.com - a Multi-list real estate mash-up. There are other sites like this out there but this one - I think- merits a look.

Fred

Home - Personal Mash-up

Sastry — Fri, 03 Aug 2007 21:13:00 GMT

Sort of like the Wall Street Journal, as we are heading to the weekend, I believe it is good to step away form the business world and look at our personal worlds. This week, we have been discussing mash-ups in the retail business world. Many home computer users – especially Generation Y users have become interested in Web 2.0 communities. The latest craze to hit this new space is on-line financial communities. Users can post their information on-line, much like many of us have done with Quicken or Microsoft Money – but now they can have their friends see their spending patterns and comment on them.

Many of us that have more assets then we might feel comfortable sharing with others (or less). Or maybe it is just a generational thing. However, we use Web 1.0 tools (our browser) to log into a number of different financial services accounts and audit the information in them. We might automate this to a degree with our financial management software.

Many people have also “automate their homes and created or are creating smart homes with integrated energy management systems, security, and lighting and home entertainment systems. These same people often times travel extensively and want remote access. What if we had a mash-up tool that allowed us to customize access to the things that we need the most – access to our financial information, access to our home systems and perhaps access to things like our children’s use of the Internet, or their location - if they are very young.

Our dashboard would present our world – the state of the home(s) systems, our financial state, our children’s activities to the degree that we need to monitor them – or our children’s (college-age) financial balances. This information would be available to our cell phone, a laptop, our office computer or from our primary home systems. We could designate agents to act for us in one consolidated place from one interface. This interface would have vice recognition so that we could set the thermostat to 50 degrees for the next week, or record Desperate Housewives tonight even though we never watch it, but something struck us in the morning paper about a guest star that is on it that we want to watch. The most interesting application or me – would be – did I turn off the gas on the stove before I left – kind of like – “Hello ON-Star….”