Open Group points standards at service-orientation architecture needs and approaches

This guest BriefingsDirect post comes courtesy of Heather Kreger, IBM’s lead architect for SOA Standards in the IBM Software Group.

By Heather Kreger

Last week The Open Group announced two new standards for architects; actually, more appro-priately, for service architects, SOA architects, and cloud architects. These standards are intended to help organizations more easily deploy service-based solutions rapidly and reliably especially in multi-vendor environments.

These standards are the first product in a family of standards being developed for architects by The Open Group’s SOA Work Group. Other standards currently in development for SOA include the SOA Ontology, SOA Reference Architecture, and Service Oriented Infrastructure.

Architecture standards are especially valuable for creating a common, shared language and understanding between service integrators, vendors and customers of all sizes. They provide a common foundation of understanding for the industry. Considering the who’s who of integrators involved in the development of these two new standards -- Capgemini, CGI and HP/EDS, and IBM -- we can expect the standards to reflect validated and mature best practices and industry experience.

[See a post by Sandy Kemsley from Heather's presentation at The Open Group's recent architecture conference in Toronto. Disclosure: The Open Group is a sponsor of BriefingsDirect podcasts.]

First, the Open Group Service Integration Maturity Model (OSIMM) provides a method to measure service adoption and integration and create roadmaps for incremental transformation to SOA to meet business objectives.

OSIMM provides a context to identify the business benefits of each step along the roadmap and progression toward the appropriate level of maturity for your business goals. The model consists of seven dimensions of consideration within an organization: Business View, Governance and Organization, Methods, Applications, Architecture, Information, and Infrastructure and Management.

Each of these dimensions can, in turn, be assessed on a maturity level scale from one to seven, including: 1: Silo (data integration); 2: Integrated (application integration); 3: Componentized (functional integration); 4: Simple services (process integration); 5: Composite services (supply-chain integration); 6: Virtualized services (virtual infrastructure); and 7: Dynamically reconfigurable services (eco-system integration).

OSIMM resonates with organizations because they can see at a glance what the entire scope of service use and SOA is and they can find themselves somewhere on that continuum. The model also makes it easy to see where they want to be on the continuum to meet objectives and to check on progress toward those goals. It’s important to note that with this maturity model, more is not necessarily better; few companies will need to be at level 7 maturity, most will satisfy their business objectives at level 4 and 5.

Second standard

The second standard, the SOA Governance Framework provides a methodology to help ensure that business objectives are in line with the SOA solutions and IT investment. The framework defines a SOA Governance Reference Model, which includes concepts that architects should understand in relation to governance, such as principles, guidelines, organizations, governed service and SOA processes, governing processes for compliance and dispensation, and supporting technologies.

For each of these concepts, the authors have provided starting points based on best practices. The framework defines the SOA Governance Vitality Method, which is an iterative cycle through the phases of Plan, Define, Implement and Monitor for the governance regimen. The monitor phase uses policies, checkpoints and triggers to ensure the governing processes are in place and being followed. These triggers can also be used to evaluate and adjust the governance regimen itself.

Actually, a great deal of the SOA Governance Framework applies to the governance of architecture in general but is explicitly defined to provide guidance for governing Service portfolios and SOA solution portfolios. Interestingly enough, the governance of service portfolios applies equally to business solutions that use cloud.

These two standards represent a major step forward in creating and simplifying the standards to build SOA. This is increasingly important as more organizations have to justify incremental investment in services. OSIMM helps you figure out where you want to go, and SOA governance ensures that you meet your objectives on the journey.

Heather Kreger is IBM’s lead architect for SOA Standards in the IBM Software Group, with 15 years of standards experience. She has led the development of standards for Web services, Management and Java in numerous industry standards groups including W3C, OASIS, DMTF, and The Open Group. Heather is the author of numerous articles and specifications, as well as the book “Java and JMX, Building Manageable Systems,” and most recently was co-editor of “Navigating the SOA Open Standards Landscape Around Architecture.”

Nimble business process management helps enterprises gain rapid productivity returns

Listen to the podcast. View a full transcript or download the transcript. Find it on iTunes/iPod and Podcast.com. Learn more. Sponsor: BP Logix.

Welcome to a sponsored podcast discussion on the importance of business process management (BPM), especially for use across a variety of existing systems, in complex IT landscapes, and for building flexible business processes in dynamic environments.

The current economic climate has certainly highlighted how drastically businesses need to quickly adapt. Many organizations have had to adjust internally to new requirements and new budgets. They have also watched as their markets and supplier networks have shifted and become harder to predict.

To better understand how business processes can be developed and managed nimbly to help deal with such change, I recently moderated a panel of users, BPM providers, and analysts. Please join me in welcoming David A. Kelly, senior analyst at Upside Research; Joby O'Brien, vice president of development at BP Logix, and Jason Woodruff, project manager at TLT-Babcock.

Here are some excerpts:

Kelly: What's important is to be able to drive efficiency throughout an organization, and across all these business processes. With the economic challenges that organizations are facing, they've had to juggle suppliers, products, customers, ways to market, and ways to sell.

As they're doing that, they're looking at their existing business processes, trying to increase efficiencies, and they are trying to really make things more streamlined. ... Some organizations are even getting into cloud solutions and outside services that they need to integrate into their business processes. We've seen a real change in terms of how organizations are looking to manage these types of processes across applications, across data sources, across user populations.

... BPM solutions have been around for quite sometime now, and a lot of organizations have really put them to good use. But, over the past three or four years, we've seen this progression of organizations that are using BPM from a task-oriented solution to one that they have migrated into this infrastructure solution. ... [But] now with the changes and pressures that organizations are facing in the economy and their business cycles, we see organizations look for much more direct, shorter-term payback and ways to optimize business processes.

O'Brien: It's difficult for an organization, especially right now, to look at something on a one-, two-, or three-year plan. A lot of the BPM infrastructure products and a lot of the larger, more traditional ways that BPM vendors approach this reflect that type of plan. What we're seeing is that companies are looking for a quicker way to see a return on their BPM investment. What that means really is getting an implementation done and into production faster.

When there are particular business needs that are critical to an organization or business, those are the ones they tend try to address first. They are looking for ways to provide a solution that can be deployed rapidly. ... They take the processes that are most critical, and that are being driven by the business users and their needs, and address those with a one-at-a-time approach as they go through the organization.

It's very different than a more traditional approach, where you put all of the different requirements out there and spend six months going through discovery, design, and the different approaches. So, it's very different, but provides a rapid deployment of highly customized implementations.

Woodruff: TLT-Babcock is a supplier of air handling and material handling equipment, primarily in the utility and industrial markets. So, we have our hands in a lot of markets and lot of places.

As a project manager, ... I realized a need for streamlining our process. Right now, we don't want to ride the wave, but we want to drive the wave. We want to be proactive and we want to be the best out there. In order to do that, we need to improve our processes and continuously monitor and change them as needed.

After quite a bit of investigation and looking at different products, we developed and used a matrix that, first and foremost, looked at functionality. We need to do what we need to do. That requires flexibility and ultimately usability, not only from the implementation stage, but the end user stage, and to do so in the most cost-effective manner. That's where we are today.

We looked at why document control was an issue and what we could do to improve it. Then, we started looking at our processes and internal functions and realized that we needed a way to not just streamline them. One, we needed a way to define them better. Two, we needed to make sure that they are consistent and repetitive, which is basically automation.

O'Brien: There's one thing that Jason said that we think is particularly important. He used one phrase that's key to Nimble BPM. He used the term "monitor and change," and that is really critical. That means that I have deployed and am moving forward, but have the ability, with BP Logix Workflow Director, to monitor how things are going -- and then the ability to make changes based on the business requirements. This is really key to a Nimble BPM approach.

The approach of trying to get everybody to have a consensus, a six-month discovery, to go through all the different modeling, to put it down in stone, and then implement it works well in a lot of cases. But organizations that are trying to adapt very quickly and move into a more automated phase for the business processes need the ability to start quickly.

... The idea or the approach with the Nimble BPM is to allow folks like Jason -- and those within IT -- to be able to start quickly. They can put one together based on what the business users are indicating they need. They can then give them the tools and the ability to monitor things and make those changes, as they learn more.

In that approach, you can significantly compress that initial discovery phase. In a lot of the cases, you can actually turn that discovery phase into an automation phase, where, as part of that, you're going through the monitoring and the change, but you have already started at that point.

Woodruff: We saw this as an opportunity not just to implement a new product like Workflow Director, but to really reevaluate our processes and, in many cases, redefine them, sometimes gradually, other times quite drastically.

Our project cycle, from when we get an order to when our equipment is up and operating, can be two, three, sometimes four years. During that time there are many different processes from many different departments happening in parallel and serially as well. You name it -- it's all over the place. So, we started with that six-month discovery process, where we are trying to really get our hands around what do we do, why do we do it that way and what we should be doing.

As a result, we've defined some pretty complex business models and have begun developing. It’s been interesting that during that development of these longer-term, far-reaching implementations, the sort of spur-of-the-moment things have come up, been addressed, and been released, almost without realizing it.

A user will come and say they have a problem with this particular process. We can help. We'll sit down, find out what they need, create a form, model the workflow, and, within a couple of days, they're off and running. The feedback has been overwhelmingly positive.

Listen to the podcast. View a full transcript or download the transcript. Find it on iTunes/iPod and Podcast.com. Learn more. Sponsor: BP Logix.

New era enterprise architects need sweeping skills to straddle the IT-business alignment chasm

Listen to the podcast. Find it on iTunes/iPod and Podcast.com.View a full transcript or download the transcript. Sponsor: The Open Group.

Welcome to a special sponsored podcast discussion coming from The Open Group’s 23rd Enterprise Architecture Practitioners Conference in Toronto. This podcast, part of a series from the event, centers on the issue of the enterprise architect (EA) -- the role, the responsibilities, the certification, and skills -- both now and into the future.

The burgeoning impact of cloud computing, the down economy, and the interest in projecting more value from IT to the larger business is putting new requirements on the enterprise IT department. [See a related discussion on the effect of cloud computing on the architect role.]

So who takes on the mantle of grand overseer as IT expand its purview into more business processes and productivity issues? Who is responsible? Who can instrument these changes, and, in a sense, be a new kind of leader in the transition and transformation of IT and the enterprise?

To help us sort through who takes on the mantle of grand overseer as IT expand its purview, we're joined by James de Raeve, vice president of certification at The Open Group; Len Fehskens, vice president, Skills and Capabilities at The Open Group; David Foote, CEO and co-founder, as well as chief research officer, at Foote Partners, and Jason Uppal, chief architect at QRS. The discussion is moderated by me, BriefingsDirect's Dana Gardner.

Here are some excerpts:

Fehskens: One of the things that I've seen over my career in architecture is that the focus of architects has moved up the stack, so to speak. Initially the focus was on rationalizing infrastructure, looking for ways to reduce cost by removing redundancy and unneeded diversity. It's moved up through the middleware layer to the application layer to business process, and now people are saying, "Well, the place where we need to look for those kinds of benefits is now at the strategy level." That's inevitable.

The thing to understand, though, is that's it's not moving forward in a linear front across the entire industry. The rate of progress is locally defined, so to speak. So, different organizations will be at different points in that evolutionary path.

Uppal: As role of the architect starts to ascend in the organization ... it makes a lot of other professionals very nervous about what we do. In this day and age, you have to be very good at what you always did in the rationalization technology, but you also have to be very much almost a priest-like sensitive person, so that you don't trample on somebody's feelings.

You have to make sure that you don't trample somebody else along the way, because, without them, you're not going to go very far. Otherwise, they're going to throw a lot of stones along the way. So that's another a huge challenge that we have from skills of the architect ... having this soul that is sensitive to the other professions.

Foote: In the total group of enterprise architects I've met, every one of them was a great communicator. They were able to really make people feel comfortable around some very abstruse, very abstract, and, for people who are not technical, very technical concepts. They just could communicate. They could set people at ease. They were nonthreatening, and by the way, most of them, I think, were really close to genius.

Fehskens: One of the architects who I worked with on a fairly regular basis told me that the most satisfying moment in her career was when one of her clients told her, "You make me feel smart." That for me really encapsulated the communications goal for an architect -- to make points about these complex issues so clear that people understand them and feel comfortable with them.

Foote: People really don't know who enterprise architects are. ... [The average HR department person] thinks "architect" is a title that all people in IT want to have ... without really grabbing hold and defining the architect. They've let the IT organization simply hand out these titles to people as a way to attract them to the organization.

... That lack of control in HR is commonplace today. I tell HR organizations that ... You should have a representative to the HR organization that was selected by the CIO or the IT management there to represent them to HR. That person should be the person who advocates also for HR, so that they never are handed job descriptions that do not exist in the company. ... Mainly the lack of control is around job descriptions.

De Raeve: The other thing is that architects are, by their nature, extremely adaptive, and they redefine themselves to fit into where there are gaps in the organization where there are needs. They reshape themselves to address those needs. So, we're sort of like chameleons or shape-shifters, depending on what the organizational context is.

If you've got a whole bunch of people doing that, it's very hard to say, "You people are all basically performing the same role, because it will look different in some respect. See one person do it. It's even worse. So the only thing you could do is say, "Oh, shape-shifter, some kind of a magician."

... I think what you're asking for is the universally agreed professional framework for the enterprise architect, and I'll give it you the moment we have it. ... We're at an early stage in the maturity of this concept in the profession or in the industry.

... This was the very problem that we were given when developing our certification. We've got some documentation, which defines what those skills and experience levels are. You can look at that, if you're practicing architecture or you are in the architecture space. You could look at that stuff and say, "These are really good things that I ought to be drawing from as I work on my definitions of roles, or as I look at recruiting people or developing or promoting people." The certification is a separate piece of value.

So, we provide a lot of material that enables you to actually come to grips with what best practice things are, a set of core skills, competencies, and experiences that are needed by successful architects. In response to that, we developed our IT Architect Certification Program (ITAC) for the skills and experience, the ITAC Program, and we also have the TOGAF program, which is more about knowledge.

The community is crying out for it. They may not know that they're asking for it, but they're asking for it. One of my things is that I have to go and sell our certification programs to people. So I visit a number of different organizations and explain what we're doing and what it means.

So, we've got the two things: tools to enable organizations to start understanding what best practice is in the space, and then the certification program that allows people to communicate to their customers, their employers, and their next employer that they actually possess these skills and competencies.

Uppal: If we step outside of the IT industry, you'll see a lot of parallels of other professionals being developed, very similarly to how we develop architects. Architects are not this nebulous thing that just grows. They are developed.

Foote: There are definitely some activities in architecture that you can't outsource.

I've never met a recruiter who specialized in architects. I don't know that those recruiters exist. They probably don't, because there isn't a lot of demand on the outside for hiring architects.

... Most companies that we talk to say, "We like our architects. They've done very well, because we trust them. The business trusts them. We trust them. They are good channels of communication. They've opened up a lot of thought in our company. We'd really like three times more of these people. How do we accelerate the growth internally?"

They want to know how they can develop architects internally, because they know that they're not going to get that same quality. Now, these are people who are architecting out of that very delicate core competency, strategic level that you don't want to share with outsiders -- for a lot of reasons.

... I've never met a recruiter who specialized in architects. I don't know that those recruiters exist. They probably don't, because there isn't a lot of demand on the outside for hiring architects.

I do think the architects that I see that are brought in from outside are often consultants, formerly of Accenture, IBM, CSC, or one of the large houses. They are brought in basically to calm down the chatter, to educate, and train. They're there to cleanup a fire, to calm things down, get people on the same page, and then go. Sometimes, that's the best way to bring in an architect.

Fehskens: In a couple of conversations that I've had with people about where we seem to be evolving the role of enterprise architect, they have said basically, "Yeah, these people are going to become in-house management consultants and they're going to be better for that. They're going to know your business intimately, because they're going to have participated in strategic evolution over time."

There is a lot of merit in that analogy and a lot of similarity. I think the only difference is that what we're trying to do with EA is bring more of engineering rigor and engineering discipline to this domain and less of the touchy, feely, "do it because I think it's the right thing to do" kind of stuff -- not to disparage management consultants and the like.

Uppal: One of the big differences between management consultant and enterprise architects is that what you put on the table, you have to execute. The management consultant says, "You should do this, this, and this," and walks away. At the end of the day, if you, as an architect, put something on the table and you can't execute this thing, you have basically zero value. People are no longer buying management consultants at face value. They want you to execute.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com.View a full transcript or download the transcript. Sponsor: The Open Group.

DoD's Net-Centricity approach moves SOA into battle formation

This guest BriefingsDirect post comes courtesy of ZapThink. Jason Bloomberg is managing partner at ZapThink. You can reach him here.

By Jason Bloomberg

ZapThink recently conducted our Licensed ZapThink Architect Bootcamp course for a branch of the United States Department of Defense (DoD). As it happens, an increasing proportion of our US-based business is for the DoD, which is perfectly logical, given the strategic nature Service-Oriented Architecture (SOA) plays for the DoD.

SOA is so strategic, in fact, that SOA underlies how the DoD expects to achieve its mission in the 21st century -- namely, defending US interests by presenting the most powerful military presence on the globe. Furthermore, the story of how SOA became so strategic for the DoD provides insight into the power of SOA for all organizations, both in the public and private sector.

This story begins with the issue of complexity. The DoD, as you might imagine, is an organization of astounding complexity, perhaps the most complex organization in the world, save the US Federal Government itself, of which the DoD is indubitably the most complex part.

And with complexity comes vulnerability. As the sole remaining global superpower, the US's strength in battle, namely our overwhelming force, presents vulnerabilities to much smaller enemies. Traditional guerrilla tactics give small forces advantages over large ones, after all. Our 21st century adversaries understand full well the ancient principle of using an enemy's strengths against them. The DoD is rightly concerned that its sheer scale and complexity present weaknesses that today's terrorism-centric threats can take advantage of.

From the network to service orientation

Even before 9/11, there was an understanding that the core challenge that this complexity presented was one of information: who has it, how to share it, and how to rely upon it to make decisions -- in military parlance, Command and Control (C2). In response to this need, the DoD instituted a new strategic program, Network Centric Warfare, also known as Net-Centricity.

The idea for Network Centric Warfare arose during the late 1990s in response to the rise of the Internet. Its original concepts, therefore, were essentially "Web 1.0" in nature. It didn't take long, however, for DoD architects to realize that the network itself was only a piece of the puzzle, and it soon became clear that the challenges of Net-Centricity were as much organizational as technological. After all, Net-Centricity requires cooperation across the different branches of service -- a tall order for an organization as siloed as the DoD.

In fact, as the DoD and their contractors hammered out the details of Net-Centricity, it became increasingly clear that Net-Centricity required a broad, architectural approach to achieving agile information sharing in the context of a complex, siloed organization.

At that point, SOA entered the Net-Centricity picture, providing essential best practices for sharing information resources to support business process needs. In the military context, such business processes are operational processes, where the operation at hand might be fueling airplanes or deploying ground troops or spying on suspected terrorists with a satellite. When battlefield commanders say that they want the warfighting resources at their disposal to be available as needed to achieve their mission objectives, they are essentially requiring a Service-Oriented approach to Net-Centricity.

Information as a strategic military asset

Information has always been a part of warfare, since the stone age or even earlier. Essentially, the element of surprise boils down to one force having information the other does not, regardless of whether you're sneaking up on a foe with a club or leveraging satellite technology to precisely target an attack.

The same is true of Net-Centricity. Net-Centricity centers on supporting the military's C2 capabilities by ensuring the right information is in the right place at the right time. These three dimensions all create a path toward SOA ...

• The right information: Commanders on the battlefield need all relevant information. It is essential to have access to relevant information from different forces, different locations, and different branches of service. Furthermore, commanders need a way to separate relevant information from the surrounding noise. And finally, they must ensure that the information is reliable.
  
  
• In the right place: Today's warfare is an inherently distributed endeavor. Gone are the days where armies fight each other on single fields of battle. Today, commanders might call upon forces from hundreds of miles away, on land, at sea, in the air, or in space. Furthermore, the people who need the information might be anywhere. For example, a Navy ship may get the information it needs to target a missile from air support, satellite-based intelligence, and ground capabilities. The commander needs one view while the troops on the battlefield need another.
  
  
• At the right time: Information is perishable. The more dynamic the purpose of that information, the more perishable it becomes. Knowing where your enemies are right now is far more valuable then where they were an hour or a day ago.

If you've been following ZapThink for any amount of time, you'll recognize these business drivers as being a recipe for SOA. It's no surprise, therefore that the Global Information Grid (GIG), a central Net-Centric capability, is inherently Service-Oriented. The GIG essentially consists of a set of Services that provide the underpinnings of the right information at the right place at the right time, as the figure below illustrates.
















There are a few features of the GIG worth noting. First, note how the core notion of a Service pervades the GIG. Every capability, from security to messaging to management, is represented as a Service. Secondly, keep in mind the global nature of the GIG. This is not a solitary data center; the GIG represents global IT capabilities across all branches of service for the entire DoD.

Today, the stakes for Net-Centricity couldn't be higher, because information itself proffers a new set of weapons, and even new battlefields. As a result, Net-Centricity focuses not only on leveraging shared IT capabilities to gain an advantage on both large and small opponents using traditional tactics, it also covers protecting our forces from information-based attacks as well as launching our own.

After all, if a small but smart opponent combines traditional guerrilla warfare with the information-centric guerrilla tactics we now call cyberwarfare, our vulnerabilities multiply. If a single opponent with an improvised explosive device can wound us, what about a single opponent with a means to interfere with our communications infrastructure?

The ZapThink take

There are lessons here for our readers both within the DoD as well as at other organizations, including those within the private sector, where the battles are economic. For DoD readers, it's important to recognize the importance of SOA to Net-Centricity, in particular how the architecture required to succeed with Net-Centricity is the true SOA that ZapThink talks about, where organizational transformation is a greater challenge than the technological issues that organizations face.

For other organizations, the lesson here is how to take a page out of the DoD's playbook. Net-Centricity is by no means the first example of how a DoD project led to broad commercial application; after all, the Internet itself is a case in point. In the DoD we have an organization with both a mind-boggling complexity problem and enormous resources, both financial and human, to assign to the problem. Sharing information across lines of business in a bank or manufacturer or power utility is child's play in comparison to getting the Army, Navy, Air Force, and Marines to share information effectively.

Furthermore, as ZapThink continues its work within the DoD, we can help act as a conduit for conveying the best practices of Net-Centricity to the private sector, as well as other government organizations. You'll see evidence of Net-Centric lessons learned in both our LZA Bootcamp as well as our new SOA & Cloud Governance course. The more complex your organization, the more a Net-Centric approach to achieving your strategic goals is a useful context for your SOA efforts, and ZapThink can help.

Finally, some organizations may find the concept of Net-Centricity to be a useful synonym for SOA. If you're having trouble explaining the benefits of SOA to a business audience, perhaps a discussion of Net-Centricity will help to shed the light on the approach you're recommending.

After all, not only does Net-Centricity focus on effective information sharing in a complex environment, it also distills the urgency and importance of the military context, where the enemy is literally trying to kill us.

Competition in the marketplace may not be a literal life-or-death battle, but leveraging best practice approaches to fighting such battles that treat them as though they were truly about survival is an attitude that any seasoned business stakeholder can take to heart.

This guest post comes courtesy of ZapThink. Jason Bloomberg is managing partner at ZapThink. You can reach him here.

---

SPECIAL PARTNER OFFER

SOA and EA Training, Certification,
and Networking Events

In need of vendor-neutral, architect-level SOA and EA training? ZapThink's Licensed ZapThink Architect (LZA) SOA Boot Camps provide four days of intense, hands-on architect-level SOA training and certification.

Advanced SOA architects might want to enroll in ZapThink's SOA Governance and Security training and certification courses. Or, are you just looking to network with your peers, interact with experts and pundits, and schmooze on SOA after hours? Join us at an upcoming ZapForum event. Find out more and register for these events at http://www.zapthink.com/eventreg.html.

---

Cloud computing uniquely enables product and food recall processes across supply chains

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download the transcript. Learn more. Sponsor: Hewlett Packard.

Free Offer: Get a complimentary copy of the new book Cloud Computing For Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.

This week brought an excellent example of how cloud-based services can meet business goals better than traditional IT and process management approaches.

In conjunction with GS1 Canada, HP announced a product recall process Monday that straddles many participants across global supply chains. The pressures in such multi-player process ecologies can mount past the breaking point for such change management nightmares as rapid food or product recalls.

You may remember recent food recalls that hurt customers, sellers, suppliers and manufacturers -- potentially irreparably. There have been similar issues with products or public health outbreaks. The only way to protect users is to identify the risks, warn the communities and public, and remove the hazards. It demands a tremendous amount of coordination and adjustment, often without an initial control source or authority.

The keys to making such recalls effective is traceability, visibility and collaboration across many organization boundaries. Traditional "one step up, one step down" methods -- the norm today in addressing the tracing of any product -- has its limitations in providing required visibility into products across their lifecycle. Without viable information about how food or products get to market, you can't get them out.

Hence, developing an accurate, single picture of the "life story of a product" is something the industry and the consumers have struggled with continuously, according to Mick Keyes, Senior Architect in HP's CTO's Office. [Disclosure: HP is a sponsor of BriefingsDirect podcasts.]

That "life story of a product" became the nexus of the initiative to create a "cloud traceability platform," which arrived Monday. The GS1 Canada Product Recall service runs on the HP cloud computing platform for manufacturing to provide users with secure, real-time access to product information so that recalled products are fully traced and promptly removed from the supply chain.

This enables more accurate targeting of recall products. Security enhancements help make sure that only authorized recalls are issued and that only targeted retailers receive notifications. HP will be creating a number of additional specific services that leverage cloud computing to meet specific industry need in other sectors, such as hospitality and retail.

I recently moderated a sponsored podcast discussion on the fast-evolving implications that cloud computing has on companies in industries like manufacturing. The goal is not to define cloud by what it is, but rather by what it can do, and to explore what cloud solutions can provide to manufacturing and other industries.

In addition to Keyes, I was joined in the discussion by Christian Verstraete, Chief Technology Officer for Manufacturing & Distribution Industries Worldwide at HP, and Bernd Roessler, marketing manager for Manufacturing Industries at HP

Here are some excerpts:

Keyes: In the whole area of recall, we're looking at value-add services that we will offer to regulatory bodies, other industry groups, and governments, so they can have a visibility into what's happening in real-time.

This is something that's been missing in the industry up to today. What we're offering is a centralized offering, a hub, where any of the entities in the supply chain or nodes in the supply chain -- be they manufacturers, be they transportation networks, retailers, or consumers -- can use the cloud as a mechanism from which they will be able to gain information on whether our product is recalled or not.

In the last few years, we've seen a large number of recalls across the world, which hit industry fairly heavily. But also, from a consumer point of view or visibility into where the food comes from, this can be extended to other product areas. It improves consumer confidence in products that they purchase.

It's not just in the food area. We also see it expanding into areas such as healthcare and the whole pharmaceutical area as well. We're looking at the whole idea of how you profile people in the cloud itself. We're looking at how next generation devices, edge of the network devices as well, will also feed information from anywhere in the world into the profile that you may have in the cloud itself.

We're taking data from many disparate types of sources -- be it the food you actually eat, be it your health environment, be it your life cycle -- and be able to come with up cloud based offerings to offer a variety of different services to consumers. It's a real extension to what industry is doing.

Roessler: Cloud services to consumers are distinct, different things, compared to cloud services in the enterprise. From an industry vertical perspective, I think we need to have a particular look at what is different in providing cloud services for enterprises. ... Some dimensions of cloud are changing business behavior of companies.

Number one is that everybody likes to live up to the promise of saving costs by introducing cloud services to enterprises and their value chains. Nevertheless, compared to consumer services like free e-mail, the situation in enterprises is dramatically different, because we have a different cost structure, as we need not only talk about the cost of transaction.

In the enterprise, we also need to think about, privacy, storage, and archiving information, because that is the context under which cloud services for enterprises live.

The second dimension, which is different, is the management of intellectual property and confidentiality in the enterprise environment. Here it is necessary that cloud services, which are designed for industry usage, are capturing data. At the moment, everybody is trying to make sure that critical enterprise information in IT is secured and stays where it should stay. That definitely imposes a critical functionality requirement to any cloud service, which might contradict the need for creating this, "everybody can access anywhere," vision of a cloud service.

Last but not least, it is important that we're able to scale those services according to the requirement of the function and the services this cloud environment should provide. This is imposing quite a few requirements on the technical infrastructure. You need to have compute power, which you can inject into the market, whenever you need it.

You need to be able to scale up very much on the dependencies, however. And, coming back to the promise of the cost savings, if you're not combining this technology infrastructure scalability with the dimension of automation, then cloud services for enterprises will not deliver the cost savings expected. These are the kinds of environments and dimensions any cloud provisioning, particularly in enterprises, need to work against.

Verstraete: By using cloud services and by changing the approach that is provided to the customer, at the same time you do a very good thing from an environmental perspective. You suddenly start seeing that cloud is adding value in different ways, depending on how you use it. As you said earlier, it allows you to do things that you could not do before, and that's an important point.

Gain a good understanding of what the cloud is and then really start thinking about where the cloud could really add value to their enterprise. One of the things that we announced last week is a workshop that helps them to do that – The HP Cloud Discovery Workshop -- that involves sitting down with our customers and working with them, trying to first explain cloud to them, having them gain a good understanding of what a cloud really is, and then looking with them at where it can really start adding value to them.

Once they’ve done that, they can then start building a roadmap of how they will start experimenting with the cloud, how they will learn from implementing the cloud. They can then move and grow their capabilities in that space, as they grow those new services, as they grow those new capabilities, as they build a trust that we talked about earlier.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. View a full transcript or download the transcript. Learn more. Sponsor: Hewlett Packard.

Free Offer: Get a complimentary copy of the new book Cloud Computing For Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.