“We are working with EPC, but less with RFID, due to cost per unit”, is what a friend replied when I asked about his RFID program. The decision was made with more than a million dollars invested to explore RFID for the purpose of item-level track and trace, and especially for purpose of preventing counterfeit product from entering the distribution chain. Based on careful analysis, even with a paramount need to prevent counterfeiting, his plan is “EPC yes, RFID no”. They will use EPC for unique item-level identification, but for the foreseeable future, the EPCs won’t be affixed to products via an RFID tag.
After much anticipation about employing the perfect marriage of EPC and RFID, the conclusion to forego RFID is on one hand, a disappointment. Even my friend’s company, with significant resources to plan and execute for large-scale and long-term, couldn’t make the business case work for item-level tagging. It’s disappointing at first, but on the other hand, deferring to business case over emotional attachment to technology deserves much respect.
When the business case doesn’t make sense, it’s best to call off the deployment early and avoid the more painful reality of bad economics later in the deployment. Moving ahead when the business case doesn’t make sense only results in high-visibility, costly failures. Failure to heed a bad business case will trigger a “gun shy” attitude and undermine support for future RFID deployments, even when they do make business sense. Failure to heed a bad business case will also present an unwarranted warning to others that will bias their intuition against RFID projects.
Asset tracking with RFID can pay highly-respectable returns. Pallet tagging, case tagging, and a wide range of other RFID applications can pay highly-respectable returns. In spite of my friend’s company deciding against it, item level tagging can, whether today or in the future, also pay respectable returns. Over time, as the technology continues to mature, as the advantages of scale economics increase, as infrastructure and knowledge develop, more applications will pay more handsome returns. The key to achieving those returns is understanding when and where to invest.
It’s true that one-size-fits-all does not apply to RFID and EPC solutions. Each type of need should be addressed individually. It’s also true that one-size-fits-all does not apply to RFID and EPC business cases. The business case for each situation needs to be considered individually. There’s no valor in forging ahead with a deployment that doesn’t make business sense, and then later encountering the harsh reality of economics. It’s better to do careful business analysis and invest accordingly. It’s better to get a solid business case, one way or the other, and heed the business case decide.
Sunday, May 16, 2010
Sunday, May 9, 2010
EPC Changing the World in Three Arenas
Yes, [RFID and] EPC technologies will fundamentally change the world. Only time will reveal the specifics, but success in three EPC investment arenas will influence the future. In one arena, investments are made with the interest of individual enterprises as a primary consideration. In a second arena, investments are made to serve an industry by using a shared infrastructure. In a third arena, investments are made to provide uniform services to the global public.
There will be many payoffs, and some losses, in each of the three EPC investment arenas. The payoffs will accelerate to the extent investments in the three arenas are coordinated. Ken Traub is shaping and galvanizing standards (e.g., EPCIS) that will facilitate that coordination. Nobody has a crystal ball, but Ken has his finger on the pulse of EPC adoption. Ken and I spoke recently about the state of world-wide EPC adoption and this blog post is partly a reflection on my conversation with Ken.
Although complex by any measure, the first arena of enterprise-focused activity is an easier problem to define. Customer-premises-based or private-cloud solutions are a natural response to these enterprise-focused problems. IBM, SAP, and Axway, among others, are leveraging strategic competencies and making investments with emphasis in this first arena.
Relatively-speaking, it’s easier to define and respond to enterprise-oriented problems, but industry orientation provides the opportunity for additional benefits. Hosted and software-as-a-service solutions provide advantages for industry oriented solutions via neutral-party-information-sharing, shared cost of capital, and easier-to-manage risk profiles. TraceTracker’s GTNet and FSE’s GDSN pool provide examples of investment in this second arena in concert with the food and beverage community.
The third arena, uniform services for the public, envisions a day when the need to exchange information about RFID tags and EPCs is common and routine. In anticipation of this common need, an open-loop, general-purpose, publicly-accessible service is appropriate. VeriSign shares this vision and is committed to providing Object Naming Service (ONS) to connect interested parties with information about individual EPCs.
The players mentioned as examples above and many others are managing investments and dependencies in the three arenas. To enable and re-enforce their efforts, standards for EPCIS, EPC Discovery, GDSN, and ONS hold the promise for additional returns via increased interoperability among investments. Those leading the charge in the three arenas and those dedicated to standards are setting the stage that will change global productivity and fundamentally change the world.
There will be many payoffs, and some losses, in each of the three EPC investment arenas. The payoffs will accelerate to the extent investments in the three arenas are coordinated. Ken Traub is shaping and galvanizing standards (e.g., EPCIS) that will facilitate that coordination. Nobody has a crystal ball, but Ken has his finger on the pulse of EPC adoption. Ken and I spoke recently about the state of world-wide EPC adoption and this blog post is partly a reflection on my conversation with Ken.
Although complex by any measure, the first arena of enterprise-focused activity is an easier problem to define. Customer-premises-based or private-cloud solutions are a natural response to these enterprise-focused problems. IBM, SAP, and Axway, among others, are leveraging strategic competencies and making investments with emphasis in this first arena.
Relatively-speaking, it’s easier to define and respond to enterprise-oriented problems, but industry orientation provides the opportunity for additional benefits. Hosted and software-as-a-service solutions provide advantages for industry oriented solutions via neutral-party-information-sharing, shared cost of capital, and easier-to-manage risk profiles. TraceTracker’s GTNet and FSE’s GDSN pool provide examples of investment in this second arena in concert with the food and beverage community.
The third arena, uniform services for the public, envisions a day when the need to exchange information about RFID tags and EPCs is common and routine. In anticipation of this common need, an open-loop, general-purpose, publicly-accessible service is appropriate. VeriSign shares this vision and is committed to providing Object Naming Service (ONS) to connect interested parties with information about individual EPCs.
The players mentioned as examples above and many others are managing investments and dependencies in the three arenas. To enable and re-enforce their efforts, standards for EPCIS, EPC Discovery, GDSN, and ONS hold the promise for additional returns via increased interoperability among investments. Those leading the charge in the three arenas and those dedicated to standards are setting the stage that will change global productivity and fundamentally change the world.
Labels:
Electronic Product Code,
EPC,
EPCIS,
Malcolm Bliss,
Malcolm D Bliss,
RFID
Sunday, May 2, 2010
How are the RFID and EPC Adoption Models Different than Adoption Models for Other Products?
This week, RFID Journal will host a webinar featuring Geoffrey Moore. I was first introduced to Geoffrey by Jeff Miller at Documentum. Geoffrey has written landmark books on how new technologies are adopted, including Crossing the Chasm and Inside the Tornado. I look forward to catching up with Geoffrey's latest ideas applied to RFID on the webinar.
In anticipation of the webinar, I formed up some questions that I hope Geoffrey will speak to. Technology adoption models presented in "Crossing the Chasm" and "Inside the Tornado" are mainstream ideas for tangible products, software, and services. Some products provide most or all of their value through "network effects". Network effects occur when the return to an individual or single organization is dependent on the adoption decisions of others. My questions center around the notion that different adoption models apply when network effects contribute a large share of a technology's value:
- How do you see network effects impacting RFID adoption?
- To what extent is adoption of EPCIS, ONS, GDSN, and EPC Discovery governed by network effects?
- How is the adoption model for network-effect technologies different, and how should those differences be managed in the case of RIFD, EPC, and related technologies?
I’ll report back in this space with more related to the webinar with Geoffrey and on the questions above.
In anticipation of the webinar, I formed up some questions that I hope Geoffrey will speak to. Technology adoption models presented in "Crossing the Chasm" and "Inside the Tornado" are mainstream ideas for tangible products, software, and services. Some products provide most or all of their value through "network effects". Network effects occur when the return to an individual or single organization is dependent on the adoption decisions of others. My questions center around the notion that different adoption models apply when network effects contribute a large share of a technology's value:
- How do you see network effects impacting RFID adoption?
- To what extent is adoption of EPCIS, ONS, GDSN, and EPC Discovery governed by network effects?
- How is the adoption model for network-effect technologies different, and how should those differences be managed in the case of RIFD, EPC, and related technologies?
I’ll report back in this space with more related to the webinar with Geoffrey and on the questions above.
Sunday, May 24, 2009
Ending the Tyranny of False Network Connectivity Assumptions
You can’t always connect to a network. Some have done better with that reality than others.
Microsoft desktop software assumes the user is connected to the network. I’ve been on a 100% travel schedule for years at a time, so the assumption of full-time network connection seems outlandishly wishful. I’ve found Outlook particularly offensive in this regard. After years of trying to get used to it, I still want to return to Lotus Notes Mail, which was designed with a traveler like me in mind.
Verizon’s VZAccess Manager and AT&T’s Communication Manager have provided good data network connections for the significant amounts of time between hotel rooms and offices. Airlines such as AirTran now offer connections while in flight. The only problem is that the assumptions about connectivity require more bandwidth than these services generally deliver.
I don’t hold it against developers who build assumptions into their software based on a future expectation of infrastructure. I understand that as much as I do travel, many others do most of their work from an office with a lot of reliable bandwidth. At the same time, there is a large and growing community of mobile people like me who have been forced to improvise and scramble to use software designed with us as an afterthought.
There is new hope that the tyranny of false network connectivity assumptions may come to an end. It comes from “desktop” and social networking applications accessed via mobile devices such as Blackberry and iPhone.
I wanted to see Matt Coblentz’s presentation of CenterStage Mobile Client at EMC World last week, but schedule conflicts prevented it. I saw Matt in the corridor later and he showed me something more convincing. He demonstrated on the spot that he is already using CenterStage Mobile Client with his Blackberry Bold. I am not a bleeding edge technology adapter. Relative to others in the industry, I am a laggard, but not this time. I’ve seen CenterStage Mobile Client in action. It’s a real productivity enhancer. It will work with my existing Blackberry, and I want it.
That answers one of the questions posed in last week’s post, and here are the others:
Q: Does CenterStage provide the end user functionality that users and businesses will readily adopt?
A: This is highly addictive functionality. Once users get their hands on it, they won’t want to let it go.
Q: Does CenterStage fully deliver the back end capabilities of Documentum Content Server?
A: In theory yes, CenterStage delivers the backend functionality. It’s a good bet that this theory will be proven in fact, because all CenterStage content is being stored in CenterStage.
Q: Does CenterStage have the flexibility to allow enterprises to centralize or decentralize administrative responsibilities? To the extent administrative responsibilities are decentralized, does CenterStage allow safeguards to keep departmental administrators within bounds of enterprise policies?
A: CenterStage is looking good in this regard. Initial deployments will prove it out, but this seems like another low risk bet.
Q: Does CenterStage have an advantage in accelerating mobile computing applications?
A: This is the real surprise behind CenterStage. I didn’t think this question was going to have the most exciting answer, but it does. If you’re a mobile professional you can see an end to the tyranny of false assumptions about connectivity.
Microsoft desktop software assumes the user is connected to the network. I’ve been on a 100% travel schedule for years at a time, so the assumption of full-time network connection seems outlandishly wishful. I’ve found Outlook particularly offensive in this regard. After years of trying to get used to it, I still want to return to Lotus Notes Mail, which was designed with a traveler like me in mind.
Verizon’s VZAccess Manager and AT&T’s Communication Manager have provided good data network connections for the significant amounts of time between hotel rooms and offices. Airlines such as AirTran now offer connections while in flight. The only problem is that the assumptions about connectivity require more bandwidth than these services generally deliver.
I don’t hold it against developers who build assumptions into their software based on a future expectation of infrastructure. I understand that as much as I do travel, many others do most of their work from an office with a lot of reliable bandwidth. At the same time, there is a large and growing community of mobile people like me who have been forced to improvise and scramble to use software designed with us as an afterthought.
There is new hope that the tyranny of false network connectivity assumptions may come to an end. It comes from “desktop” and social networking applications accessed via mobile devices such as Blackberry and iPhone.
I wanted to see Matt Coblentz’s presentation of CenterStage Mobile Client at EMC World last week, but schedule conflicts prevented it. I saw Matt in the corridor later and he showed me something more convincing. He demonstrated on the spot that he is already using CenterStage Mobile Client with his Blackberry Bold. I am not a bleeding edge technology adapter. Relative to others in the industry, I am a laggard, but not this time. I’ve seen CenterStage Mobile Client in action. It’s a real productivity enhancer. It will work with my existing Blackberry, and I want it.
That answers one of the questions posed in last week’s post, and here are the others:
Q: Does CenterStage provide the end user functionality that users and businesses will readily adopt?
A: This is highly addictive functionality. Once users get their hands on it, they won’t want to let it go.
Q: Does CenterStage fully deliver the back end capabilities of Documentum Content Server?
A: In theory yes, CenterStage delivers the backend functionality. It’s a good bet that this theory will be proven in fact, because all CenterStage content is being stored in CenterStage.
Q: Does CenterStage have the flexibility to allow enterprises to centralize or decentralize administrative responsibilities? To the extent administrative responsibilities are decentralized, does CenterStage allow safeguards to keep departmental administrators within bounds of enterprise policies?
A: CenterStage is looking good in this regard. Initial deployments will prove it out, but this seems like another low risk bet.
Q: Does CenterStage have an advantage in accelerating mobile computing applications?
A: This is the real surprise behind CenterStage. I didn’t think this question was going to have the most exciting answer, but it does. If you’re a mobile professional you can see an end to the tyranny of false assumptions about connectivity.
Sunday, May 17, 2009
The Dawn of New Age of Collaboration?
Ever since there have been departmental systems, Collaboration has been departmentally focused. eRoom, Lotus Notes, and SharePoint owe their success to end user functionality on the one hand, but also to departmental deployment and control models that support viral adoption across the enterprise on the other hand. Given the trends of enterprise consolidation and cloud computing, the time may have come for the pendulum to swing back to a centralized model for collaboration software. (Remember collaboration before Lotus Notes?)
The pendulum should not swing to complete centralization of responsibility and costs. Rather there should be a shift that lets responsibility and cost lie where it is most effective. In such a shift, enterprise policies would be controlled centrally. Work structures would be defined and implemented in decentralized fashion, for greatest responsiveness to the demands of work on the front lines. Each business would fine tune the balance of what is centralized and what is decentralized according to its own needs.
Consolidation within enterprises and cloud computing are driving the infrastructure for centralized computing, but what about application software for centrally deployed collaboration? EMC Documentum CenterStage targets this space. More will be revealed about CenterStage this week at EMC World 2009 and we’ll all be better able to gauge the alignment of the trends toward centralized infrastructure with the centralized control model of CenterStage.
Here are a few things to look for:
The pendulum should not swing to complete centralization of responsibility and costs. Rather there should be a shift that lets responsibility and cost lie where it is most effective. In such a shift, enterprise policies would be controlled centrally. Work structures would be defined and implemented in decentralized fashion, for greatest responsiveness to the demands of work on the front lines. Each business would fine tune the balance of what is centralized and what is decentralized according to its own needs.
Consolidation within enterprises and cloud computing are driving the infrastructure for centralized computing, but what about application software for centrally deployed collaboration? EMC Documentum CenterStage targets this space. More will be revealed about CenterStage this week at EMC World 2009 and we’ll all be better able to gauge the alignment of the trends toward centralized infrastructure with the centralized control model of CenterStage.
Here are a few things to look for:
- Does CenterStage provide the end user functionality that users and businesses will readily adopt?
- Does CenterStage fully deliver the back end capabilities of Documentum Content Server?
- Does CenterStage have the flexibility to allow enterprises to centralize or decentralize administrative responsibilities?
- To the extent administrative responsibilities are decentralized, does CenterStage allow safeguards to keep departmental administrators within bounds of enterprise policies?
- Does CenterStage have an advantage in accelerating mobile computing applications?
Labels:
CenterStage,
collaboration,
Crown,
Crown Partners,
Malcolm Bliss,
Malcolm D Bliss,
Web 2.0
Sunday, May 10, 2009
They are both Right about Web 2.0. Now Get a Backbone in Place.
“Web 2.0 is the business revolution in the computer industry caused by the move to the Internet as a platform, and an attempt to understand the rules for success on that new platform”, says Tim O’Reilly. “I think Web 2.0 is of course a piece of jargon, nobody even knows what it means.”, says Tim Berners-Lee, “It’s dookie.” They are both right, but it doesn’t matter.
Whether you agree with O’Reilly or Berners-Lee, information technology organizations must deal with the adoption of social-networking, video-sharing, wikis, blogs, and user tagging. Because people use them and businesses demand them, the infrastructure has to control and support Web 2.0 applications.
Public Web 2.0 facilities can achieve inter-company benefits, but those public facilities don’t meet the large organization’s need for control or support in the areas of retention, access, security, availability, and cost. In those large organizations, rogue Web 2.0 islands have likely sprung up internally and increasing adoption has caused unplanned cost and risk. Public facilities and rogue islands were fine when Web 2.0 applications were an experiment, but for many companies, enterprise-caliber infrastructure is now required.
Enterprise Content Management (ECM) technology is a promising backbone for Web 2.0 applications. The appeal of ECM is first in the fit and maturity of the technology. ECM is designed to manage unstructured information such as addressed by Web 2.0 applications and has been proven at enterprise scale for over a decade. The appeal of ECM is also in the potential to leverage existing investments. Most large companies have existing ECM platform investments that can provide needed support and control to Web 2.0 applications.
EMC Documentum Content Server (Documentum) is playing the role of backbone for Web 2.0 applications via two different approaches. First, Documentum has traditionally played a repository role for custom-built or niche front-end applications. Documentum plays a similar back end role when used in conjunction with Web 2.0 solutions built using Crown SiteBuilder and Crown Web Gear products. In the second approach, EMC has built on it’s eRoom heritage of providing application front-ends, and EMC is now extending eRoom solidly into the Web 2.0 era with its CenterStage product.
If you have enterprise-scale Web 2.0 needs, Crown can help you evaluate your options and put the appropriate infrastructure in place. Ask us about our SiteBuilder and Web Gear products and about our experience with EMC CenterStage.
Whether you agree with O’Reilly or Berners-Lee, information technology organizations must deal with the adoption of social-networking, video-sharing, wikis, blogs, and user tagging. Because people use them and businesses demand them, the infrastructure has to control and support Web 2.0 applications.
Public Web 2.0 facilities can achieve inter-company benefits, but those public facilities don’t meet the large organization’s need for control or support in the areas of retention, access, security, availability, and cost. In those large organizations, rogue Web 2.0 islands have likely sprung up internally and increasing adoption has caused unplanned cost and risk. Public facilities and rogue islands were fine when Web 2.0 applications were an experiment, but for many companies, enterprise-caliber infrastructure is now required.
Enterprise Content Management (ECM) technology is a promising backbone for Web 2.0 applications. The appeal of ECM is first in the fit and maturity of the technology. ECM is designed to manage unstructured information such as addressed by Web 2.0 applications and has been proven at enterprise scale for over a decade. The appeal of ECM is also in the potential to leverage existing investments. Most large companies have existing ECM platform investments that can provide needed support and control to Web 2.0 applications.
EMC Documentum Content Server (Documentum) is playing the role of backbone for Web 2.0 applications via two different approaches. First, Documentum has traditionally played a repository role for custom-built or niche front-end applications. Documentum plays a similar back end role when used in conjunction with Web 2.0 solutions built using Crown SiteBuilder and Crown Web Gear products. In the second approach, EMC has built on it’s eRoom heritage of providing application front-ends, and EMC is now extending eRoom solidly into the Web 2.0 era with its CenterStage product.
If you have enterprise-scale Web 2.0 needs, Crown can help you evaluate your options and put the appropriate infrastructure in place. Ask us about our SiteBuilder and Web Gear products and about our experience with EMC CenterStage.
Labels:
CenterStage,
Crown,
Documentum,
ECM,
EMC,
enterprise content management,
eRoom,
Malcolm Bliss,
Malcolm D Bliss,
Web 2.0
Sunday, May 3, 2009
Heterogeneous ETL Platform Capability as a Content Consolidation Enabler
Extract Transform and Load (ETL) operations can be homogeneous or heterogeneous. Homogeneous operations involve extract from a repository and load into a repository of the same technology. As an example, one can synchronize the content in a North American Documentum repository with the content in a European Documentum repository via a homogeneous extract and load (i.e., from Documentum and to Documentum). Two or more technologies are involved in a heterogeneous operation. As an example, one can migrate from FileNet to Documentum, by extracting from FileNet and loading into Documentum.
The challenge with content consolidation is that there are several, if not numerous, repository technologies to be addressed. For example, if content in SharePoint, FileNet, Lotus Notes, and ApplicationXtender are content sources to be consolidated into a Documentum target infrastructure, then extract must be performed on four different technologies and load into one technology. Each of the technologies involved implies a need for knowledge of the technology, technical infrastructure (e.g., test environment), and existing functionality to connect to each repository technology. A heterogeneous ETL platform capability addresses each of these needs:
The challenge with content consolidation is that there are several, if not numerous, repository technologies to be addressed. For example, if content in SharePoint, FileNet, Lotus Notes, and ApplicationXtender are content sources to be consolidated into a Documentum target infrastructure, then extract must be performed on four different technologies and load into one technology. Each of the technologies involved implies a need for knowledge of the technology, technical infrastructure (e.g., test environment), and existing functionality to connect to each repository technology. A heterogeneous ETL platform capability addresses each of these needs:
- Knowledge of each technology is required to inform consolidation strategy from an enterprise taxonomy point of view. Knowing each source technology is required to understand how the content in each source will map to a taxonomy for the enterprise. Knowledge of each source technology is also important for consolidation efficiency. Consolidation efficiency can be improved by best leveraging technical capabilities in the source, such as indexes and application programming interfaces.
- Technical infrastructure (for the several or numerous technologies involved) to test and execute consolidations can be costly and time consuming to establish, but is required for an effective consolidation program. In most consolidation programs, the technical infrastructure is required for a finite period of time, and obtaining required infrastructure via outsourcing is an economically attractive idea. Aside from traditional outsourcing or hosting, large consolidation programs can also leverage infrastructure of solution providers or software vendors.
- Constructing extract connections to each source repository technology is the most technically risky portion of a consolidation effort. Using pre-existing extract connections for the source repositories or proven models for constructing them greatly reduces the risk.
Subscribe to:
Posts (Atom)
