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.

Whether you’re focused on improving business processes and integration, or looking for new strategies around Big Data or transactions, this one global event will inspire you with groundbreaking innovation and insights.

• Learn how you can transform your organization into a Digital Enterprise that acts faster in ever-changing market

• Discover how to capitalize on mobile, social, cloud and big data while leveraging your current IT investments

• Visit product-specific Innovation Worlds on ARIS, webMethods, Terracotta and Adabas-Natural

• Engage with hundreds of peers, valued industry experts, and inspiring digital leaders

This one international event is for everyone interested in IT-driven innovation centered around delivering business value and solutions people never thought possible. Register today and take advantage of the early bird savings.

The post ProcessWorld is now Innovation World! Register Today. 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.

In my role, I have the privilege of meeting with exceptionally bright customers to hear what they are doing. Most of these customers tell me that they are witnessing the effects of the nexus of 4 forces – Mobile, Social, Cloud and Big Data. A lot has been written about the nexus of the four forces – Mobile, Social, Big Data, and cloud. But, I think more importantly it’s not just that the forces exist, but what are these combined forces creating?

From what our customers are seeing, we believe these forces are creating proliferation of 3 key assets: Data, Services and Devices. It is this proliferation that is pushing integration to be the key focus for all new applications.

Data Proliferation

Big Data is everywhere and the newest and probably hottest area in the marketplace but integrating this big data is key to deriving business value. Data integration can be as “simple” as creating a single view of the customer – basically creating a single logical record of the customer data across the enterprise so that all interactions with the customer are consistent, and all relevant data is considered as part of that interaction. As one of our customers who is in the pediatric healthcare business put it, this single view isn’t a nice to have but it saves lives by ensuring all drug interactions are known and factored in from their pharmaceutical, surgical and ER systems. But, data integration can be much more complex, involving statistical pattern matching, algorithmic correlation and producing a model that predicts whether a particular transaction is safe or fraudulent. No matter what the application, if you are talking about data proliferation you probably need some form of integration to bring this all together.

Services Proliferation

My prior blog entry on “Big Services”  describes this area, but consider a relatively simple transaction of shipping a product from your favorite online retail site – there is probably dozens of services that need to be integrated together to provide a seamless experience – Customer data from one or more services, product data from another service, logistics data from the warehouse, preference list from a predictive analytics service, shipping time from the shipping service, credit verification from the card issuer, etc. This is a very simplistic view since products usually come from one or more partners, and the logistics and product availability is derived from warehouses across the globe. Net net, though, is that integration of these systems is key to ensuring that the customer has a great experience.

Device Proliferation

Much has been said about Bring your own Device (BYOD) and the need to have applications that address iOS, Android, Windows, web, and the multitude of screen sizes, but the real device proliferation is around the “Internet of Things”. Integration of the information these devices create is a key enablers to new applications. Consider another customer of ours who is in the recycling business. They integrate GPS data with telephony data, and create an application where customers can view where the recycling truck is and alert the customer when their recycling container has been picked up via a text message. Again, it is the integration that makes this application interesting and compelling.

What This Means for You

Integration is the application, and it is only through integration of existing assets that new compelling applications can be created that provide differentiated value. You need to have a plan and partner that takes the proliferation of data, devices and services into account and allows innovation through integration, only then will you truly have applications that take your business to the next level. Conversely. I challenge you to find the application that has no integration!

The post Integration is the Application appeared first on Reality Check.

Regardless of the industry, size or company, the “four forces” are enabling businesses to transform processes and technology platforms in fundamental ways. These forces are driving new business models, new sales channels, and new ways to attract and engage with customers. By leveraging these technology trends, organizations can provide better insight into the business to plan more effectively and better predict everything from demand to the delivery of goods and services.

But the question is, how do you adopt the latest technology trends to innovate quickly, while limiting the impact on your existing investments and IT infrastructure?

Integration is key.

Why Integration? Because the best approach for adopting new technology trends is to leverage your existing business logic, IT systems and services. And integration makes it possible to leverage these investments while allowing  you to adopt new technology trends quickly, with less risk and reduced redundancy in data and logic. Businesses have made tremendous investments in their current IT infrastructure and want to protect and maintain these investments by limiting potentially disruptive or risky initiatives in order to adopt the latest trends.

Register for one or all of a series of webinars that explore this topic. Whether your organization is adopting one or all of the 4 forces or developing new technologies for mobile applications, public APIs, enterprise social collaboration, big data analytics or addressing data quality, partner onboarding, or process automation, this series of webinars will provide insight into how you can drive “Innovation through Integration.”

The post Innovation through Integration: It’s back and more relevant than ever 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.

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.

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.