In my last blog entry here, I started a discussion of the technical challenges of using Spreadsheets as electronic business documents. I want to continue that discussion, but instead of focusing on how data is located predictably in the spreadsheet, I want to talk about separating the formatting from the business data.
As you might imagine, consuming Spreadsheets and producing them presents two different sets of challenges. When consuming them, the problem of locating the data in the spreadsheet predictably is the most significant challenge, next to data content concerns. The formatting (fonts, colors, shading, graphics, etc.) generally does not matter when consuming the Spreadsheets, whereas when producing them, it can matter almost as much as the data content. Continue reading →
Spreadsheets are a little bit like hammers: you can use them for almost anything. And, they’re a relatively simple mechanism so what could be hard about them…right? Humans seem to have a propensity to find new ways of complicating technology, and I think most of you have probably guessed that that applies to spreadsheets, too. I don’t expect that will ever change.
Spreadsheets are a natural choice for people who don’t want (or don’t have the time) to invest in more formalized options like EDI or XML. They’ve gotten a bad rap, perhaps because they’re arguably less sophisticated than the alternatives, but also because of the complication of dealing with them in an automated fashion.
Before we decided to add support for spreadsheets to our integration platform, we were asked by several prospects and even given some examples of what they needed to handle. These cases were, of course, quite varied and we thought about it for a while, wondering if we could come up with something that would be useful. Continue reading →
Many Business-to-Business (B2B) relationships choose to initiate transaction exchanges at the point a buyer sends an electronic purchase order to a supplier. This Purchase Order is often in the form of an EDI 850 document. This Purchase Order often then triggers the supplier to send the buyer an electronic Invoice (EDI 810) and an electronic Ship Notice (EDI 856), for the goods ordered. This “business process” represents the minimum number of transactions required to maintain this successful model. Moreover, there exists an abundance of data in support of this process, although it may often fail to be included in the production model. The cost of integration may exceed the return and, as a result, this data either isn’t shared between the two organizations or it fails to be integrated to a usable state.
For example, at the suppliers’ front end is Catalog data (EDI 832). This provides an opportunity for a supplier to identify the attributes of their products to the buyer, creating a more-efficient ordering process. At the buyers’ backend is Product Activity / Point of Sale data (EDI 852). This provides an opportunity for buyers to report their sales activity, aiding in the ability to forecast the production of goods. While this data is not essential to the “Purchase Order <-> Invoice” model, it provides the ability to “enhance” production processes. Additional transactions, such as Purchase Order Acknowledgment (EDI 855), Purchase Order Change (EDI 860), and Payment Advice (EDI 820), are a few of the many electronic formats capable of improving and furthering the overall business process integration. Continue reading →
How many times have we needed to format some data quickly and reached for our favorite spreadsheet application? I am just as guilty of this as you are. Or maybe we needed to send data to someone, but weren’t sure what capabilities they had to parse out a flat file. The spreadsheet has been the Swiss Army knife in our IT toolboxes for years.
As our businesses drive us to leverage integration to reduce costs, we typically look to the large implementations for ROI. However, there is some low-hanging fruit that just requires us to think a little differently about an age-old problem; dealing with customers that eschew technology. These are the customers that are still faxing orders to you. They do email, hopefully, but one thing they do know how to use is a spreadsheet.
Spreadsheets do have valuable integration use cases, both inside the business and externally. An application example that comes to mind is mining shipment data from a database and producing the data in a format suitable for business end-users. Dumping the data to a comma-separated-values (CSV) file is quite limiting in presentation control. Yes, the data is all there, but the end-user is still going to spend time “prettying up” the contents. Printing a report to PDF also gets the job done, but it’s still just a report. Wouldn’t it be useful to query the data and easily put it into a spreadsheet that encourages user interaction? This approach takes the data publishing paradigm one step further, enabling the end-user to interact with the data and empowering them to draw new insights that are beneficial to the business.
There are a number of blogs, discussion groups, podcasts, etc. talking about Service-oriented Architecture (SOA) and Service-oriented Integration (SOI). Instead of focusing on them individually, this blog focuses on using them together for better ROI results.
Service-oriented Integration (SOI) is the practice of using XML over HTTP (e.g. Web Services) to achieve interoperability between applications and services – for example, wrapping a legacy application function and exposing it to other applications, services, and business partners. Service-oriented architecture (SOA) encompasses architecture principles and best practices that guide the design and implementation of SOI, including methods that minimize coupling, complexity, and functional overlap. Most SOA initiatives start with the need to integrate an application; I believe the reason why companies fail and overspend on SOA initiatives is due to the lack of consideration for SOI and SOA together.