I am freshly returned from the HighJump Software user conference in Scottsdale, and my thinking on supply chain software went in an unexpected direction relative to a new approach to supply chain software functionality enhancements.

At the conference, HighJump announced a new "app store" for its supply chain execution suite (Warehouse Management Systems, etc.).

At first, I assumed it was just some trendy, inconsequential thing to jump on IPhone bandwagon, but I was wrong - though the IPhone app store was the germ of the idea.

As many or most may know, with the rapid rise of Internet-enabled smart phones, especially the IPhone and the Google-based Androids, developers have been busy building add-on applications for these phones. In fact, there are hundreds of thousands of them, many free, some with a small charge. The apps range from tracking what food you eat during the day to tracking a FedEx package and thousands of other utilities.

The key point is that they just work on the IPhone or Android platform. You download what you need and only what you need.

HighJump has adopted a similar philosophy to providing enhancements to its core applications. The HighJump app store will feature pieces of functionality that can be downloaded and added to the functionality of the appropriate module in HighJump's suite that a customer is already running.

So, to cite an example offered at the conference by HighJump VP Chad Collins, there are some specific ways that bakery products coming out of the ovens need to be sorted and put on carts or other storage mechanisms. Specific data needs to be collected using handheld devices or regular screens. With this app store concept, that specific little work flow can be created as a downloadable application, and it can be easily inserted ("called") from the standard application precisely where it is needed in the process, handing back control to the main app when finished.

When you download an app from the HighJump store (free, for now, with a current maintenance agreement), you receive:

• Required screens/screen changes (regular or RF)
• Database changes
• Workflow/screenflow process mappings
• Documentation on what the app is and how it works.

Implications for Software Industry Could be Many

There are all sorts of potential implications from  this concept. The first is that this may be the perfect way of delivering many/most pieces of functionality specific to companies in different vertical industries or with different supply chain process models. This, as I know quite well, is a constant challenge for those in the software business.

Let's take the bakery example. You sell a WMS to a bakery, which needs this functionality. It's not in the base product. So a modification is required - but of course the bakery wants the capability to be in the core system, so the vendor makes that commitment.

Good for the baker - but not so good for the candlestick maker, the retailer, the widget manufacturer, and everyone else who now has their core system mucked up with more functionality and database stuff that has nothing to do with them. Across dozens of other customers, this becomes a big issue (code and database "bloat".) App stores with specific vertical industry functionality might be the way to solve this issue.

Which then begs the question - is an "app store" the way a supply chain software company might actually primarily deliver new functionality? No more upgrading the full software solution to just to get  the two or three new capabilities that are the ones really needed for the operation. Just download those apps instead.

Likely, some functional improvements would be considered "core" and go into the base product, while some would be consider specialized and be available from the app store. How this would/will play out in practice will be interesting to see.

Obviously, this concept now opens the potential for an "open source" type of community. Service oriented architecture (SOA), software componentry, and workflow tools continue to put more power into the user's hands. As they build their own enhancements, those could be offered back to the app store. HighJump, in fact, is positioned to support this, saying they would vet the quality and workability of the submitted apps and then make them available in the store.

Another question, of course, is would companies really be willing to share those advances? Sometimes yes, sometimes no, I suspect. factoring in competitive issues. Procter & Gamble, as just a for instance, is not likely to gladly submit an app that makes Colgate-Palmolive's distribution life easier.

But during the presentation in Scottsdale, I would estimate 75-80% of the room said they would be open to sharing the apps they might develop internally. This would have to play out. Perhaps companies might want to make it available for most others, but not some specific competitors. Could get tricky.

A couple of years ago, i2 Technologies actually unveiled a somewhat similar notion, with what it called "business content libraries." The idea involved a library of tailored workflows for different scenarios (say a specific process for developing a global, consensus forecast) that its customers could similarly download and implement.

My sense is i2 was thinking "bigger" in terms of scope of the workflows than HighJump is thinking or others might. In addition, to take advantage of this new offering, nearly everyone at the time would have needed to upgrade their i2 platform to take advantage of the new "agile architecture." There was a cost to  be able to access the workflow library (a subscription fee).

Nevertheless, it was a very cool vision, and clearly on the same basic track, if maybe a level above, to both the good and the bad. I am not sure how the concept has fared since the JDA Software acquisition of i2.

There are of course some challenges. Our Mark Fralick, who knows as much about service oriented architecture as anyone around, sees much potential in the basic idea, as well as some challenges.

"The key is the "atomic completeness" of the applications being downloaded," he said. I asked for a translation for that term, and he said that an available app must really be able start and fully execute successfully on its own given the context of the specific environment it is going into.

"That would be pretty easy for things like reports or bills of lading, compliance requirements, things like that," he said. "But as the apps get more complex, things would become more challenging. The app would have to make assumptions about the state of things in the distribution center or the WMS configuration."

Fralick brought up the example of a cart picking enhancement that would add new intelligence to the process.

"Could that be downloaded and installed without breaking something somewhere else? That's the question," he added, saying the smaller the scope of functionality, the easier it would be to achieve atomic completeness.

That said, he believes it would be difficult but not impossible to achieve that completeness for larger chunks of functionality, or that the apps could get a company maybe 75% of the way there for something they need rather than starting from scratch.

There are many more issues here. A vendor would have to have the right type of SOA-based architecture to support the whole notion. To have maximum effect in the long run, users would need tools to easily build their own mini-apps, which could then be shared with the community. The effort to qualify and fix submitted apps as needed could prove very costly to the vendors. Maybe free doesn't work. This only works within a given vendor's system - though I can see maybe specific SAP integrations from best of breed vendors being offered as an app.

Nevertheless, this is a very provocative concept, and one that might have quite an impact on how software functionality is delivered and even the traditional versus on-demand software debate. More on the latter statement in a future column.

What do you think of an app store approach to supply chain software? What are the barriers? Could this have a major impact on how software is delivered? Let us know your thoughts at the Feedback button below.

Web Page/Printable Version of Column

In the early days of the wireless RF terminal industry in distribution (late 1980s throughout most of the 1990s), what long gone company was usually the market share leader?

Telxon. The once high flyer stumbled late in the decade and was acquired by Symbol Technologies in 2000, which in turn was later acquired by Motorola. We suspect there are still quite a few Telxon-branded devices in operation somewhere out there today.