Take a look at this and tell me what you think.

There are two options with different benefits that I have used.  One is to build a actual file format that holds your canonical data.  Another is to use a database to act as your canonical.  Both of these have trade offs.

File based Canonical:

To make a canonical file format you will need to pick the type of file that you want all of your applications to be receiving either directly or through an adapter of some kind.  Building from scratch a flat file or XML file is the most flexible, but requires you to do a bunch of planning.  And after it is done, this format must be maintained.

Using a file based canonical does allow you a fairly easy way to find the state of a failed step, as you can look at the file and identify what is wrong.  You can also correct the data there and allow the process to continue.  You can also make copies of these files for your monitoring so that tracking your data and transactions becomes easy, and you performance metrics become rich with data.

Database based Canonical:

Sometimes people, DBAs especially, get excited when we talk about doing this.  They are visualizing one massive Canonical Database that holds all of the transactions and is accessed by all of the applications.  And there are many products that work this way internally.  But this is not the only approach.

The one database to rule all canonical, or as I like to call it “Lord of the Databases”, requires a DBA to pay attention to optimizing, backing up, and all of the other care and feeding tasks that go along with having a database that you maintain for the long haul.  This is efficient in that you can get all of your performance data from one place, and monitoring is one connection.  However, some times applications have limitations in how they talk to a database that is not theirs, and this can make implementation complex.

Another way to use a Database based Canonical model is to use disposable databases.  In the Disposable Database implementation, you create a database that is small, only contains the structures and tables for the one transaction, and gets destroyed at the end of the transaction life cycle.  Using the Disposable Database, you don’t ever have to optimize them, back them up, or any of the other care and feeding tasks that are part of the LOTDB implementation.

Comparative implementations:

I want to examine and compair the File vs DB canonical implementations in more detail in another article.  If you have another Canonical implementation that I haven’t seen, please let me know.  I would love to examine that as well.

Leo answers a question from Charlie about what makes a software company successful.  Leo responds and explains that it is taking good ideas, and incorporating them in software.  He then goes on to explain that industry leaders like SAP are made by specializing in one line of business.  Companies that only have Enterprise software as one of their business lines will never achieve the same level of expertise.

This is an interesting perspective.  I wonder how someone from IBM or Microsoft would respond.

I also enjoyed the comments by Andrew Mcafee of the Technology and Operations Management Unit at Harvard Business School.  My favourite quote of his from this when responding to Charlie’s assertion that Google had an insurmountable lead over other search engines was.  “I don’t think the people at Google would say there was ever an insurmountable lead.”

Both Andrew and Leo agreed in that the software industry was in flux with a ever present struggle to stay in the lead, or to catch the leaders.  And that keeping people with expertise and knowledge engaged was key to maintaining success.

Thanks to Randy McClure of mcislog for pointing me to this  interview.

This is about a 23 minute video.  It was worth the watch.  Take a look and let me know what other insights you see into SAP and or the supply chain software vending industry from these remarks.

RFID is exciting technology for integration engineers.  All of this data coming in will have to be aggregated and integrated by someone.  Also, one of the focuses of integration is to provide more and better information to people and systems.  With more and better information people, businesses and systems can make better choices and decisions.

This is a good thing.

People talk about privacy issues and consumer protection.  I am sure that debate will continue to rage on long after the keyboard and mouse you are using have RFID tags embedded.  But the focus of this blog is how these technologies can be used for the collection and integration of information.  Implementing RFID technologies provides a hugely beneficial and accurate stream of data.

Whether we are integrating the data gathered from RFID tracking, or using the techniques in our tracking of data transactions, the benefit is the same; A more robust, and flexible set of data and better issue resolution work flow.

I was particularly impressed with Sanjay’s comments around the challenges of phantom inventory caused by missed reads of RFID tags.  Sanjay mentions that this could be mitigated by using multiple read points.

This is similar to techniques that I have built in the past, but without putting a name to them.  Building a BPM process that expected some of the metric points to be lost, and to be able to fill them in when subsequent point are met allows for a more flexible and rapid system.

This is a bit long, at 42 minutes, but is still interesting.  He spends most of his time using retail based examples, but the concepts are equally applicable to all areas of RFID inventory control, and supply chain managment.

Professor Mansour Javidan, Ph.D talks about supply chain considerations using blue jeans as a case study.  This clip is 3 minutes long.

Professor Javidan gives an amusing illustration of some of the challenges that can occur in supply chain integration.  9 different countries, currencies, cultures to get Blue Jeans to your store.  Each of these will have orders and payments that flow between companies, and across boarders.

This is where having a reliable standard of communication can create greater efficiencies in the supply chain system.   It also illustrates why documenting your supply chain is essential for stability and finding and solving supply chain problems.

So this may not really be news to experienced supply chain integrators, but it is an interesting case study matterial.