<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://rossmason1.ulitzer.com"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>Latest News from Ross Mason</title>
 <link>http://rossmason1.ulitzer.com/</link>
 <description>Latest News from Ross Mason</description>
 <language>en</language>
 <copyright>Copyright 2012 Ulitzer.com</copyright>
 <generator>Ulitzer.com</generator>
 <lastBuildDate>Thu, 17 May 2012 17:34:25 EDT</lastBuildDate>
 <docs>http://backend.userland.com/rss</docs>
 <ttl>360</ttl>
<item>
 <title>Top Ten Pitfalls of P2P Integration to Avoid in the Cloud</title>
 <link>http://rossmason1.ulitzer.com/node/2028259</link>
 <description>While integration isn’t necessarily a new problem, the unique challenges of integrating in the cloud require a new approach. Many enterprises, however, are still using point-to-point (P2P) solutions to address their cloud integration needs.&lt;p&gt;&lt;a href=&quot;http://rossmason1.ulitzer.com/node/2028259&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Fri, 21 Oct 2011 14:45:00 EDT</pubDate>
 <guid isPermaLink="true">http://rossmason1.ulitzer.com/node/2028259</guid>
 <comments>http://rossmason1.ulitzer.com/node/2028259#feedback</comments>
</item>
<item>
 <title>Integration Causes SaaS Customers to Rethink Cloud Strategy</title>
 <link>http://rossmason1.ulitzer.com/node/2007441</link>
 <description>With the increasing use of SaaS applications and the move towards hybrid architectures, cloud integration has become a mission-critical priority for the enterprise. The challenges of cloud integration have led some SaaS customers to rethink their cloud computing strategies while deterring prospective customers from adopting SaaS in the first place. More than ever, there is a crucial need for cloud integration solutions--and SaaS users are looking to SaaS vendors to provide them. 
Although SaaS vendors recognize that integration is a major obstacle for end users, they don’t always invest the time and resources needed to develop cloud integration technologies and solutions. And their reasons are perfectly understandable. &lt;p&gt;&lt;a href=&quot;http://rossmason1.ulitzer.com/node/2007441&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Wed, 05 Oct 2011 10:15:00 EDT</pubDate>
 <guid isPermaLink="true">http://rossmason1.ulitzer.com/node/2007441</guid>
 <comments>http://rossmason1.ulitzer.com/node/2007441#feedback</comments>
</item>
<item>
 <title>What Is iPaaS? Gartner Provides a Reference Model</title>
 <link>http://rossmason1.ulitzer.com/node/1933285</link>
 <description>It&#039;s no secret that cloud integration is one of the main challenges facing today&#039;s enterprises. In order to meet the growing need for secure and reliable cloud integration solutions, several vendors have started to offer integration services known as iPaaS, or integration Platform as a Service.
iPaaS is a cloud-based integration solution that is steadily gaining buzz, but - as with other cloud offerings - it is important to look beyond the hype for actual substance. One sure sign that iPaaS is securing its place as a legitimate category in the cloud computing stack is Gartner&#039;s slew of research publications in the past several months on iPaaS, the most recent of which is the &quot;Gartner Reference Model of Integration PaaS.&quot; This growing attention is a good sign for iPaaS vendors, but a few people may still be unclear about what iPaaS actually is or does. &lt;p&gt;&lt;a href=&quot;http://rossmason1.ulitzer.com/node/1933285&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Tue, 09 Aug 2011 10:15:00 EDT</pubDate>
 <guid isPermaLink="true">http://rossmason1.ulitzer.com/node/1933285</guid>
 <comments>http://rossmason1.ulitzer.com/node/1933285#feedback</comments>
</item>
<item>
 <title>Integration Providers Respond to the Cloud&#039;s Challenge</title>
 <link>http://rossmason1.ulitzer.com/node/1904114</link>
 <description>As enterprises deploy SaaS and other cloud technologies, they are confronted with the challenge of integration. It is hard to ignore the impact of the cloud, but responses among integration technology providers have varied.
Integration veteran David Linthicum sees 3 categories of data integration providers: the &quot;do nothing about cloud computing&quot; providers; the &quot;integration on the cheap&quot; providers; and &quot;the cloud is everything&quot; providers. The &quot;do nothing&quot; providers have largely refrained from moving into the cloud, offering traditional integration solutions that are on-premise and rich in features while the &quot;integration on the cheap&quot; providers are approaching cloud integration from a tactical perspective.
The &quot;cloud is everything&quot; providers are cloud-centric, responding to the new integration challenges of the cloud by aggressively developing on-premise and cloud-based solutions with connectors to leading SaaS, PaaS and IaaS offerings. Linthicum recommends integration solutions from these providers since they are more likely to stay current with changes in the cloud space than other providers.&lt;p&gt;&lt;a href=&quot;http://rossmason1.ulitzer.com/node/1904114&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Wed, 13 Jul 2011 13:00:00 EDT</pubDate>
 <guid isPermaLink="true">http://rossmason1.ulitzer.com/node/1904114</guid>
 <comments>http://rossmason1.ulitzer.com/node/1904114#feedback</comments>
</item>
<item>
 <title>Connecting the Dots: The Social Web, Cloud Computing and Integration</title>
 <link>http://rossmason1.ulitzer.com/node/1904035</link>
 <description>These days it seems nearly impossible to talk about the enterprise without mentioning the words &quot;social&quot; or &quot;cloud.&quot; At first glance, social networking sites like Facebook, Twitter and LinkedIn and cloud computing services like Salesforce.com appear to be separate and distinct technologies from a business as well as technical standpoint. One thing that both technologies have in common is that their growing popularity is putting pressure on enterprises to join the bandwagon and adopt them.
On the social side of things, sites like Facebook and Twitter allow companies to communicate marketing messages to customers through direct channels while professional networking sites like LinkedIn streamline the process for recruiting talent. Yammer, an enterprise social network, works much like Facebook but is limited to users within a business organization and thus not available to the public. With Yammer, employees can post updates about projects they are working on, ask questions, and share links, making it easy to connect and collaborate with co-workers in real time.&lt;p&gt;&lt;a href=&quot;http://rossmason1.ulitzer.com/node/1904035&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Tue, 12 Jul 2011 11:56:00 EDT</pubDate>
 <guid isPermaLink="true">http://rossmason1.ulitzer.com/node/1904035</guid>
 <comments>http://rossmason1.ulitzer.com/node/1904035#feedback</comments>
</item>
<item>
 <title>Top 10 Pitfalls of P2P Integration to Avoid in the Cloud</title>
 <link>http://rossmason1.ulitzer.com/node/2055729</link>
 <description>While integration isn’t necessarily a new problem, the unique challenges of integrating in the cloud require a new approach. Many enterprises, however, are still using point to point solutions to address their cloud integration needs.

In order to tackle cloud integration successfully, we need to move beyond point to point integration and avoid repeating the same mistakes. To aid in that effort, here is a list (in no particular order) of the top 10 pitfalls of P2P integration to avoid repeating in the cloud:

1. Building vs. buying: If you have developers with integration experience in your IT department, you can have them build a custom P2P integration in-house rather than buy a packaged solution. Building your own integration, however, typically means that you will also have to manage and maintain a codebase that isn’t central to your business and is difficult to change.

2. Quickfire integrations: Let’s say you need to integrate two systems quickly and hire a developer to work on the project over a couple of days. You notice an improvement in business efficiency and see an opportunity to integrate additional systems. You hire the same developer and expect the same quickfire integrations, but the complexity of the project has increased exponentially. The takeaway? It’s always a good idea to approach integration systematically and establish a plan up front rather than integrate your systems in an ad hoc point to point fashion.

3. Embedding integrations in your application: Although it might be tempting to embed P2P integrations in your web application, you should be cautious about this approach. It may be fine for really simple integrations, but over time, your integration logic becomes scattered in different web apps. Instead, you should think of integration as a separate tier of your application architecture and centralize this logic.

4. Creating dependencies between applications: When you integrate applications in a P2P fashion, you create a dependency between them. For instance, let’s say you’ve integrated App A and App B. When App A is modified or updated, you will need to change the integration that connects it to App B. You also need to re-test the integration to make sure it works properly. If you add App C to the mix, your workload can increase exponentially. 

5. Assuming everything always works: One of the consistently recurring mistakes of doing quick P2P integrations is assuming that things will not break. The reality is that integrations don’t always work as planned. As you integrate systems, you need to design for errors and establish a course of action for troubleshooting different kinds of errors. Error handling is particularly troublesome when integrating SaaS applications because you have limited visibility and control over the changes that SaaS vendors make to them. 

6. It worked yesterday: Just because P2P integration worked for one project does not mean it will work for another. The key is to test each integration you build. Unfortunately, P2P integrations are often built and deployed quickly without sufficient planning or proper testing, increasing the chances for errors. Although it can be difficult and does require a decent amount of effort, testing integrations is absolutely critical. 

7. Using independent consultants: Many companies are not staffed with developers who have enough integration expertise and hire consultants to resolve their integration issues. The problem with this approach is that you often have limited visibility into whatever the consultant delivers. If you need to make changes you typically need to work with the same consultant, which is not always possible. 

8. Creating single points of failure: As your P2P integration architecture grows in size and complexity, its chances of becoming a single point of failure in your entire network increase as well. Minimizing the potential for single points of failure should be a priority when it comes to integration, but the lack of decoupling in a P2P approach makes it hard to eliminate bottlenecks in your system. 

9. Black box solutions: Custom built P2P solutions are usually black box in nature. In other words, they lack reporting capabilities that tell you what is happening between systems. This makes it very hard to debug problems, measure performance or find out if things are working properly.

10. Creating a monster: Quick P2P integrations are relatively manageable when you have 2 or 3 systems to connect, but when you start adding other systems, your architecture quickly becomes a complicated mess. And because no two P2P integrations are exactly the same, managing your integrations becomes a major pain. If you invest in doing some design work up front, however, this will save you from having to throw away a tangled P2P architecture and starting from scratch to find a new solution under pressure. If you have a well thought out design and a simple architecture, you can reduce the management burdens and costs associated with integration.
&lt;p&gt;&lt;a href=&quot;http://rossmason1.ulitzer.com/node/2055729&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Wed, 31 Dec 1969 19:00:00 EST</pubDate>
 <guid isPermaLink="true">http://rossmason1.ulitzer.com/node/2055729</guid>
 <comments>http://rossmason1.ulitzer.com/node/2055729#feedback</comments>
</item>
<item>
 <title>Top 10 Pitfalls of P2P Integration to Avoid in the Cloud</title>
 <link>http://rossmason1.ulitzer.com/node/2055730</link>
 <description>While integration isn’t necessarily a new problem, the unique challenges of integrating in the cloud require a new approach. Many enterprises, however, are still using point to point solutions to address their cloud integration needs.

In order to tackle cloud integration successfully, we need to move beyond point to point integration and avoid repeating the same mistakes. To aid in that effort, here is a list (in no particular order) of the top 10 pitfalls of P2P integration to avoid repeating in the cloud:

1. Building vs. buying: If you have developers with integration experience in your IT department, you can have them build a custom P2P integration in-house rather than buy a packaged solution. Building your own integration, however, typically means that you will also have to manage and maintain a codebase that isn’t central to your business and is difficult to change.

2. Quickfire integrations: Let’s say you need to integrate two systems quickly and hire a developer to work on the project over a couple of days. You notice an improvement in business efficiency and see an opportunity to integrate additional systems. You hire the same developer and expect the same quickfire integrations, but the complexity of the project has increased exponentially. The takeaway? It’s always a good idea to approach integration systematically and establish a plan up front rather than integrate your systems in an ad hoc point to point fashion.

3. Embedding integrations in your application: Although it might be tempting to embed P2P integrations in your web application, you should be cautious about this approach. It may be fine for really simple integrations, but over time, your integration logic becomes scattered in different web apps. Instead, you should think of integration as a separate tier of your application architecture and centralize this logic.

4. Creating dependencies between applications: When you integrate applications in a P2P fashion, you create a dependency between them. For instance, let’s say you’ve integrated App A and App B. When App A is modified or updated, you will need to change the integration that connects it to App B. You also need to re-test the integration to make sure it works properly. If you add App C to the mix, your workload can increase exponentially. 

5. Assuming everything always works: One of the consistently recurring mistakes of doing quick P2P integrations is assuming that things will not break. The reality is that integrations don’t always work as planned. As you integrate systems, you need to design for errors and establish a course of action for troubleshooting different kinds of errors. Error handling is particularly troublesome when integrating SaaS applications because you have limited visibility and control over the changes that SaaS vendors make to them. 

6. It worked yesterday: Just because P2P integration worked for one project does not mean it will work for another. The key is to test each integration you build. Unfortunately, P2P integrations are often built and deployed quickly without sufficient planning or proper testing, increasing the chances for errors. Although it can be difficult and does require a decent amount of effort, testing integrations is absolutely critical. 

7. Using independent consultants: Many companies are not staffed with developers who have enough integration expertise and hire consultants to resolve their integration issues. The problem with this approach is that you often have limited visibility into whatever the consultant delivers. If you need to make changes you typically need to work with the same consultant, which is not always possible. 

8. Creating single points of failure: As your P2P integration architecture grows in size and complexity, its chances of becoming a single point of failure in your entire network increase as well. Minimizing the potential for single points of failure should be a priority when it comes to integration, but the lack of decoupling in a P2P approach makes it hard to eliminate bottlenecks in your system. 

9. Black box solutions: Custom built P2P solutions are usually black box in nature. In other words, they lack reporting capabilities that tell you what is happening between systems. This makes it very hard to debug problems, measure performance or find out if things are working properly.

10. Creating a monster: Quick P2P integrations are relatively manageable when you have 2 or 3 systems to connect, but when you start adding other systems, your architecture quickly becomes a complicated mess. And because no two P2P integrations are exactly the same, managing your integrations becomes a major pain. If you invest in doing some design work up front, however, this will save you from having to throw away a tangled P2P architecture and starting from scratch to find a new solution under pressure. If you have a well thought out design and a simple architecture, you can reduce the management burdens and costs associated with integration.
&lt;p&gt;&lt;a href=&quot;http://rossmason1.ulitzer.com/node/2055730&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Wed, 31 Dec 1969 19:00:00 EST</pubDate>
 <guid isPermaLink="true">http://rossmason1.ulitzer.com/node/2055730</guid>
 <comments>http://rossmason1.ulitzer.com/node/2055730#feedback</comments>
</item>
<item>
 <title>Top 10 Pitfalls of Point-to-Point Integration to Avoid in the Cloud</title>
 <link>http://rossmason1.ulitzer.com/node/2055779</link>
 <description>While integration isn’t necessarily a new problem, the unique challenges of integrating in the cloud require a new approach. Many enterprises, however, are still using point to point solutions to address their cloud integration needs. 

In order to tackle cloud integration successfully, we need to move beyond point to point integration and avoid repeating the same mistakes. 
&lt;p&gt;&lt;a href=&quot;http://rossmason1.ulitzer.com/node/2055779&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Wed, 31 Dec 1969 19:00:00 EST</pubDate>
 <guid isPermaLink="true">http://rossmason1.ulitzer.com/node/2055779</guid>
 <comments>http://rossmason1.ulitzer.com/node/2055779#feedback</comments>
</item>
<item>
 <title>6 Predictions for 2012</title>
 <link>http://rossmason1.ulitzer.com/node/2117949</link>
 <description>Ross Mason, CTO and Founder of MuleSoft shares his six IT predictions for 2012.&lt;p&gt;&lt;a href=&quot;http://rossmason1.ulitzer.com/node/2117949&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Wed, 31 Dec 1969 19:00:00 EST</pubDate>
 <guid isPermaLink="true">http://rossmason1.ulitzer.com/node/2117949</guid>
 <comments>http://rossmason1.ulitzer.com/node/2117949#feedback</comments>
</item>
</channel>
</rss>

