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

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   

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

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

 

 

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

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

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

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

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

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….”