“Who do you trust?” Hubba, hubba, hubba…what can cloud do for you in trusted supply chains?

Trust in Supply Chain Management – Threats beyond the US Department of Defense

I know it has been quite awhile since the first Batman movie where Jack Nicholson starred as The Joker. However, I cannot help but think of Nicholson’s Joker when I think about Trusted Supply Chains when he said, “…And now, folks, it’s time for “Who do you trust!” Hubba, hubba, hubba! Money, money, money! Who do you trust? Me? I’m giving away free money. And where is the Batman? HE’S AT HOME WASHING HIS TIGHTS! “

My first take on the topic of supply chains is that it must be an abysmally dry topic, particularly in the context of the “white hot” world of cloud computing. At least that is what I believed until this week. With late notice last week, I had the distinct pleasure as an invited panelist at the inaugural Critical Technologies Conference that was held this week at NAVSEA in Crane, IN.  The panel was about the threat to national security from DIS-trusted supply chains infiltrating their way into DoD platforms of all types. The conference was held in a quaint and picturesque setting at NAVSEA’s Crane Division in southern Indiana at the base’s club house situated on Lake Greenwood. Trust me when I tell you that I wasn’t the only attendee that was happy to have had the conference shuttle from Bloomington!

While the conference was limited to about one hundred attendees, the presentations and information were more than simply intriguing to the selective gallery of onlookers. The content was sobering and in some ways startling. While the focus of the conference was on interests for the US Department of Defense (DoD), the epiphany that hit me square between the eyes is the very nasty impact that globalization is reeking on the supply chains of legitimate commercial interests. In this blog, I want to talk about Trusted Supply Chains and the positive impact that cloud computing architectures can have on what should be considered the lifeblood of a product, it’s supply chain.

I’m an electrical engineer by training, not an industrial engineer, so I haven’t given a great deal of thought into the subject of supply chains until my MBA days. That’s the funny thing about MBA training for engineers, it actually forces you get your head out of the calculus book and think about why you need calculus anyway. But back to the subject matter at hand. I’ve blogged ad nauseam about Christensen’s Value Chain Evolution (VCE) Theory. I’m afraid I have to do so again, because it is precisely VCE Theory that is responsible for the disaggregation in complex supply chains.

The interesting thing about VCE Theory in supply chain disaggregation is that it seems impervious to the granularity of the inflection point. It doesn’t seem to matter whether the inflection point in the supply chain is outsourcing diesel locomotive engines, steel factories, a few cleverly connected transistors on an integrated circuit, or a few lines of software code in a middleware module. The one thing that is discriminatory in VCE-affected supply chains is the “digital content ratio” exhibited by the supply chain. The more the supply chain is driven by information content that is inherently digital, the faster the absorption rate of VCE inflection points and the more subject the supply chain is to disaggregation.

Disaggregated supply chains can have very positive effects on extracting cost efficiencies in products. As with any pro, there is a con, and in this case the cost efficiency comes at the price of TRUST! Why do I think of the opening quote by The Joker? Because as a systems integrator when it comes to Supply Chain Risk Management (SCRM), who are you going to trust while saving money in assembling products? “…hubba, hubba, hubba! Money, money, money! Who do you trust?” These two issues, trust and money, go hand in hand in disaggregated supply chains.

“Hell isn’t merely paved with good intentions, it is walled and roofed with them” Aldous Huxley

Engineers, Supply Chains, Business Capital, Free Markets, and Good Intentions

I am no advocate for commercial isolationism, nor am I a proponent for a global free trade zone. However, we must be willing to take a candid look at the reality of industrial and commercial policies with enough open mindedness to step back when we see those policies start backfiring. With that said, I am also a dog lover, and dogs do the darnedest things, almost always with an intent to please their masters. The same great intentions can be aspired to the creators of disaggregated, VCE-shaped supply chains. However, just as our furry friend in the illustration shows, past habits that we learned that have previously pleased our masters, may now end up with unexpected and sometimes undesirable results!

The evolution of the disaggregated inflection points in a supply chain occur because there is no longer a differentiated advantage to maintaining that point in the supply chain vertically within the company. The value of outsourcing the service or part has become “good enough” and can be competitively sought after on the open market. The operative words “good enough” and “open market” impose a Supply Chain Management (SCM) responsibility on the consumption side of the supply chain, and the following questions must be considered:

1. Is the outsource service truly “good enough”, i.e. will using the outsourced version of the component degrade the overall quality of the final product and ultimately the company’s reputation?
   • How will we maintain an ongoing quality control program in collaboration with the supplier?
2. Does the supplier operate a sustainable business model?
   • Will they be in business as long as I need them to be?
   • Do we have acceptable alternative supply sources in our contingency plans?
3. Is the supplier “trusted”?
   • Is the supplier honest, reputable?
   • What indemnification rights protect our company from transacting with this supplier?
   • Are the parts/service that I am receiving counterfeit?
   • Is the supplier operating under nefarious auspices?
4. What about the distribution channels of the supplier?
   • What international tariffs or laws must be considered to integrate the supplier into our manufacturing processes?
   • How can we implement Just-In-Time manufacturing process efficiencies?

“Executive Decisions”…unexpected consequences from honest intentions…

Hard choices always start at the top

The electronics and software supply chains are characterized through high digital content ratios. These two supply chains are also very synergistic and have complex, interrelated dependencies. We are now observing practices in foreign markets that have degraded the integrity and trust of the electronics and software supply chains. The first and foremost practice is a market of counterfeit electronic parts. The second is digital content Intellectual Property (IP) theft that once compromised and disseminated, the control and recovery of that IP is effectively lost forever.

At the Critical Technologies Conference, the Supply Chain panel featured Tom Sharpe, CEO from SMT Corporation. SMT Corporation specializes in trusted electronics supply chain management. What I learned from Mr. Sharpe’s presentation is that knowing that counterfeit electronics exist and understanding the magnitude and prevalence of the problem are entirely two different things. A comment from Mr. Sharpe that strikes at the heart of the problem was this, “I guarantee you that if you have more than a few consumer electronics products in your home, there are counterfeit parts in one of those products!”

To most of us that statement does not translate into a serious threat, until one of the products that has been compromised with counterfeit electronics fails, malfunctions, or worse creates a hazard. In most cases, the product seems to work fine, but the unseen crime at work takes money out of the rightful pockets of the original manufacturers. Crime! Did I say crime! Yes, I did. When we examine the counterfeit electronics supply chain, what we find is that it is not all that hidden from view. In fact, we know a great deal about every step of the process. Most noteworthy is the cultural mindset that those engaged in the counterfeit electronics market do not associate any criminality in the activity, but in many respects see their market as a “green initiative” in recycling what is considered waste products.

The RnD cost that goes into designing, qualifying, testing, and supporting electronic components is staggering. Specification of the dozens of parameters for a specific component that are characterized by the component’s packaging labels are negated when counterfeiters re-mark the component with a higher performance designation. The situation becomes even more egregious when completely different components that have the same physical package are mislabeled. The fraudulent device is inserted into the product. The product test fails, gets ejected in manufacturing to a quality assurance line, and the counterfeit manufacturing cycle begins anew.

The situation becomes much more arduous when the malfeasance penetrates the silicon die in terms of digital content controlled intellectual property. This process of compromise in a trusted supply chain can be likened to an organ transplant and never knowing or finding the transplant recipient. In electronic component design & manufacturing, digital IP references the actual functional specification of a particular capability the component exhibits or delivers. That IP will undergo a series of content transformations that lead to a final manufacturing description. At each transformation stage the IP is in a human or machine readable digital format that if stolen or compromised can be used to complete the manufacturing process.

The problem becomes intractable once the IP is removed from its intended application or component and transferred into a completely different component architecture. The stolen IP simply becomes another functional element of a black box system that is practically impossible to detect, akin to someone disappearing into a large crowd of people. The IP, along with the component that is now contaminated with stolen IP, becomes part of the landscape of a black market supply chain. While not identical in process, in context, the problem of theft and compromise of software IP may be easier to execute, but just as hard to recover from after the theft has occurred.

Tony Bent, Business Operations Director for National Semiconductor’s trusted foundry operations represented on the same Supply Chain panel, talked about the additional supply chain controls that National is manufacturing into their components to make it easier to detect counterfeit components earlier in the supply chain cycle. Tony also mentioned the brazenness exhibited by counterfeiters. He discussed situations in which National engineers have received calls from overseas persons who ask why certain transistors are part of a particular circuit, clearly with an aim at replicating the silicon die for counterfeiting. The fact that the counterfeiting party has no reservation about contacting the original manufacturer borders on obscene!

Adding the “Trusted” cloud computing component into a disaggregated supply chain!

The issue of IT intellectual property rights, security, privacy, and protection is without dispute or question the single highest calling and priority for cloud computing service providers! There can be no effort minimized, no corners taken, no expense incurred in fulfilling this mission statement for a cloud computing service providers. Simply stated, without total IT intellectual property control and security, a cloud computing service provider does not have a service to sell.

Information control and management is a crucial component in SCM. While the information content associated with SCM is not in a strict sense technical or engineering intellectual property controlled through patents and copyrights, it is valuable to the company’s operations and must be considered a form of intellectual property and treated with appropriate security concerns. When a supply chain is vertically integrated within a single organization or company, control and management of SCM data is a simpler task. Disaggregate and distribute that SCM database across dozens of independent, international ongoing concerns, and SCM data management flies out the window. If the information flow across a supply chain could be likened to the glue that holds the flow of components across the supply chain, then SECURE, COLLABORATIVE information flow across that supply chain could be considered SUPER GLUE for the flow of components.

I suspect by now that you’ve probably surmised where I am going this with this…enter the disruptive world of collaborative cloud computing enterprise architectures. I personally love the application of a disruptive technology that solves a VCE-driven disruption.

True disruptions always look funny at first glance and often end up as mainstream solutions.

For most companies, the transition to a cloud architecture in itself is scary enough, much less a public cloud. Therefore, the initial focus of my comments here will be on “community cloud computing” architectures, i.e. a collaborative, demand-based, multi-tenant, utility computing model designed to serve the interests of a specific community of users. The concepts stated here are just as applicable to public clouds. The key concept to retain from the previous statement is that the multi-tenancy is the critical component in a community cloud service that binds collaboration with disaggregation.

Now let’s apply the vision a supply chain workflow implemented as a secure, collaborative, cloud computing enterprise architecture.

Identity Profiles – Trust component for Cloud-based Supply Chain Management

“Identity in the Age of Cloud Computing”, J.D. Lasica, Communications and Society Program

“Technology enables companies to build and tear apart alliances and partnerships on an as-needed basis. Product decisions are becoming less dependent upon a fixed list of suppliers than on the range of suppliers available. Relationships come together based on a particular product or project and then disband at the end.”

“The beginnings of this move toward specialization is already on display in certain global supply chains, where workers in disparate venues focus on one aspect of the manufacturing process. For instance, eighteen companies were involved in developing and manufacturing the first Apple iPod.”

“Improved global coordination allows companies that have found unique ways to deliver products in certain markets to go global with those advantages.”

More to come…

Cloud-based Intellectual Property Rights – Part 2 – Applying “aspects” to a DRaaS design pattern…

The proliferation of the Internet and subsequent Web services exposed a heretofore unseen level of software and hardware security exposures that engineers had previously considered unimportant or even irrelevant. Over the past 10 years, the technical community has produced an enormous amount of research and development into Web services security architectures. Cloud computing services & application development through IaaS, SaaS, PaaS, & WFaaS services has introduced yet another level of system variable integration through concepts such as multi-tenancy, application mash-ups, and data security. Developers now have to begin addressing another level of security architectures in cloud design patterns.  In this blog, I want to spend some time talking about security “aspects” that can be applied to a specific cloud computing pattern, Digital-Rights-as-a-Service (DRaaS).

I’ll introduce the use of a UML profile that will illustrate the application of defining a security “aspect” to a single component of a DRaaS design pattern XML schema.

First, from a high level, let’s review the concept of Aspect-Oriented-Programming (AOP).  The software engineering community has long come to grips with the theory and application of Object-Oriented-Programming (OOP) as a staple methodology practice for application development.  While modularity was a foundation of OOP, as applications became more complex and more ubiquitous, code modularity came at a price of code replication across object classes where common methods or functionality needed to be implemented.  In a response to reducing the code replication, developers would create references and exploit polymorphism across objects. While the code was still modular in nature, the system’s overall common functional code became “scattered” across the application’s class hierarchy, which in turn had a direct effect on the system code’s maintainability.  It became apparent that something more was needed to address OOP code scattering across object hierarchies with common functional methods.  This is time when definitions for crosscutting concerns, aspects, advices, join points, and point cuts entered the genre of advanced OOP, i.e. AOP.  I’ll leave the deep dive tutorial on AOP to the reader.

Security parameters are “cross-cutting concerns”, that is, similar security parameters affect multiple objects within the object hierarchy. Such security cross-cutting concerns must be implemented as “aspects”. However, the operative questions that arise are as follows:

1. If we use an XML Schema as a base for a DRaaS, can we apply the use of aspects to our advantage in the context of a DRaaS XML XSLT?
2. In Web services, information exchange is defined through secure XML documents.  How can digital rights be expressed in aspects for XML?
3. Can XML aspects be carried in both a static and dynamic security model for intellectual property?
4. Can we define a XML aspect methodology that can reverse engineer and track security breaches for cloud-based DRaaS services?

Reference material:

1. “HyperAdapt: Enabling Aspects for XML”, M. Miederhausen, S. Karol, U. Assman, K. Meissner
2. “A model-based aspect-oriented framework for building intrusion-aware software systems”, Z. Zhu, M. Zulkernine, Information and Software Technology, Vol 51, 2009
3. “Automated analysis of security-design models”, D. Basin, M. Clavel, J. Doser, M. Egea, Information and Software Technology, Vol 51, 2009



Aspect insertion in XML Documents

More to come…looking at this as a major chapter in an upcoming book proposal on “Meta-applications in Cloud Computing…”

DRaaS – Part 1 – Indirect network effects of cloud-based IP licensing and distribution…

This blog entry will opine on the following topics and questions…

• What are indirect network effects as defined in the context of collaborative, cloud-computing IT systems?
• Cloud computing enterprise architectures (IaaS, PaaS, SaaS) are creating a host of new valuation points in complex supply chains…
  • Collaboration-centric IT enterprise architectures create such indirect network effects.
  • One crystallization of IaaS/PaaS/SaaS design patterns is WorkFlow-as-a-Service (WFaaS).
• WorkFlow-as-a-Service (WFaaS) & Digital-Rights-as-a-Service (DRaaS) are two integrally related, highly interdependent cloud services design patterns…

An MBA view of network effects

I want to first frame the impact of Intellectual Property (IP) in light of my expertise in semiconductor System-on-Chip (SoC) design methodology (Please refer to my blog entry on the supply chain evolution of the semiconductor industry to gain a greater insight into delivery of IP into the supply chain of semiconductor supply chain). I will then generalize the discussion of indirect network effects for IP in orthogonal supply chains.

Indirect Network Effects

“In markets with indirect network effects, the value of any component does not depend directly on the number of other users of that component (hence the terminology), but rather on the availability of complementary and compatible components. For example, a PC is more valuable as the set of available software for that PC grows.”

(The Handbook of Technology and Innovation Management, Wiley-Blackwell, 7/14/2009, Scott Shane)

“Next to these direct effects, so-called indirect network effects are recognized. This is the case when adoption of a standard itself does not offer direct benefits on other users of the standard, but the adoption of the standard might ultimately benefit others. The distinction between direct and indirect refers to the source of benefit to participants in the network not necessarily to the magnitude of the network effect. For example, greater adoption of Xbox® consoles should generate greater variety in Xbox 360™ game titles. Common adoption would allow producers to achieve scale more easily. Katz and Shapiro (1985) showed how an indirect network effect i.e. the availability of software to support a hardware standard) made the more popular standard more attractive to future adopters. Other consumers or producers are likely to adopt such benefits as well.”

(Toward Corporate IT Standardization Management: Frameworks and Solutions, IGI Global, 2/28/2010, Robert van Wessel)

The hyper-effect of IP in a cloud!

To set the stage for semiconductor SoC design, we have to look again no further than the now famous, Moore’s Law. Moore’s Law simply states that the “quantity of transistors that can be placed inexpensively on an integrated circuit has doubled approximately every two years (http://en.wikipedia.org/wiki/Moore’s_law). The theoretical effect of Moore’s Law has been an exponential increase in the state space as defined by binary logic circuits that compose an integrated circuit’s functionality. The practical effect for large integrated circuit designs has been that it has become computationally impossible to verify the functional state of these devices before committing the component to manufacture.

Therein lies the impetus to leverage pre-packaged, pre-verified, circuits that can be placed as a self-contained functional blocks. We in the semiconductor industry call this design process System-on-Chip or SoC. The effect that we want to explore in this blog is: how does provisioning semiconductor IP within a collaborative computing cloud through a secure Digital-Rights-as-a-Service (DRaaS) design pattern create indirect network effects. In many ways, both DIRECT and INDIRECT network effects are spawned from Intellectual Property (IP), whether that IP is patent protected or copyrighted. In the case of INDIRECT network effects, the multiplicity of complementary IP components or products creates greater value in foundational IP element or product.

Indirect network effects come in the strangest ways –> http://www.prohiphop.com/2006/08/network_effects.html

Cloud-based Intellectual Property Rights – Part 1 – Defining “Parametric Security” and Digital-Rights-as-a-Service (DRaaS)

I’m personally energized by the IT industry trend toward cloud computing.  Rather than fearing the new paradigm for utility computing, I see the impact of utility computing as a tremendous leveling of the playing field for virtually EVERY field of engineering research and development.  I’m no different than any other engineering or business manager in sharing the concern for IP security in the cloud.  In fact, it is my very concern for IP security rights that adds to my belief that cloud computing architectures and services with the proper architecture, can INCREASE IP security and governance over a firm’s present distributed, isolated IT systems.  As systems and technology products continue to advance in complexity, the need for engineering collaboration between firms increases in a non-deterministic manner.

I postulate the following emerging dependencies…

Increasing system complexity is positively correlated with the demand for IT processing resources.

(1) Increasing levels of system complexity compel increasing reliance upon computer-aided design and (2) increasing reliance upon computer aided design increases the engineering demand for IT processing resources.

Increasing system complexity subjugates product architectures to the realism of Value Chain Evolution (VCE) theory.

Value Chain Evolution (VCE) Theory necessitates that supply chains effectuate higher degrees of collaboration.  As supply chains increase in complexity, modularity increases.  As modularity increases, key supply chain valuation points become amplified such that what is “good enough” can be outsourced, leaving niche differentiation as the key profit driver.

Cloud computing enterprise architectures can enact major positive changes for BOTH of the above postulates by supplying (1) on-demand, scalable processing resources, (2) providing a secure, multi-tenant design environment through distinct identity profiles for collaboration, and (3) standardized WorkFlow-as-a-Service (WFaaS) design processes.

Cloud Security Is a Recurring Theme

A recurring theme in the resistance to the adoption of cloud computing is always the inherent security risks that come with working in a shared computing resource environment.  Unquestionably, the cloud’s security concerns are certainly valid and warranted.  As a primary inhibitor to the adoption of cloud services by prospective users, cloud security concerns must be addressed by service providers in a transparent and satisfactory manner, lest their days as a service provider become short lived.  While not a closed subject by any means, much has been written about the user and IT requirements for cloud security.  As far as I am aware, very little has been written or debated about what I term parametric security, i.e. security guidelines within prescribed limits and or boundaries.  When a parametric security stereotype is applied to digitally distributed Intellectual Property (IP) rights in collaborative computing clouds, the design pattern that emerges is Digital-Rights-as-a-Service (DRaaS).  In this blog, I will seek to (1) contrast the types of digitally distributed IP that require DRaaS and then (2) discuss the foundational requirements of parametric security in cloud computing enterprise architectures, i.e. the Digital-Rights-as-a-Service (DRaaS) design pattern.

Astute readers will take issue, noting that DRaaS is simply another term for Digital Rights Management (DRM).  Unquestionably, DRM and DRaaS will have similarities, but primarily at an abstract level.  DRM and DRaaS are not two separate pronunciations or language translations of the same word.  If I were looking for a cultural metaphor for DRM and DRaaS, I’d look to the tradition of marriage and it’s diverse associated ceremonial rituals. The general outcome and objectives of marriage are effectively the same for all cultures, yet there are as many cultural and social distinctions in marriage ceremonies as there are cultures.  It is the same with DRM and DRaaS. DRM and DRaaS services are seeking very common objectives, but the implementation methods through which we get to the final result are highly contrasting in nature.  Additionally, as married couples from different cultures often live very different lives from other cultures, so to will the life cycle of parametric security implementations for DRM and DRaaS be varied and operationally unique.

The primary differences in DRM and DRaaS implementations lie in the types of datasets that each parametric security design pattern manages. DRM is typically applied to multi-media files, e.g. music or video files that are digitally distributed. However, digital distribution of Intellectual Property (IP) is not restricted to entertainment genre. Outside of multimedia files, the next set of digitally distributed data that comes to mind is open source software. Software source code has been assigned copyright protections for many years. The open source community has controlled copyright protections on digitally distributed source code through licenses such as the GNU General Public License. The product use of open source software code is ultimately in the form of a compiled binary object file to a target processor architecture or executed on a virtual machine architecture, e.g a JVM.  The resulting execution of the compiled binary on the target processor or virtual machine is obfuscated from the original source code. Dynamic and statically compiled libraries are also distribution mechanisms for open source code.

In these examples, the software source code has undergone one degree of non-orthogonal transformation, i.e. compilation or virtual machine.  In what sense do I mean non-orthogonal?  In the sense that the targeted operational domain of the IP has not changed.  The original high level programming source code was targeted for a Von Neumann style of object code execution.  Even after compilation, it is relatively straightforward to trace source code origins through both functional behavior and static analysis.  A second degree of non-orthogonal transformation in this case could be viewed as a re-compile of the original source code or binaries with compiler optimizations turned on.

This brings us to another type of intellectual property that is distributed in a  source code format, but undergoes a domain transformation that is orthogonal.  While I don’t want to get caught up in the trivialities of my loose definitions of orthogonal versus non-orthogonal domain transformations, a contrasting definition is in order.  In my definition of orthogonal domain transformations, what is input to the transform is not easily recovered or impossible to reverse engineer, i.e. there exists no inverse function.  You may contend that source code compilation of C++ code to a binary has no inverse function for de-compiling if the source code is not compiled with “debug” options.  Strictly speaking, that is true, thus my subjective caveat, “…not easily recovered”.  However, I contend that efforts in reverse engineering observed behavior of object code using processor emulators or virtual machines is not that difficult for trained and experienced eyes.  But, as I said, I don’t want to get caught up in the semantics.

What forms of digitally distributed IP undergo single and multiple degree orthogonal domain transformations?  Engineering or technology intellectual property.

As an electrical engineer and semiconductor component designer, the primary example that comes to my mind, is semiconductor intellectual property that is integrated as part of what component designers classify as Systems-on-Chip (SoC, pronounced ess-ō-see).  There are in fact many other type of engineering intellectual property that are subject to multi-degree orthogonal domain transformations.  My supposition is that if you were to review the patent database and then cross match those patents with computer aided automation design processes that would be applied to that patent’s industry, you would very quickly categorize virtually all intellectual property that that could be protected through a cloud-based DRaaS design pattern.

More to come from this blog entry…