We hear so much these days about agile enterprises and agility in software, but what does that mean? An agile enterprise responds quickly to unexpected opportunities, buys companies and spins some off. It changes the product line to accommodate surprise trends, and can change its business processes almost overnight. While the spirit may be agile, the constraining element is invariably the underlying IT infrastructure’s ballast. The word “ballast” is defined as a heavy material used to enhance stability. That was definitely important in the late 1990s and early 2000s when companies needed to consolidate their disperse infrastructures and applications. The integration architectures that are prevalent today came from that era, but the ballast has outlived its usefulness. Organizations simply cannot be responsive when changes in the integration infrastructure are measured in months and years rather than minutes and days.
How are these companies going to keep up with competitors that were invented after the Internet grew up? They must be able to leverage their proven experience and valuable existing applications on a new playing field, and the way to do it is to replace the ballast with Agile Integration Software [AIS].
Stone Bond Technologies, LP has identified the following 10 elements that can help you identify an AIS. Some of these points will be found in special-purpose platforms such as standards-based B2B like EDI, limited scope integration around a particular endpoint like SAP, or SOA platforms. Remember, though, that we are looking for enterprise-level software that suits more than 90 percent of the integration needs of the enterprise, and allows it to keep up with and even outrun the youthful new competitors. You will find that all 10 of these characteristics must be present and working together, in order to deliver the agility your organization needs to be competitive.
Click through for 10 elements that can help you identify agile enterprise integration software, as identified by Stone Bond Technologies, LP.
While “off-the-shelf” may not always be explicitly the case, it can be used as a reasonably good “rule of thumb.” If it takes days or weeks to install, that’s a good indication that the software has multiple discrete components that most likely do not work as a cohesive holistic solution, one that would not be able to meet the next nine qualifications. After all, this is about agility. Fast implementation and configuration of the environment means the ability to respond to corporate change more quickly. Long, slow installation processes, by themselves, negate the concept of agility. Upgrades and updates for AIS are automated, as opposed to requiring laborious and repetitive manual efforts.
This feature is absolutely essential to agility. You must be able to define virtual relationships across dissimilar sources in seconds or a few minutes, and then define mapping to your destination quickly. While you design the relationships and mapping, the associated run-time components should be generated so that you can validate and test as you go. Even better, if you want these interfaces to be bi-directional, the necessary metadata and run-time components should also be generated for you. At run time, the data from multiple sources is accessed live, aligned, transformed, and sent, as specified, to the destination.
It is inevitable that some mapping of data among sources will be more complex than can be done with logic that is built into any mapping user interface. Handling those situations will require ad hoc code fragments or pre-built analytics. AIS will have standard code editors built in that can be accessed from various places within the construction of integration.
You will be able to compose small (or large) functions that can access and act on any information involved in the integration. Wherever it makes sense to be able to include custom code, you enter the code editor and test it in place. As part of the solution you are building, AIS will manage the code, store it with the other mapping or process definitions (“metadata”) and ensure that it gets assembled in the right place. For example, you may be mapping fields A and B to destination field C, and the built-in capabilities do not meet your requirements. You should be able to enter the custom code option, and build and test the code. When the transformation engine maps those fields, it will execute your equation.
Since the development time of integration projects is such a huge component, AIS has many angles that help to reduce the time and effort. You should be able to see any integration object (metadata) you are building validated as you are building it, advising you of things that you have not completed, and errors you may have introduced. You should also be able to test it from the same environment.
For example, as you build a mapping of sources to destinations, you should be able to see live data at the endpoints to make sure you select the right fields, and see constant validation as you define relationships and formulas. Once you have finished the mapping, and no errors show up, you should be able to push a button and see the results of the mapping from live test systems. If something doesn’t look right, you can simply fix it and try again.
AIS cannot rely on XML-based XSLT transformation engines. These require that the data, regardless of its native format, must be converted to XML before it passes through the transformation engine, and must be converted from the XML output to whatever the destination requires. This means effectively that there are two transformations that have to happen, one on either side of the XSLT conversion. Doing this means additional development and additional steps at run time, which will impact performance. It also means that the transformation engine simply cannot coordinate the processing of virtual relationships across disparate systems.
AIS eliminates the classic adapter, which is the source of much re-programming, and replaces it with intelligent “dynamic adapters.” Dynamic adapters, called AppComms, are able to discover the schema from the specific instance of an application as opposed to making assumptions.
It is important to have a single environment within which to build, test, modify, and monitor an integration solution. AIS requires that a person configuring an integration be able to test end-to-end and deploy without leaving the environment in order to minimize the speed of implementation and to reduce maintenance costs. All the metadata that define the data access, business rules, and triggering events is generated and managed from that single user interface.
AIS must include the ability to define data workflow logic in the same environment and must make both the data logic and the workflow logic and information available for use throughout the AIS at run time. You will find the same philosophy of automating behind the scenes, embedding code, reusability, design time validation, and integrated testing. A separate tool for workflow will not support the fluid end-to-end information exchange at execution time.
Discussions about security of an integration environment generally focus on security of data as it is being moved, and on ensuring correct end-user permissions when accessing data that has been extracted from an application.
AIS adds another dimension to the infrastructure security capabilities. By eliminating the need for leaving the development environment to add custom code, and by having the execution centralized, AIS ensures a locked-down infrastructure where it is impossible to tamper with the underlying integration infrastructure by changing code, metadata, mapping, or other integration objects without being tracked. Every change that is made to any integration object has an audit trail of time stamped “who did what.” Users of the development system not only have granular permissions/restrictions granted with respect to activities, but also to system or process accessibility across the enterprise. This is critical in certain environments such as government and health care.
Any ISV should be able to provide all of this capability to their applications and customers. Because of its compactness and ability to scale, not just up, but also down, AIS is embeddable or can be called from any application, so that ISVs can provide integration as part of their solution. EAI’s cumbersome nature and time to implement, as well as its price point, make it impractical for ISVs to incorporate it into their offerings. Technically, EAI has no hope of being embeddable.
Some ISVs require their customers to perform the integration necessary to their backend systems or to populate a dedicated database for its use. Customers may use EAI, ETL, custom code, or whatever is familiar to them. Many times, this is a prohibitive exercise that causes ISVs to lose sales. AIS, by its nature, is easy to embed or to package with an offering.
For example, AIS embedded in SharePoint 2010, provides full CRUD (Create, Read, Update and Delete) capabilities including cross-application virtual relationships. Any WSS 3.0 application or Web Part can get the same functionality via an AIS ADO.NET driver (Full CRUD). For older applications that use OLEDB, the AIS functionality is available read only with the OLEDB driver.
Once an integration infrastructure is in place, the great challenge for corporate agility is rapidly incorporating changes without incurring significant risk and disruption. The imperative comes from mergers and acquisitions, changing business direction, or just an upgrade to a new version of software. The IT infrastructure has always been an impediment to the agile company because technologies for integrating software, data sources, and business partners cannot support or withstand much change without beginning to incur exponential instability.
Any time a change is made, AIS prevents the potential catastrophic side effects of crashing systems or bad decisions because of bad information.
AIS watches for changes and performs an impact analysis every time any change is detected in an application, data source, business process, or element of integration such as interfaces, business rules, etc. Once the potentially impacted elements are identified, the process notifies the owners of the objects with detailed information. The owner either approves the change or makes a change in his object(s) to accommodate, which would again start the integrity check, continuing recursively. All changes are held pending until completely resolved, and then are automatically rolled out in the appropriate order.
