When talking about integration, whether it is application to application (A2A), business to business (B2B) or data and cloud integration, the goal is to exchange data, documents, information, and/or messages between a source and a target. To accomplish this goal, we identify business patterns related to the sources and targets of these “integrations” and then apply the identified patterns to similar scenarios that meet specified criteria. Most, if not all of these patterns will require data mappings, also known as “maps” or “rulesets”, at some point during the integration process. These maps are ultimately used to perform one of two operations: to transform or translate data. I often use the terms, transform and translate, interchangeably. But, is there more to them? Are these terms synonymous, or do their meanings differ?
Let’s look at this a little closer to see if there is a difference. Data translation can be defined as the process of converting data from one syntax to another and performing value lookups or substitutions from the data during the process. Translation can include data validation as well. One example of data translation is to convert EDI purchase order document data into purchase order database files or even flat files while performing data validation on the source data. Continue reading
First it was personal digital assistants (PDAs) and then it was cell phones… now the world is starting to embrace tablets. We live in a world where we are more “connected” than ever before. Our devices cater to immediate gratification by offering access to our email, the spontaneous purchase from Amazon and even faster communication with texts and tweets. Personally, I am excited that soon I will be able to start my washing machine from my iPhone! Since we’re tethered to our devices, it was inevitable that the business world would recognize the opportunity to improve the efficiency of managing our day-to-day operations.
But how can we leverage this wonderfully connected, always online technology to manage our digital landscape better? To understand the opportunities, let’s think about our daily experiences in our “personal life” with our connected technologies and then draw some parallels to our “working life”. In our “personal life”, we receive emails, texts and monitor Twitter feeds of our favorite sports teams, celebrities or passing interests. When things happen in the world, as long as we are “subscribed”, we can be notified about them. Continue reading
Now that we are well past the hype of Web Services, what can they do for your company? Before we answer this question, let’s clarify what Web Services really are.
One traditional definition states that they are any service available over the Internet using a standardized XML messaging system and not tied to any operating system or programming language. In the early days this was true, but the definition has evolved over the past decade. The World Wide Web Consortium (W3C) defines Web Services as a software system designed to support interoperable machine-to-machine interaction over a network. Gartner defines them as “a software component that can be accessed by another application (client, server, another Web service) through the use of generally available, ubiquitous protocols and transports (HTTP).” Continue reading
When I think about integration, the first thing that comes to mind is application to application integration (A2A). Gartner states that application integration aims to make independently designed application systems work together. Their definition applies to my interpretation of A2A integration, which is the connection of disparate applications both inside and outside the firewall, regardless of location (including the Cloud). This interpretation includes integration between a few or many applications and encompasses all integration aspects such as, communications and messaging, translation and transformation, routing, process automation, data access and even extends to application access. This can apply to scenarios such as transaction replication or process activation across applications, providing web access to legacy applications and publishing information to mobile devices. Most of the integrations between these disparate applications used to occur by means of proprietary APIs, messaging or a combination of both. This can still be the case, but a larger percentage of integration today is mediated by integration middleware or via web services. Continue reading
Some of the most difficult challenges that integration projects face are what I like to refer to as “artifacts of black-box implementations.” These artifacts include incomplete specifications (both from external sources such as vendor specification or internal sources due to a lack of understanding of the interrelationships between systems), opaque processes from lack of visibility and undocumented integrations. Opaque processes and undocumented integrations present the greatest challenge because necessary information is not available due to ineffective communication, absence of the original source (often a single person) or integrations with legacy systems where there is no more vendor support. Most processes enabled by commercial applications are opaque. If you can’t determine (because it’s undocumented) (a) the identities and locations of all data that is added or updated by the process; (b) the rules under which data changes and additions occur; and (c) the identities and locations of all downstream applications, modules, and services that are invoked, then the process can be considered, to some degree, opaque. Continue reading