Industry Context

CIOs of B2B companies are faced with many challenges. They are to build more applications, at a faster pace with fewer resources. They have to integrate broader and deeper sets of data. All while being compliant and ensuring security. Employees must be enabled on the road; suppliers have to be brought closer to the organization. Communication channels have vastly expanded. Architecture models have proliferated, modernized and evolved.

Value Proposition

The solution: agile applications, delivered in a hybrid way, with end-to-end methodology delivered via measurable ROI. Software AG Live is a platform with 3 interlinked capabilities that deliver business agility and time-to-value, precisely addressing the challenges in the B2B space. The platform allows for the rapid development of applications that adjust to evolving business needs, their integration with legacy ground or cloud based systems and the business process documentation thereof.

Target audience

Focus for Software AG remains the Global 2000 and governmental audience. However, due to the lower barrier of entry that cloud represents, aspiring mid-sized companies will now also be able take advantage of Software AGs’ history of innovation. Beyond its traditional IT base, Software AG Live is particularly attractive for the business analyst profession and subject matter experts. Not only will they be able to design processes unique to their business area with Process Live (available Q3 2013), but they will also be able to implement them with AgileApps Live (available now). Finally corporate IT will be able to integrate these with existing systems using Integration Live (available Q1 2014).

As-a-Service

In developing our cloud proposition, Software AG paid particular attention to getting the service experience right. Amongst others, AgileApps Live, based on the recent LongJump acquisition, comes with self-service purchasing, automatic on-boarding and zero delay to deployment. This service orientation will be extended to the rest of the suite, a unique experience in the PaaS sector.

Differentiation

Three things allow Software AG Live to stand out. Firstly, on-premise, private cloud and public cloud are treated as equals. In other words 40+ years of on-premise innovation are now also available in the hybrid cloud. Second, data privacy and security are at the forefront of the service delivery experience. Diligence is given to ensure data is treated according to the world’s most comprehensive data protection laws and standards, which are further supported by leading security processes and technology. Finally, Software AG live is a unified platform with integration between its various sub-components.

Market promise

Software AG Live will …

1. Allow Capex to Opex transformation
2. Have returns measured in agility and time-to-market
3. Protect investments through high information security and data privacy

The post Introducing Software AG Live! A different approach to cloud computing that will stir up the PaaS market 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.

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.

Introducing Big Data’s cousin Big Services. What you never heard of Big Services? Well Big Services is perhaps a little shy. OK being a little tongue-in-cheek here but services are proliferating very very fast. And the business opportunity is just as big as taming Big Data.

Services are not a new concept; they started as design guidelines to creating reusable services, evolved to Service-Oriented-Architecture (SOA), and the now to API management. What is amazing is that we are in the age of service proliferation – by one measure public services that can be accessed over the internet are doubling every year and that excludes the hundreds of thousands of services inside the enterprise. Add to this the whole new suites of Software-as-a-Service (SaaS) offerings it becomes a nightmare to even know how many services are out there.

The sheer volume of services is one reason we could call them “Big Services”, but it is the complexity of the different service interfaces, issues of access and control, monitoring, lifecycle management, governance and access that make them really Big Headache Services!

Consider SalesForce.com which has one API (well that seems easy enough) but has a 1,000 page document describing how to access it (OK not so easy). Workday’s opposite approach of publishing 100’s of API’s with 6 or 7 versions. Each WSDL and schema is unique, with different data types (which many need translation form one API to the next), different dependencies (ordering of API calls make a big difference to the end results) and different security and access requirements.

In order to keep track of these Big Services (Volume and complexity) is no easy task. There is a need for software to help you do this. The software needs to provide repository services and a level of abstraction that ensures you work at solving the business problem at hand and not the complexity of the services call. Naturally the software needs to take care of error handling (like what to do if the service is unavailable), monitoring (like checking if the API is available and the average time per call), lifecycle management (like which version of the service to call) and a host of other service security and dependency checking needs. It comes down to whether you have time to build this software of buy it from a trusted partner.

Big Services are creating Big Opportunities: Online services such as Google, Facebook, Netflix and eBay are handling billions of application programming interface (API) calls per day and some companies are accounting for billions of dollars in revenue per year via API links to their services, according to John Musser, founder of ProgrammableWeb. Enterprises are finding that exposing their systems to the world as services create amazing opportunities, just like Best Buy who allows shopping and fulfillment via their API’s, or the EPA which serves up hundreds of self-service APIs that handle air quality to UV index monitoring, or 7-Eleven who exposed coffee purchase API information to determine the results of the election. It isn’t a matter of if, but a matter of when you expose your services to the self-service world, but if you don’t you will miss this BIG services opportunity. Naturally exposing internal systems as services creates its own set of Big Services Headache – stopping denial-of-service attacks, securing the service, publishing the WSDL and documenting the interfaces, and providing access to these services across the mobile and web world.

How will you take advantage of this Big Services opportunity, and provide your business with Big returns?

The post Big Data Meet Big Services 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.