Although BEA’s President and CEO, Alfred Chuang, predicted the “end of the era of packaged applications“, he was beaten to the punch by Bob Crowley (president of Bowstreet).  Crowley beat this prediction by seven years actually…  Crowley’s prediction is from the year 2000.

It is ironic here that my link is from AMR, as one of my favorite AMR analysts, Jon Fontanella, is at our Global Headquarters today for our annual Managed Services Forum — and he was strong in his belief that packaged applications will be with us for “a long time”.  Jon has been very consistent on this, but it is in no way due to a lack of enthusiasm for the SaaS (Software as a Service) model — it is just that enterprises do not abandon technology that is working for them and mission critical, at least not quickly.

The world is full of cautionary tales of ERP implementations that were full of pain, cost, and expensive consultants.  Less discussed, but not difficult to find, are companies running such implemented software very successfully and not eager to commence a new implementation — any implementation — anytime soon.  Where existing packaged applications are in place and performing well, they are going to remain.  Moreover, thousands of IT professionals that have worked in these shops are able to leverage their experiences and skills to increase the success rate of downstream projects.

Software as a Service is well suited to areas where traditional packaged software often disappointed.  If you want to get up and running quickly, SaaS is a great alternative.  If you need to scale cost as well as capacity, SaaS is terrific.  But if you already have an ERP system in place, it may well make sense to add a module, to leverage the shared data model.  SaaS versus packaged apps will be an “it depends” for a long time.

This whole discussion reminds me of the debate about XML and EDI.  When XML was skyrocketing in popularity, many thought it would replace EDI.   When that didn’t happen, people interpreted that as a failure of XML.  Both of these perspectives missed a key point, while new technology or business models will cannibalize some existing competing alternatives, the biggest impact is from addressing new markets or unsolved problems. 

I believe that SaaS will have a huge impact on the packaged applications market, I just don’t believe it will end it…

A very interesting post on “Paying for SOA” by Nick Malik over at Microsoft (he is in the Enterprise Architecture group).  He applies a taxonomy based on tax policy — which is surprisingly apt (or at least I felt so after reading his post…)

For me, the core challenge is that two truths are in conflict:

1. Centrally providing services at scale is usually more efficient
2. Small, independent teams will outperform large dependent teams (I wish I could phrase this better)

Did I say these are in conflict?  I made a mistake, a mistake many people make, because I equated efficiency, productivity, and speed.

In the traditional IT world, I would propose these definitions:

• efficiency:  total cost of ownership to the entire organization, which may mean “sub-optimizing” a given team
• productivity:  the efficiency of a person or team on a given project, but not necessarily the whole organization
• speed:  time to benefit for a given solution

“Big SOA” can be considered to be good for efficiency.  In this world you build things only once, reuse like crazy, and standardize as much as possible.  The theory is that you will get some speed benefits, later…   The problem here is that we turn the world inside out, and make the engine room the entire purpose, rather than just a big infrastructure to move the cruise ship from island to island.  Big-time architecture programs often disappoint because they get so enmeshed in infrastructure that they forget why they were started (to make it easier to do things).  I believe some large outsourcing arrangements (where entire IT groups are consumed by mammoth firms) succumb to this as well, though not all.

Total independence, on the other hand, makes no sense either.  If every team is using a completely different philosophy and technology stack, you never get any scale and spend lots of time integrating stuff.  This is almost never a conscious decision, and is mostly observed in acquisitions (hey, nobody told the IT groups that would be one big happy family one day) — but on a smaller scale it is not uncommon to see different teams “agree to disagree” on key points like middleware.  Independence and free choice will initially drive productivity, but as systems need to be linked, you pay it back with interest.

So what is the answer?  I think it is somewhere in-between.  Our own GXS Trading Grid applications are a mixture of mandated shared services (like identity, translation, messaging), and independent application functionality.  The balance is difficult to achieve, but Nick Malik’s piece is some nice thinking on at least one model of achieving it….

Something in one of my recent posts ( SOA versus ESB — conflict or collaboration ) struck a chord with Dan Foody over at Progress Software, and his post about understanding your organization before you architect has now gotten me thinking.

The Chief Architect of the GXS Trading Grid is a guy named Jeff Barton, and he has a favorite phrase on this, “architecture by org chart”.  This is somewhat different from Dan’s blog entry, as Jeff’s point is the tendency of development teams to be more Ptolemaic than Copernican (basically, teams make the rest of thew world revolve around themselves).  As I looked up the wikipedia entries on the Ptolemaic system, I realized just how apt this metaphor was — since it requires gigantic planets in space to spin, perform loops and rotate around Earth to make the math work!

The widespread implementation of SOA requires coordination across multiple teams, who must “do work” on current projects that is — in the short run — exclusively of benefit to other teams!  Over time, and not even that long in GXS’s experience, benefits boomerang as other teams do the same — but this is a leap of faith, and many IT people are not into leaping.  This same challenge is also faced by the proponents of RFID deployments (we’re for that, but that is another entry….).

This is where the influence of CTOs, Chief Architects, and senior developers is make or break. 

Dan references the very real challenges of balancing the power of IT/non-IT groups, but in my experience even balancing amongst different IT teams can be a monstrous challenge.  One technique I have seen work with some success is to deploy mandatory common infrastructure, with some degree of enforcement.  I have seen a few models of this:

1. preferred vendors:  one ESB, database, ERP, etc.  There might still be multiple instances (better be, in the case of databases!), but at least there is a single skillset and technical support connection.  You still have versioning issues, but at least you’re on the right track.  Easiest to enforce if you have centralized purchasing, as they can flag orders for anything “off the list”
2. common services:  you have to go to the “insert capability here” team (ESB, message queueing, database).  Much more amenable to a unified structure, but requires incredible commitment from the teams providing services, and lots of enforcement from above.  The first time a project misses because of an external dependency (”they wouldn’t configure the ESB for us!”), it starts to unravel.  Particularly challenging because the “core teams” are not directly connected to revenue, which can cause issues when budgets are allocated.  This is probably not an option for teams in organizations where IT is not in control — or at least on par — of resource allocation for IT projects
3. outside service providers:  Like #2 above, but using an outside service provider or SaaS vendor.  I admit this is somewhat self-serving, but the difference is that you do not have to deal with internal rivalries, and for-profit service providers tend to have more capacity when you go to them, which is really just a function of scale.  We have many managed services customers who require their divisions to use us for certain functions, and that achieve both standardization and integration (we are already integrated to their back ends).  Easier than #2, but only works for certain problem domains

I’m sure there are other models, and would love if people would add some comments about how it works in their shops.  As much as I would like to say there is a solution to “architecture by org chart”, I think the best we can do is get the architecture to reflect the view from higher up in the org chart (c-level), so that it ends up including the entire organization and its needs.

Here is a great piece from Andrew McAfee of Harvard Business School that makes a point that technology matters.  Sometimes I think in our zeal to not focus on the technology we can forget that everything still needs to work.  In my own experience of doing software selection “shoot-outs”, even vendors with similar feature sets and Gartner ratings often have vastly different technology.

It’s a relief after investing millions in our Trading Grid to know that advanced technology still matters, even if its not the only thing that matters….

When I’m not on an airplane, I can occasionally be found leading a Cub Scout Den. Tonight, for instance, my Webelos played a game using compasses to navigate back and forth a circle of hundred feet in diameter. At each point in the game. The boys were given a compass bearing, which should point across the circle to a letter, which they would walk to. After reaching the letter, the boys would take a new bearing that you point them back across the circle to a different period. The game is won by getting six letters in the correct order on the basis of the compass bearings. What is interesting about this game is that you must do it one step at a time because you need the context of your last step to determine where to go next. The other interesting part of this game is that errors are cumulative, so once you’ve made one mistake, it’s likely contribute to downstream mistakes. As an example, some boys might start at the letter A. The first compass bearing is 32, which should take them across the circle to the letter X. However, some boys make a mistake and wind up at the letter L. This means their next bearing which might be 225 will be from the wrong point, increasing the likelihood of an error. You get the point. Since I want the boys to complete successfully, I periodically check their progress and help them correct mistakes. For the kids, this is actually a form of visibility or continuous business activity monitoring, although I doubt they thought of it this way.

The supply-chain business is very similar to this game in some ways, particularly in the compounding of mistakes. As new products or promotions are rolled out, some errors in forecasting or other planning creep in, and roll forward! At each stage in the process, there is a chance to either make new mistakes or compensate for old ones. You don’t need to worry about making new errors, that happens automatically — but compensating requires continous feedback. Since there are many participants in a typical supply chain, the feedback system that is most critical these days is “continuous visibility”. The idea behind continuous visibility is to leverage the many “signals” (sometimes called demand signals, although sometimes signals on the supply side are critical as well) being sent between participants in a supply chain to figure out what is happening — with an eye toward improving the situation. Vendors who specialize in this space are usually categorized as BAM, or business activity monitoring, vendors. But putting a complete system like this in place is not for the faint of heart, as it combines the toughest challenges of EAI and B2B into a single task — and then requires it be done in realtime to be worth doing at all! Having said that though, there is a path to follow that leverages the combined strengths of modern systems and existing assets. A good approach is to focus on detecting and managing events occurring in the supply chain, and correlating the events to detect patterns. Most BAM tools have great functionality in this area, and the younger market category of CEP (complex event processing) software is also very promising. But, sadly, most vendors assume you have a clean event stream to start with — which is rarely the case… In the B2B world, the document is king. Overwhelmingly the document is based on a standard like X12 or EDIFACT, but XML based standards are just as helpful here. Turning documents into events is a good way to get a basic monitoring system in play, and there are several ways you can go about it. Many high end EDI translators (including GXS’s Application Integrator) are capable of generating multiple files per document in translation (Application Integrator now generates an XML “meta-data” file by default, whose content is configurable), and they are also usually of accessing databases or making web service calls (but you have to watch for performance degradations, as these packages are very highly tuned for their core semantic processing tasks). The extracted data can usually be submitted to a BAM/CEP system using either asynchronous messaging or web services. Some B2B solutions, like Microsoft BizTalk, incorporate BAM capabilities directly into the package. If a company exchanges a complete suite of documents (from Order through Remittance Advice), events generated from that create a skeleton of supply chain activity that can be “fleshed out” through integration to other systems via traditional EAI or possibly web services. This is usually quite a bit more challenging than working with the documents, but also potentially lucrative since at this point you tend to have a good idea what kind of information is required. Within the GXS Trading Grid, we tend to generate events whenever we handle data, and then augment that activity with events “fired” from our key infrastructure and application services. Leveraging our centralized ESB (enterprise service bus), we can aggregate information flowing through it. In fact, a major focus continues to be generating ever more events to the “bus”, and making it easier to “see” what is going on. The patterns and practices for doing this emerged from work in our Managed Services environment, where we can achieve visibility into literally millions of documents that we manage — and we did it exactly the same way, starting with the documents and then integrating key systems one by one. Without a strong feedback loop in your supply chain, you might find yourself outpaced by former Cub Scouts who check their bearings often…

Catching up on email today, I came across a comment that an EDI professional posted about how frustrated she was with EDI!  In the well-written response to an ec-bp article, she shared her frustration:

“I have not been able to find a solution that would not be very costly to change to and would make life any easier than the way we currently do things. All customers want something different and it is getting more complex as time goes on.” 

In another section:

“Edi in my opinion did not standardize or uniform anything. For example you have hundreds of options on every document. You don’t have to have the same information on your advance ship notice as the other guys. You can request an 855 instead of a 997.”

Guilty as charged…

Like many industries, ours has focused so much on empowering users through advanced features and complete configurability/customization that it seems nothing is simple.  This is partially a consequence that the real drivers behind e-commerce are the PRACTITIONERS, who are often at the leading edge of supply chain practices, which sometimes get complicated.  As a service provider and a software vendor, we owe our customers powerful offerings that are as easy to use as possible.

But if we’re not there yet, we are trying — and you don’t have to take my word on it!  Many of our key initiatives over the past couple of years are targeted straight at the issues highlighted, including:

• Development of e-Commerce Accelerators to make it easier for small and medium businesses to connect into global e-commerce with the software packages that run their businesses
• Managed services that can accept most protocols and translate partner formats into whatever you want internally
• Integration to other software vendors’ products (like BizTalk R2, webMethods, etc) to give customers choices and allow them to use what they know
• Ever more flexible web forms solutions that leverage Web 2.0 technologies

Now, before you right this one off as a sales pitch, time to come clean — as I said, we’re not there yet (and neither is our competition), and here are some reasons why:

• Integration is still very tough.  Even with standard integration options, if customers have customized their own software, it can require professional services (ours or someone else’s) to get it all setup and working
• Mapping between standards, and customized usages of the same standard, is still hard.
• The world of e-commerce processes is still largely “un-standardized”.  There are no widely used methods of specifying the rules for which EDI documents a given partner uses, and in what order (RosettaNet PIPs were ground-breaking here, but many factors have limited adoption — including complexity)

So, is it hopeless?  Absolutely not.  More companies do e-commerce, and in particular EDI, than ever before — and at a lower unit cost than ever before!  Keep on going, and we will too, and keep voicing frustration and constructive criticism, because we’re not there yet…

In the time since SOA has become an “IT” technology (or pattern, if you prefer, since SOA is not so much a technology as a design pattern…), there have been some surprisingly vigorous debates about whether SOA implies ESB, is complementary to ESB, or is anathema to ESB.  I claim no objectivity here, as the GXS Trading Grid has been designed with a particular point of view on this topic, but first lets get our definitions clear…

SOA = Service Oriented Architecture.  Good luck getting agreement on a definition here, but I would say that is a method of architecting applications and systems using loosely coupled services working together to accomplish a purpose.  The trick is to do this in such a way that the services involved can be reusable, so that all of the inherent efficiencies of code reuse are realized.

ESB = Enterprise Service Bus.  Another one that is difficult to define, but at a minimum a standard asynchronous message bus that all or most of an Enterprise’s applications utilize to communicate.  The “ESB” was popularized by Sonic Software (a division of Progress Software), with their phenomenal product SonicESB (not many pieces of software can define a new category) — but now most EAI/middleware vendors (think webMethods, TIBCO, etc) have competitive offerings.

So is the relationship between SOA and ESB just some esoteric technology discussion?  No.

The root of the argument is that an ESB becomes a “backbone” through which all communications flow, and thereby tightly couples services via that backbone.  It may seem a small matter, but the “loose coupling” concept is key to SOA.  But, at least with the GXS Trading Grid, there is a “third way”, which borrows from both points of view.

GXS Trading Grid is GXS’s service infrastructure for providing B2B services to our customers and their trading partners (base level messaging to full-blown process collaboration, and everything in between) — but for my purposes here, it is a service oriented architecture.  Services are able to invoke one another in realtime to do “work” (this is referred to as synchronous, because the two services are working together at the same time, or in synchrony), which is typical for “immediate” processing like authenticating a user or checking the status of something.  This is implemented in the traditional model with independent services “talking” to one another directly (the agreed method of “talking” is the interface, or contract).

This is a really easy model to work with, but very challenging to scale, and scalability is our number one priority.  The reason this is challenging is that you have to have enough capacity to respond immediately (within microseconds anyway) on every service!  This is hard to do across the board.

To put it another way, it is reasonable to expect that a grocery store will have a can of chicken soup for every customer that wants one, but not that there will always be available checkouts — no matter how crowded the store gets!

The checkouts (and the deli counter, and the pharmacy) are asynchronous services, and they can scale very effectively (a store can open more checkouts, or increase staff at the deli).  However, there must be an infrastructure (the rows of cash registers, the deli counter), and that is the Enterprise Service Bus.

Because of its ability to handle load without loss (work queues up), and its dynamic scalability (a good architecture lets you add capacity on the fly), we build as much as we can in the ESB model (this is how we have implemented all of our on network translation capabilities, for instance).

By implementing a Service Oriented Architecture on top of an Enterprise Service Bus, you can have the virtues of SOA, with room to grow.

Read the rest of this entry »

In most areas of business software and services today, buyers face a choice between special, purpose-built software, and modules of more generic frameworks.  As a for instance, you want to manage a to-do list, so you can either use Outlook’s Task feature, or get a specific tool (or keep a list in Excel, but that is another blog post….). 

Likewise, when someone is looking to manage inventory, if they are an Oracle or an SAP shop, they can either buy the sister module for their stack … OR … get a “best of breed” piece of software from another vendor.  (As an aside, you should NEVER, NEVER, buy a module of a rival stack — believe me — just don’t do it…..!!!).

In the world of B2B, this problem is even more difficult to solve, as most B2B programs involve integration to internal systems (often via middleware).  Special purpose B2B programs tend to have excellent partner management, solid translation, and good orchestration capabilities…. but ….the business process management, analysis, and extensibility generally cannot hold a candle to the full-fledged platforms offered by webMethods (now SoftwareAG), TIBCO, IBM, BEA, Microsoft, and — increasingly — SAP.

This has led to a couple of approaches from the purpose built side

1. Build on top of a strong horizontal platform.  This is our approach in our partnership with webMethods/SoftwareAG, with our TG Enterprise Gateway offering.  The goal here is to deliver a specialized application for traditional high-scale B2B messaging on top of a flexible powerful framework (essentially having your cake and eating it too)
2. Expand the platform to become a full integration suite, and compete with the existing enterprise infrastructure vendors.  This approach works well for some environments, but creates tension in enterprises where there is a strong bus already in place.  It also has the unintended effect of reducing the effort expended to integrate to “competing” environments, reducing customer choice

On the other “front”, the large infrastructure players are trying to consume the B2B space, but face challenges of their own.  Things to watch out for include:

• solutions that are too “fine-grained”:  EAI is typically large numbers of small messages, requiring very fine control.  B2B on the other hand, tends to be characterized by much larger transactions (documents), but lower volumes.  Using a standard EAI approach is often sub-optimal
• machine to machine orientation:  EAI systems are often very geared to connecting systems, often using adapters.  Many will simply consider partners to be “systems”, and model standard protocols as “adapters”, but this is a problem because it can have the unintended consequence of tying a partner to a protocol, creating issues when a partner changes technologies
• in-line translation:  because they are optimized for high volumes, the focus of data transformation in platforms is operational efficiency.  The issue is that B2B mapping is quite a bit more complicated than EAI mapping, and the folks that do it are often not traditional developers.  Many products require mappers to use Integrated Development Environments (IDEs, like Visual Studio or Eclipse), which are often not the right tool for data transformation

The truth is that designing the correct solution for B2B is still very challenging, and the growing capabilities of the infrastructure platforms make it more challenging still.  For my part, if B2B is a major part of your IT operation, I still believe the base platforms are not there yet, but the gap is narrowing.  There is a lot of merit to the hybrid approach (a B2B product built on a strong general platform), but selecting the right approach still involves extensive evaluation and a strong knowledge of your own — and your vendors — technology strategy.

I spend a lot of time talking to large enterprises with vast networks of suppliers and customers, most of whom should be enabled as Trading Partners in a B2B program.  Beyond that, companies, industry groups, standards bodies, and the e-commerce industry have spent decades developing a dizzying array of options and techniques for getting partners “connected”, the latest of which are supplier portals and AS2, with large scale use of web services clearly visible on the horizon.

But in spite of this, as with the invention of ever more powerful processors, smaller and denser storage, or more efficient power generation, it is a task that will never be done, and for much the same reason — our very success creates new demand.

Now I am not talking about classic demand generation, which is about price.  In economics there is a moderately famous curve that shows demand increasing as price decreases, and that has certainly been a factor in B2B — but it has not been the major factor.  There is another demand pattern that is harder to quantify, but we’ve all seen it.  When a restaurant opens and attracts lots of people, other restaurants usually open across the street or parking lot.  But far from reducing waiting times or prices, the multiple restaurants usually attract more people and increase the demand for food. 

So what does this have to do with B2B?  There was a time when B2B was about eliminating the paper in the ordering process, but that goal is now one of many, and not even the primary goal anymore.  Once all that order information was digitized, we took a crack at shipping information, which created all sorts of interesting possibilities — which led to the first major transaction that did not have a paper opposite, the ASN (advanced ship notice).  ASNs helped make possible tremendous innovations in industries like cross-dock distribution centers (impossible without advanced knowledge of inbound shipments, and — of course — barcodes).

My point is that no one knew ASNs would be needed until they got the POs flowing (in truth, many organizations are not even using ASNs and barcodes effectively to this day).  Now we have new physical technologies like RFID, new approaches to managing information flows (BPM applied to B2B), and new business needs enabled by technology (BAM, business activity monitoring).

The good news is we are getting more information faster, and we are able to substitute “information for inventory”, but the bad news is that B2B is looking increasingly like internal IT — one continuous upgrade process.  Once we have orders automated, we want to manage the order process.  To make this happen we tie the physical supply chain (using barcodes or RFID tags) to the information supply chain — traditional documents and logistics documents.  At this point we want to start tracking performance over time and sharing the data with our partners . . . and on and on.

But unlike internal IT, which is an upgrade of one infrastructure, a new B2B capability needs to span an entire trading community, anywhere from 600 to 17000 companies (and that is only DIRECT relationships).  And that is why enablement is never done….