The post Auto Draft appeared first on Reality Check.

Note – This is a post authored by Rob Rowe, Sr. Manager, MDM Product Marketing, Software AG. I just helped in co-authoring the part about taming big data since I have already written on the topic before.

We’ve all heard about big data and there are numerous definitions of it. Suffice to say, it’s a lot of data from both inside the organization (e.g. ERP, CRM, application logs, etc) and outside the organization (e.g. Twitter, Facebook, and other social media, videos, news feeds, mobile apps, smart meters or other devices, etc). Whatever big data means to you, the real challenge is harnessing all this data and making sense out of it to provide real business value.

Enterprises today focus on application integration as data grows at an explosive rate everywhere. In order to tame such big data growth, traditional integration techniques may need to be complemented with newer design patterns such as in-memory data management platforms. An earlier blog post on this details this approach using three use cases.

With the explosion of data everywhere, Master Data Management (MDM) also becomes a critical point of observation. However, MDM works hand-in-hand with Big Data and is enabled by integration. There are two sides of this which we will explain. The first is using master data to provide “grounding” for the data, such as positively identifying the source of a social media stream. So for example, someone writes on Facebook that they are unsatisfied with a certain product. As it happens, it is YOUR product!  But, identifying this requires a Master Product repository. You also want to know who this person is so that you can investigate and rectify the situation.  This requires a Customer Master. You want to maintain brand integrity and customer satisfaction levels. So if this person is one of your customers, and they “liked” you on Facebook, perhaps to win a prize or receive a discount, then you not only have their “standard” customer profile information, you also have the supplemental information of their Facebook name. They are already in your database and you know who they are. You can contact them and resolve the issue, ideally in real-time, before your customer loyalty or your brand reputation is tarnished.

The second side of this is that big data can provide valuable information which can supplement the data that you’re already mastering. Yes, it works both ways. For example, let’s take a utility company that is mastering the location data of their smart meters, as well as the product data associated with the meters, transformers, and all the other important assets of the business. From the (big) data, integrated with the real-time analysis tools, it is discovered that a smart meter is no longer reporting its data. Because you are mastering location data, you know where this meter is, you know what type of meter it is, and you know what customer is affected. The call logs can verify whether the customer has already called in a loss of service. Having all this data allow the utility company to dispatch someone close to the troubles location, investigate the problem, and resolve it quickly, perhaps even before the resident comes home from work.

So as you can see, big data, master data, and integration together can produce valuable insight and real business value. Want to know more? Attend our webinar entitled “Taming Big Data and MDM with Integration” on May 15, 2013. You can register at http://www.softwareag.com/corporate/res/webinars/innovation/default.asp

The post Taming Big Data and MDM with Integration appeared first on Reality Check.

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.

To crisply state what was discussed in the report, here are the predictions -

• By 2016, midsize to large companies will spend 33% more on application integrations than in 2013.
• By 2016, the integration of data on mobile devices will represent 20% of integration spending.
• By 2017, over two-thirds of all new integration flows will extend outside the enterprise firewall.
• By 2018, more than 50% of the cost of implementing 90% of new large systems will be spent on integration.

I will let you read through the report to understand the details of the “whys”. However, my thoughts are in total sync and agreement on what has been said. Let us discuss a few reasons as to why these predictions are very realistic.

1. As discussed in a previous post of mine, Application Integration is more relevant today than ever. For reasons explained in that post, it only makes more sense that midsize to large companies will spend more on integration in the coming years.
2. Mobile is an explosive market. Every enterprise I have talked to, in the last six months, has “Mobility enablement” as one of their top priorities. It is just natural for them to treat the mobile interface as yet another composite application reaching into the backend to deliver the data and logic from various applications. So, integration spending is necessary in this regard.
3. Mobile and SaaS integrations lend themselves to the more critical requirement of being able to access your back-end applications from outside your firewall. Again, I concur with Gartner on the statement that more number of integration flows will extend beyond your DMZ.
4. With the explosive growth of SaaS offerings, companies will probably spend more time and money on integrating such applications than in actual development. So, it shouldn’t be a surprise if the last prediction comes true as well.

There is a lot of emphasis on B2B growth in the report. I agree with the assessment but I don’t think that that alone will be a major factor for some of the predictions. Do not under-estimate the mobile growth. As a matter of fact, it is going to enhance the B2B space as well.

The other thing that I really love in this report is the recommendation given to CIOs, Managers and Architects to focus on your ICC (Integration Competency Center) implementation. This is a favorite topic of mine. Maybe, in one of the subsequent posts, I will talk more on this. For now, I am signing off as it is getting close to the Welcome Reception at the Gartner AADI show. Look forward to more posts from the show. You can also follow my tweets from the show at my handle @AppInt4All.

The post Gartner Predictions 2013 for Application Integration: My take appeared first on Reality Check.

Of all the reasons as to why application integration is important today, let me tell you what I think are the top three reasons –

M & A activities – Many industries such as Retail, Wholesale & Distribution, Communications etc have had increased M & A activity compared to October of last year. With each acquisition, an organization inherently acquires all the IT assets of the acquiree. This just adds more complexity to an already complicated IT landscape of the acquiring company. Imagine dealing with two systems of record, redundant CRM applications and multiple customer masters! On top of all this, there will be a lot of new systems that the acquirer will have to support as well. In essence, the IT team at the acquirer needs to have a strong integration plan in place ahead of the actual acquisition to support the seamless on-boarding of the IT assets of the acquiree. A well-established integration infrastructure can help in off-boarding legacy or redundant applications and also in on-boarding new or acquired applications. Without this, the IT team will end up with writing a lot of point-to-point code and this could translate to a lot of time, cost and resources.

Consolidation efforts (Data Center / ERP) – In the last few years, every company has gone through some form of consolidation as a part of its cost-savings initiatives. With the advent of superior virtualization technologies, a lot of companies have been able to reduce the number of data centers or physical servers they had to a handful of virtualized servers. From an application landscape consolidation standpoint as well, companies have adopted a single ERP (SAP, Oracle or something similar) as their system of record. They have been able to eliminate a lot of their redundant applications by consolidating to this ERP solution. Both forms of consolidation discussed here demand a strong need for an integration backbone, without it it may become very difficult for the organization to adopt such a change.

Cloud adoption – Needless to say, adopting cloud-based applications or a cloud-based infrastructure has become a key trend in today’s IT world. Almost every company today is looking to, if not already, adopting a SaaS application for one of its core business functions. Even though the cloud solution can solve a lot of problems for the company, the SaaS application itself becomes another integration endpoint. Remember that it contains data and interfaces critical for other applications to connect with the IT landscape. Again, application integration becomes highly relevant in this context to allow for easy connectivity with such SaaS applications from its on-premise counterparts.

The industry analysts and pundits may end up calling Application Integration by a different name next year but the core values it  brings to the IT evolution still remain critical and relevant. Start looking at your IT landscape and see if you are prepared for any of the these changes in your organization. Where else do you see application integration being more relevant in your organization?

The post Is Application Integration Dead? 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.