Today, there are four approaches when it comes to cloud integration. Let us look at them one-by-one and understand the pros and cons of each approach.

1. Point-to-point integration – This is the quickest and dirtiest approach in the book. This is when your developers have an all-night hackathon to create scripts and code snippets to connect one application with another (cloud or not). This model may work with a small company where only two or three applications need to be tied together. As is obvious, this approach is not scalable at all by any means. Code maintenance, upgrades and future development soon become nightmares. You can forget about IT agility to business needs as the company starts to expand.
2. On-premise integration solution – This approach can be easily adopted by companies that already have an integration infrastructure / Enterprise Service Bus (ESB) in place. They can just leverage the existing integration platform to connect with on-premise applications as well as SaaS applications. This is provided that the integration solution that you are using has such capabilities and framework to connect with any SaaS application seamlessly. Otherwise, you will end up having more developers coding their way out of this. The other point to also consider is that this is not a cloud solution.
3. iPaaS (Integration Platform as a Service) – In the last couple of years, this model has been gaining some maturity and attention amongst small companies. Enterprises that do not want to spend much on their infrastructure but still be more agile, adopt SaaS applications as needed. As an extension to the same methodology, the same enterprise also adopts an integration solution hosted by the solution provider themselves. This is called an iPaaS. This allows companies to not worry about setting up, maintaining and managing a complex integration infrastructure to integrate with SaaS applications. On the same note, I should also emphasize that an iPaaS is not a replacement for an ESB. As a matter of fact, Gartner predicts that more and more companies are going to adopt a hybrid integration infrastructure comprising of both an on-premise ESB and an on-cloud iPaaS.
4. Cloud Services Brokerage – This is very similar to the iPaaS except that in this case, even the development and maintenance of the integration maps and services are done by the solution provider themselves. Only very few small vendors offer this type of solution. This model has not caught on to the mainstream market yet. Not a lot of companies are willing to trust outsourcing their entire integration development to a third-party. So, for the sake of this conversation here, I am not going to spend any time on this topic.

There is no such thing as the “ideal way” of how you should integrate with the cloud but there are definitely right and wrong ways of doing so. Given the four approaches above, you are better off with either option 2 or 3 based on the size of your IT department, your application infrastructure, your existing integration architecture and future growth plans. iPaaS will definitely give you greater flexibility in scaling up your integration infrastructure based on how your business grows. But, in the interim, as you step up to adopt an iPaaS, a hybrid architecture of option 2 and 3 together might be more beneficial for various reasons. We will discuss this in a later post in more detail.

Software AG launches Integration LIVE (iPaaS)

With the acquisition of LongJump, Software AG has positioned itself in a very strategic position to guide its 4000+ customers in addressing the cloud integration challenges. As a part of its most exciting launch of version 9.0 set of products in June 2013, it will be releasing webMethods CloudStreams, which addresses bullet #2 in the above list of approaches. For more information on that product, you can click on this link.

Today, Software AG announced an even more exciting future plan for our cloud strategy – Software AG Live, the first cloud-based Platform-as-a-Service (PaaS) suite. Amongst the three components that make up Software AG Live, the one that is of interest in this particular scope of conversation is Integration Live. This is an integration PaaS which enables cloud-to-cloud integration and seamlessly connects with private cloud or on-premise Enterprise Service Bus (ESB) installations. Integration Live will offer an unmatched combination of ease-of-use and enterprise-strength and will be compatible with webMethods Integration Server, the market leading ESB from Software AG. Availability is scheduled for Q1 of 2014.

The post Software AG announces launch of Integration LIVE (iPaaS) solution appeared first on Reality Check.

Business Intelligence is a thing of the past. Companies used to look at their past performance and understand their mistakes or achievements. In today’s world of tweets and posts, even news agencies can’t keep up with the speed at which information is traveling across the world. Enterprises need to be extremely proactive rather than being reactive. So, a few years ago, the concept of Social Business Intelligence was introduced. There is abundant information available in all the petabytes and zetabytes of social feeds across all social networks. The ability to single out the right channel, to kill unnecessary noise and to make sense of the remaining social information into actionable metrics is called Social Business Intelligence. For example, a retail company monitoring specific social feeds of its consumers can understand that they actually prefer its newly introduced product in red more than blue. Using this data, it can instantaneously prepare its supply chain to ship its next batch of products in red rather than blue.

However, there are inherent challenges with gathering such social data. To start with, social data is not structured. Consider a tweet such as this – “Love the fit of #Gap’s new #slimfit #jeans. Zipper not smooth”. How do you associate a metric with such a tweet? Is it a positive tweet or a negative tweet? How do we classify this tweet to make predictive intelligence from this? To address this, we have many tools out there that perform “Sentiment Analysis” on such social data. This type of analysis assigns weights and scores to social data and makes the data more meaningful for Social Business Intelligence dashboards.

There has also been another trend in the last couple of years – an increase in adoption of social media platforms within enterprises. This can span just within employees or even with customers and partners. These tools help in keeping collaborative teams closer and well-informed. And, this is where I will introduce Social Business Intelligence 2.0. The social feeds have grown to gargantuan proportions that they have created silos of Big Data by themselves. Next, the information in such social data is not useful freestanding on its own. They need to be cross-referenced with other data stores in the enterprise such as Product Master, Customer Master, Pricing database, Support Center application etc. This is the way that coherent information is created from such chaos.

Let me give you an example of such a Social Business Intelligence 2.0 scenario. Customer X logs in a support ticket about a system failure in one of their servers. The support system instantly posts a note about that ticket into the corporate social feed under the support channel. Since a few stakeholders such as the Account Manager, Systems Engineer and on-site consultant have subscribed to this specific customer’s posts, they get notifications about the post and are aware that the customer has an issue. They can immediately call up the customer expressing their interest in addressing the issue ASAP. This increases the level of customer satisfaction as well. But, what has also happened behind the scenes is that there were three other similar issues (with the same component) raised by three different customers in the past 1 week. But, those were not trouble tickets but just social posts in support forums. The correlation is made between the various social posts and a social notification is sent out to the relevant R&D team automatically. Members of that team see that post, understand the problem and release a fix immediately addressing the issue. Next, an automatic notification goes to each of those affected customers’ technical contacts indicating the availability of this fix, which addresses their problem.

Yes, I know that sounds like a fairy tale and hardly ever happens that way in any company. But, that is not wholly true. There are quite a lot of companies that are leading the charge on such initiatives and making great strides in bringing such solutions to reality. What I want you to focus on is the underlying technology to make this happen. First, yes, you need a social platform that can primarily connect everyone together. Also, the APIs of this social platform should be open enough that it can be called from other applications or from the integration platform. Second, you will need a correlation engine or a Complex Event Processing (CEP) engine that can associate disjoint data and identify patterns in them. The third most critical thing you need in such an environment is an integration backbone or an Enterprise Service Bus (ESB). This will be the glue that connects all of the moving parts in this environment together.

An ESB within a collaborative enterprise helps in enabling Social Business Intelligence 2.0 by –

• Understand and parse structured / unstructured data from various social sources
• Integrate social data from various sources into a correlation engine or a sentiment analysis engine
• Connect up with various Master data sources and lookup databases within the enterprise. This will help in classifying social data into relevant taxonomies.
• Integrate support systems, R&D systems etc with social data streams so that automatic posts can be sent into appropriate channels based on incoming / inferred data
• Pump all metrics and social analytics data into dashboards to create real-time actionable views for relevant stakeholders

An ESB can also leverage complementary technology such as in-memory management solutions to process Big Data effectively. Social Business Intelligence 2.0 is already here. I urge you to start considering your integration backbone / ESB as an effective platform to launch it within your enterprise today.

Until next time, Ciao!

The post Social Business Intelligence 2.0: Driven by Integration appeared first on Reality Check.

Infrastructure has always been a significant problem but companies seem to be handling it quite well with cloud-based models and virtualized servers. Now, that brings about its own set of challenges from an integration problem. But, that is not the topic of this post.

There is an even bigger challenge at stake today – Data. Companies are growing at the rate of 120% their data volume year-over-year. With such explosive growth rates of data, companies are battling the classic challenges of latency, data handling costs, real-time access, analytics and something real hot today – BIG DATA!

An ESB, as we know, is fundamental to a large and growing infrastructure. And, an ESB is also critical to address most of the data challenges above. However, not every ESB in the market has the capability to solve such issues. As a consumer, do NOT be misled by terms such as “high-performance” or “highly scalable”. Every vendor loves to use those terms lavishly. So, to clearly distinguish the ones that can actually deliver from the ones that are just claiming so, you need to understand what is it that makes an ESB so scalable to solve such BIG data problems.

The root problem of all the key data challenges is the sheer volume of it. If the ESB needs to cater data back and forth between various applications, it needs to have the capacity to handle such bulk loads of data in memory. Yes, you may have heard about design patterns that can handle streams of bulk data so as to not overload the ESB. However, those patterns may not be applicable in a variety of use cases where you need the bulk of the data to be available in totality. I will discuss such key scenarios below.

But, before we get to the scenarios, let us understand one thing clearly. To process such large volumes of data (> 10 GB) in real-time, ESBs need a lot of memory to work with but they do not have the capability to manage all that memory by themselves. It is not the function of an ESB. However, very few of the top notch ESBs can actually work hand-in-hand with an in-memory database (IMDB) or an in-memory data management platform to handle such complex scenarios easily. Some even come bundled with an IMDB. An IMDB is different than the traditional disk-oriented relational databases in that all of the data resides in the main memory of the machine where the IMDB is installed. The IMDB is based on an optimized algorithm that executes much faster in memory and so, data retrieval / storage have no noticeable latency. The main advantage of an in-memory database is that you are no longer delayed by costly database reads/writes and are not tied down by disk latency issues.

Scenarios to explain how an ESB can scale up and scale out with an in-memory database –

• Mainframe or AS/400 data access too expensive and poor response – There are many companies that have adopted a legacy system as their system-of-record. In which case, every single data update or read has to go to the legacy system. This is not only time-consuming and expensive but also hurts IT agility when it comes to rapidly changing business needs. Bringing in an ESB in between can solve some of the point-to-point connectivity issues and ease up on onboarding / off-boarding of other systems in the environment. However, if you are still going to the legacy system for every single query / update, then having the ESB is not helpful here. Now, bring in an IMDB and turn on the ESB’s capability to work with it. You can now bring in a significantly large amount of the most-commonly used legacy data into the IMDB using the ESB and save up on a lot of time going back and forth to the legacy system. The IMDB will take care of updating the legacy system asynchronously with its incremental updates. The ESB can now serve up any application with information from the legacy system, which is now available readily in memory. This is truly a “high-performance” promise.
• In-memory analytics of diverse data sources – This is similar to the above use case, only that the data in this case is mostly read-only and also might come from multiple data sources. The most important criterion is that the related data from such diverse sources needs to be available for real-time analysis. Again, you have to imagine real huge volumes of data (Hundreds of GBs of data). This scenario is very common in the Finance industry (Credit card fraud detection) or in Healthcare (Patient telemetric data). The question about which analytics tool to use is not relevant here since the key challenge is to bring in all these data points collectively in real-time with very little or no latency. The ESB can naturally connect with all these data sources and pull in such data effectively. However, to deposit all that information in real-time for the analytics tool to read, it will leverage the IMDB.
• Large file processing – When IT has to process a large file (> 10 GB in size), it is usually done as a nightly job so as to not impact the performance of any system or database during regular hours. However, there are scenarios when we need to process a large file like that during regular business hours. Also, the other requirement for this scenario might also be that you may need a really large chunk (if not all) of that data to be available in memory for parsing, validation and cross-reference reasons. Again, the ESB may have native capabilities to parse that file format very easily. But, to enable the ESB to read such a large chunk of the file in one shot, an IMDB is necessary. This scenario can be quite common in the Retail space (Initial Product Master load), High-tech manufacturing (Test data, supplier files etc) or in the Financial industry (Trades).

So to sum it up, when you ask an ESB vendor on how their product scales up and if they answer – “Throw in more memory” at it, question that immediately. As you now know, an ESB by itself cannot manage all that memory. It is constrained by whatever JVM or CLR constraints it is allowed. Even if your architect thinks that they can tweak the JVM parameters to use up more extended memory, remind them that the garbage collection (GC) process only takes longer and slows down the ESB even more when more memory is included. You need more sophisticated technology like IMDB to allow for very large main memory access, storage and clean-up. IMDBs have their own GC management and hence, do not rely on native JVM GC techniques. As a result, they are very fast.

Go ahead and power up your ESB. Build up an Application Integration Strategy. Give your ESB a shot in the arm by pairing it with an IMDB, if you run into any of the above mentioned scenarios or one where you see a need for such technology. When you get into more Big Data scenarios, this approach discussed here (as well as in this other post by a colleague), may serve as a possible solution pattern to that problem but may not be the entire solution. There may be other challenges that you may encounter that you typically do not see in your day-to-day use cases within your industry vertical. Topic for a different day! Write to me about some of the big data use cases that you have encountered.

Sayonara!!

The post Tame Big Data with your ESB appeared first on Reality Check.

In this day of high-speed growth and scale, organizations need to be prepared with a plan to keep up with such changes. In a matter of mere days, new hardware infrastructures are prescribed and acquired. Public and private clouds make it even easier to setup such infrastructures. CIOs are adding new SaaS applications by the dozens and retiring existing legacy applications. All these changes mean only one thing for the IT manager – Insomnia! But, it need not be. Here is my one key recommendation to plan for high-speed growth and scale in 2013 –

“Build an application integration strategy TODAY, if you already don’t have one”

Before I go on to explain how you build one, let me quickly tell you why this is important. Without an application integration strategy, you will keep on building point-to-point connections between systems. This only leads to more chaos and any change in this architecture only means high expenses for time and resources. The most successful and highly-performing organizations definitely have a good application integration strategy in place.

There are 5 basic things that you need to consider when thinking of an application integration strategy –

1. Start with the fundamentals – Setup an ICC (Integration Competency Center). Some of you may groan at this suggestion but I have seen this as a highly productive investment of time and effort in building a company’s integration strategy. Without appropriate governance, anyone with an idea will adopt their own integration methodology and soon, you will end up with a similar situation of point-to-point connectivity or even worse, disconnected silos. Ken Vollmer from Forrester has written a fantastic article on how ICCs help solve integration complexity.
2. The best way to connect systems is to disconnect – As silly as it may sound, the best advice you can get on this is to create a decoupled architecture. By tightly binding data and applications silos with one another, you are only complicating the architecture more. A decoupled architecture is one where one application is agnostic of another application’s presence or preference of connectivity. For example, if you have to send a piece of data from your ERP into Siebel, the ERP can fire the message onto an Enterprise Service Bus (ESB) and forget about it. Siebel will receive that message if it has subscribed to that message topic. This architecture is also known as pub-sub or Publish-Subscribe. This is immensely helpful because, tomorrow, if Siebel gets replaced with Salesforce.com (SFDC), no code needs to be rewritten. The ERP will still fire the message the same way. However, SFDC will now subscribe to the message topic now. As is evident, this architecture allows for greater flexibility, scalability and higher developer productivity.
3. If you are not re-using…that would be amusing – Definitely think SOA (Service-Oriented Architecture) when building upon an application integration strategy. SOA allows for maximum re-use when building your integration logic. This means less resources and more available time for other projects.
4. Think canonicals – This is one of my pet peeves that developers or even architects do not think about using canonicals when building upon an integration strategy. Canonicals are fantastic models to be leveraged to create extensible integrations between two or more complex applications. When you are dealing with two or more complex or large data structures, you will see that you are spending a good chunk of time in mapping the same set of fields or writing custom logic to same field that is named in different ways in different data sets (e.g. FirstName, FName, Name, CustomerName etc). Canonical will act as the flat representation of the superset of all data fields in your integrations. Applications will then connect to the canonical instead of creating new data structures every time they need to be connected with a new system. System-level changes can be easily accommodated with this approach.
5. Use design patterns – One solution does not fit all. If you are an architect, you probably already know what I am going to say in this section. I have seen companies with large IT development teams building integrations with absolutely no design pattern in mind. That is so wrong! Design patterns are established blueprints for success. If you have complex data exchange needs, you need to know for sure what design patterns you are going to use. Design patterns help in reducing complexity and in boosting performance of your integrations.

With that, I want to wish you all a healthy and happy new year!! As you read in my other post, 2013 is the year of application integration. So, be prepared and create an integration strategy. Go on! Connect the world now!!

The post Application Integration Strategy for 2013 and beyond appeared first on Reality Check.

I had already covered a good set of factors to consider and also a basic checklist to start off with in my earlier post titled “Help! My data is up there…”. Please review that for sure. But, after visiting the recent Gartner AADI event in Las Vegas, I wanted to revisit this topic and elaborate on a few more factors to consider. Specifically, there are three important things that will stump any vendor that is just cloudwashing you and not really offering a true cloud-based product.

1. Upgrades – The primary way that you are going to integrate with a SaaS application is via its API or service that it exposes. However, considering that it is a cloud application, upgrades to the product will happen at a much quicker pace than a traditional on-premise application. But, as a consumer of its API, you should not get affected by the periodic changes that happen to the application and inherently, its API too. Understand the frequency of their upgrades and how they manage the API changes. This will be your single biggest maintenance nightmare when it comes to Cloud Services Integration. However, your integration solution should offer you the ability to upgrade to the newer versions of the API seamlessly without making changes to the consumers. So, use that as a major selection criterion for your cloud services integration solution.
2. Testing integrations – This will be a key requirement for your cloud services integrations as well. This is something that a lot of companies overlook, thinking that they have a strong testing methodology already in place. Testing integration flows over the cloud and across multiple SaaS and on-premise applications is quite different and very challenging. Most of the SaaS application providers may not offer much in terms of testing, except for sandbox type accounts and servers. However, to solve your problem of testing an integration flow that spans across multiple SaaS and on-premise applications, you need to find out if your cloud services integration solution offers this capability. The solution should be able to perform not just unit testing of such flows but also be able to do other tests such as regression testing and load testing.
3. Governance – I briefly touched on this topic in my checklist in my other post. However, this topic can take up a few posts of its own. Governance, as Massimo Pezzini told me, is a set of processes set up to help make decisions. It is also the most widely misused term and can sound confusing in any context. So, let me explain as to what Governance means in this context and why it is important. Within the realm of SaaS applications and other cloud providers, usage-based billing and subscription models are quite common. Given that, your cloud services integration solution needs to track usage of all the service consumption that happens. This helps in identifying bad logic creating costly SaaS API consumption, rogue services using unnecessary bandwidth and also in reconciling with your SaaS providers usage claims. On top of this, Governance has a bigger play in providing a mediation layer for all service consumption. This layer will enforce all types of policies including but not limited to SLAs, Security, Availability, Consumer Identification etc. Use this as your single biggest criterion for selecting a Cloud Services Integration solution.

So, the next time some vendor asks you if you need the works for their Cloudwash session, just cut to the chase and make them sweat. As for my next post, let me know what else you would like me to blog about within Application / Cloud Integration. Adios!

The post “Standard or Premium Cloudwash, Sir?” – New factors for Cloud Integration appeared first on Reality Check.

As an IT director / manager / CIO of a company, you need to sit up and read this if you say yes to any of the following. And if you say yes, rethink your integration strategy.

You get high with flat-file based exchange!
As mentioned above, flat files may not always be the scalable solution given the complexities of today’s IT environment. So, rethink!

Your developers start playing punk-rock every time two applications need to be connected
If your IT team is developing point-to-point code every time two or more applications need to be connected, then you are spending a lot of time, money and resources. So, rethink!

When business asks for a quick change, you start rolling up your sleeves…to do a project plan!
Agility is fundamental for an IT organization. If you are unable to have quick turnarounds for all business change requests, you probably do not have a good integration middleware in place. So, rethink!

You have no idea who will lose their job when you turn off that 20-year old application
Ironically, a lot of IT managers do not know their IT landscape that well. As a result, they are unable to confidently off-board an old application just because they are not sure of the impact. Leveraging good EA (Enterprise architecture) modeling tools can also help understand how applications are connected in your environment. So, rethink!

When your CIO says that you are adopting a new SaaS CRM, you say goodbye to your family for the next 6 months
On-boarding a new application should not be complex and a several months-long effort. With a loosely coupled architecture in place with your integration middleware, adopting a new application should be fairly easy and not painful. So, rethink!

When you say that all your systems are “connected”, what you don’t want to say is that you have a real hairball on hand!!
Sometimes, application integration is misconstrued or just implemented incorrectly. IT managers find it difficult to accept that they have a hairball of point-to-point connections on hand. If you don’t untangle it now, you are going to have a bigger mess soon. So, rethink!

All this is relevant and will make more sense when you start planning for growth and scale. In my next post, I will discuss the five important things to consider for a scalable integration strategy.

The post Have you Changed your Approach to Integration? appeared first on Reality Check.

Over the last 20 years, integration grew to encompass more than just pure inter-connectivity. It grew to include: data, events, and processes. Integration vendors called the integration piece a “bus” and loaded the bus with MDM (Master Data Management), CEP (Complex Event Processing), and BPM (Business Process Management).

In the past 10 years technology evolved to make integration easier. On top of ease-of-integration, huge culture changes have influenced how we interact with technology. The first digital generation is hitting the workplace. Mobile and always-on behaviors are driven by consumers not workers. And, the implosion in the job market has caused a lot of deep changes in what people consider working.

Imagine that each of these SaaS/Cloud applications were those original enterprise applications. Only now, instead of connected across a corporate network, they’re connected across the Internet.

Now, picture the opportunity to rebuild the bus, data, events, & process integration stack internet-wide (with all the requisite changes that such an architecture demands).

Can I get a hallelujah?

The post Here’s the Opportunity appeared first on Reality Check.

A few weeks later, he called me again and this time, he sounded perplexed. Business was not able to get a single view of the customer; Sales reps were taking longer to enter opportunities; Reporting was still a challenge. Problems galore! It was as if the cloud move did not quite help at all. Ironically, the SaaS application had become yet another data silo in their organization!!

So, before you have your head up in the clouds, here are a few data challenges you want to consider for data management in the cloud:

Your data has left the building - Once you adopt a SaaS application in a public cloud model, your data is no longer in-house. Be prepared to deal with data residing outside your DMZ (firewall). This is a major concern for a lot of companies that are considering cloud adoption. Specifically, if your company is in an industry that has a higher level of scrutiny and regulations, this becomes a sensitive topic. However, it does not mean that you cannot go cloud at all. Appropriate measures need to be taken to protect your data even if it is on the cloud – Think secure storage and the possibility of even encrypting your data in dire situations.

Security is a key concern – A related topic to the point above. Data is invoked and consumed via interfaces or services. So, make sure that you have a tight access control mechanism set in place. Authentication and authorization models need to be strictly enforced to protect sensitive data from getting exposed accidentally. More importantly, put together a data governance model. The more you adopt SaaS applications, the more you will end up using services to work with the applications and inherently, their data. So, plan for a SOA Governance model as well throughout the organization.

How often should I synchronize my changes with the rest of my systems? As simple as that question seems at the outset, it is actually tricky to answer. Almost all of the SaaS subscriptions charge you based on number of service invocations or at least limit you to a tier of calls that you can make within a month. Considering such limits, it is prudent for you to measure how often you access your SaaS application since each call has a cost factor. The other factor to consider is latency. Your network bandwidth will definitely play a key role on how quickly you can access your SaaS data. So, if you are thinking of synchronizing your cloud data with your on-premise data as quickly and as often as possible, cost and performance are going to hit you right in the face. Rather than re-inventing the wheel, leverage a leading ESB (Enterprise Service Bus) solution to solve this problem for you.

Data integrity and consistency issues – But then, you cannot stay away from synchronization due to the issues stated above because soon enough, you will run into data integrity & consistency problems. It is not really a catch-22. You just need to strike the right balance. This situation is no different than an on-premise integration problem involving a mainframe, for example. What you need to figure out is your system of record. Is it the one on the cloud or an on-premise data store? Once you figure that out, you can sort out the push/pull pattern of data, its frequency and update mechanisms. Moreover, this is where a really robust integration middleware solution can help you in keeping your cloud data and on-premise data in perfect sync.

Other key data questions to be answered – Apart from the above factors to consider, there are still more questions to answer before you decide how to handle your data on the cloud. For instance, here are a few:

• Should you treat your transactional vs non-transactional data differently? If so, how?
• If your system of record is on the cloud, do you need a copy of your master data to be made available elsewhere?
• Is the SaaS application data represented in XML or some proprietary format?
• Should data be pulled or pushed from/to the cloud-based systems?

Next Steps – So, if you are planning to integrate a SaaS application into your existing IT landscape, start planning for data challenges immediately.

• Create a quick checklist based on the factors discussed above.
• Set integration goals / objectives on what needs to be achieved from a business standpoint. For example, Business objective – Sales reps should not enter opportunity data in multiple places. IT goal – Sales reps will enter opportunity information only on SaaS CRM, which should then sync data automatically with on-premise ERP and lead-tracker database.
• Data flow diagrams are always efficient to figure out which application integration patterns to use.
• Engage your enterprise architect and your data architect to come up with a plan to help meet your goals.
• Leverage a integration middleware solution such as an ESB to enable connectivity between your cloud and on-premise application.
• Plan for data and SOA governance.

Until the next post, adios! In the meanwhile, talk to me about other data challenges you have faced in a situation like this.

The post Help! My Data is Up There… appeared first on Reality Check.

Okay, I may have been a bit dramatic there but the reality is that companies are adopting SaaS applications by the dozen everyday. Personally, in the last 3 years, I have seen the mentality of an average IT manager in the Bay Area mature from skepticism to fear to apprehension to acceptance when it comes to moving functional applications to the cloud. Third party industry analysts have seen the same surge in adoption of SaaS applications. The purpose of this post is not to validate this trend but to understand why companies are doing so and also, if they are doing it for the right reasons. In this post, I will address SaaS, PaaS and IaaS in the same breath when I say cloud adoption. I will go into their differences in a later post.

On-premise infrastructure cost savings – If at all anything, this is what companies consider as the #1 reason for adopting the cloud. The common belief is that by moving to the cloud, the company can save thousands of dollars in infrastructure and support costs. It may be true but remember that cost is not the only factor that should determine a move to the cloud. One should first consider if the move actually aligns with the business benefits that the company plans to reap with this approach. As a matter of fact, one could even argue that the NPV (Net Present Value) of on on-premise solution may be lower than a cloud-based solution if it is a long-term investment!

Options to scale massively – This is probably the #2 reason that companies give for adopting the cloud. Yes, if you need to increase your throughput multi-fold or setup a test bed temporarily with 1000 instances of your application, it is easily possible with a cloud infrastructure. The on-premise solution is not even imaginable on these grounds.

Operational costs savings – If you have too many support / maintenance staff along with an army of developers that support custom enhancements for a single application, then that might be right candidate to move into an equivalent cloud-based solution to save on all the operational costs.

Build vs buy decisions – There is no better time to start talking about the cloud than at the start of a brand new project. With hardly any CAPEX on the cloud project, you have the flexibility to roll back the project if it does not go well.

Loosely coupled architecture – When adopting cloud-based solutions, you have more open connectivity options (WSDL, SOAP etc) than proprietary interfaces. This helps in enabling / extending your SOA landscape and also, to create a more loosely coupled architecture for future growth.

And then, there are a few companies that just move to the cloud because everyone else is doing it. These companies are the ones bound to fail. Hopefully, after going through the list, you understand that adopting the cloud and cloud-based applications is not so bad after all. So, the next time you have that nightmare, it is important that you remind yourself that your cloud strategy is well-aligned with your business benefits. As for the CIO calling you honey, I can’t help you with that!

Last words of wisdom – Take it slow. I have seen a large high-tech manufacturer in the Bay Area adopt a cloud strategy over the last three years over several phases. They have moved 11 of their 18 core applications like CRM, HR, Healthcare etc into the cloud over the last three years. It takes time since cloud adoption comes with its own set of challenges. I will cover some of the key data challenges in this regard in my next post. In the meanwhile, tell me what are some of the challenges that you or your company faced during the process of cloud adoption.

The post Who Moved my CRM? appeared first on Reality Check.

Which makes you wonder how Forrester came up with a simple Wave graphic summarizing a very sophisticated technology space? Trust me, there’s quite a detailed criteria, 109 questions to be exact. Forrester also required detailed briefings, demos and reference calls with customers who are using the rated products in productions.

How is it, that a product conceived 14 years ago, before the ESB category even existed, becomes the number 1 leader in the ESB category today? If you are an enterprise that uses webMethods products, you are very familiar with the corner stones of our ESB platforms – webMethods Integration Server and webMethods Broker. webMethods Integration Server was developed more than a decade ago but it’s original vision and architecture have proven to be amazingly durable. Since its inception in 1997, long before SOA became a common approach, webMethods Integration Server has been service oriented. A service is the basic building block. This simple yet flexible approach combined with powerful connectivity with existing applications and external partners allowed customers to use it as a single platform for Application Integration and B2B Integration. As integration approaches grew more business-focused, SOA and BPMS became popular. It was natural for us to extend webMethods Integration Server with webMethods Mediator and add CentraSite to round out capabilities needed for SOA and BPMS. In the last release, we continued to expand webMethods Integration Server into new software architectures with native support for RESTful services, Events and Complex Events Processing.

It feels great to be in a position where we can give customers the choice of where they start and how they build their middleware infrastructure without forcing them to choose among several incompatible products. One key reason we are in that position is because of our customers and users who are among the most talented and vocal IT professionals out there. We listen to them carefully. Without their feedback – positive and negative – it is unlikely our products would be where they are today.

Now, as we turn our attention towards helping customers connect with and use Cloud applications, we are confident our ESB platform will continue to be a great investment for our customers. We once again find that webMethods Integration Server’s service-oriented foundation is a great fit for cloud computing. We have internally adopted agile approaches to building products which allows us to react to customer needs faster. We have some terrific ideas in the pipeline. And we have customers who will push us even further.

The post What’s the Secret to Being a Forrester Leader in ESB? appeared first on Reality Check.