Calling all integration experts!

Remember the old Universal Translator as modeled here by the late Mr. Spock? One of the first (or perhaps future?) examples of integration solutions, and certainly one of the most fondly remembere! But at its heart, it is also an almost perfect representation of the integration challenges today. Many years ago, there was EAI (Enterprise Application Integration) which was all about integrating homegrown applications with purchased package applications and/or alien applications brought in from Mergers and Acquisitions activity. The challenge was to find a way to make these applications from different planets communicate with one another to increase return on assets and provide a complete view of enterprise activity. EAI tools appeared from vendors such as TIBCO, SeeBeyond, IBM, Vitria, Progress Software, Software AG and webMethods to mention just a few.

Then there came the SOA initiative. By building computer systems with applications in the form of reusable chunks of business functionality (called services) the integration challenge could be met by enabling different applications to share common services.

Now the eternal wheel is turning once again, with the integration challenge clothed in yet another disguise. This time it is all about integrating systems with completely different usage a resource characteristics such as mobile devices, IoT components and traditional servers, but also applications of completely new types such as mobile apps and cloud-based SaaS solutions. In an echo of the past, lines of business are increasingly going out and buying cloud-based services to solve their immediate business needs, or paying a third-party developer to create the App they want, only to then turn to IT to get them to integrate the new solutions with the corporate systems of record.

Once again the vendors will respond to these user needs, probably extending and redeveloping their existing integration solutions or maybe adding new pieces where required. But as you look for potential partners to help you with this next wave of integration challenges, it is worth keeping in mind possibly the most important fact of all; a fact that has been evident throughout the decades of integration challenges to date. Every single time the integration challenge has surged to the top of the priority list, the key differentiator contributing to eventual success is not the smarts built into the tools and software / appliances on offer. Rather it is all about the advice and guidance you can get from people with extensive experience in integration challenges. Whether from vendors or service providers, these skills are absolutely essential. When it comes down to it, the technical challenges of integration are just the tip of the iceberg; all the real challenges are how you plan what you are going to do and how you work across disciplines and departments to ensure the solution is right for your company. You don’t have the time to learn this – find a partner who has spent years steeped in integration and listen to what they have to say!

Breaking the SOA logjam

One of the 2008 forecasts in the annual Lustratus look ahead is that SOA decision-marking has become fractured in most companies, with clashes between architects / IT who ‘get it’, and business-oriented budget holders who don’t.

In fact, this problem is turning out to be so severe that it is causing SOA adoption to stall at many companies – although enterprise-wide decisions may have been taken to adopt SOA, projects steadfastly refuse to enact this because of the extra costs, at least initially.

The roots of the difficulty here are twofold: understandable cynicism and the need to reach critical mass of SOA deployment before benefits start to show. However, there may be a light on the horizon, as discussed in more detail in the Lustratus Whitepaper, ‘Justifying SOA to the Business’, available for free from the Lustratus webstore. For business audiences, it may be that the enhanced business visibility offered by SOA could be a compelling benefit to justify the extra investment, and this visibility becomes apparent immediately the project is complete – there is no need to wait for critical mass to be achieved before seeing the benefit.

Hopefully, this angle of attack may succeed in breaking down the SOA adoption log-jam, enabling companies to flow smoothly to widespread SOA adoption.


Is ‘Stealth SOA’ the only choice?

Some of our recent research at Lustratus has given me the opportunity to talk to a lot of end user companies trying to get going with SOA, and a range of different roles within these users spanning all the way from the programmers to business people.

As a result, I am beginning to wonder whether the only option for SOA implementation is the Stealth model.

Leaving aside those visionary companies who are able to write off large investments on the latest new idea, or on a belief, most companies are forced to take a pragmatic view. As outlined in the Lustratus 2008 forecasts, there is a definite fracturing of SOA-related decision making between the archtiect bodies that see the value clearly, and the business-driven projects that own the budgets but do not see the need to include SOA costs in their business cases. When you think about it, this attitude from the business side of the house is not unreasonable – after all, what does SOA mean to a business unit? The discussions often go like this.

You will get get business agility and flexibility – the ability to respond faster to market changes.

– Oh yeah? When? How much do I have to invest before this happens? When do we reach critical mass? How long do I have to wait? Prove it!

The P&L will improve because we will reduce redundant code and wont write so much new stuff.

– When? What is the payback time? Why have you guys been building duplicate programs anyway? And how does that increase my project budget now, to cover the extra costs you want me to include?

But it is all for the best – honest!

– Do I HAVE to use SOA? Can I do what my project needs without? All I care about is this project, its allocated budget and the returns.

The problem is that SOA actually asks the business user for a lot of faith, just like other major infrastructure changes fo the past. One way around this impasse that many users have started to employ is the ‘SOA by Stealth’ approach. The first step is to get the SOA infrastructure assembled – ESB, Registry etc. These components can sometimes be slipped into projects without arousing suspicion, usually by claiming that the particular project needs it. Breaking the infrastructure up this way avoids the problems caused by a sudden large investment. Then, as each project is done programmers try to gradually turn pieces of functionality into SOA services – as many as can be done without drawing too much attention and impacting the budget too much.

The idea is that eventually it will become possible for IT to assemble the evidence that SOA is actually delivering benefits, at which point it becomes much easier to convince project budget holders to allocate some investment to it. In other words, the hope is that once the boulder starts rolling it


SOA Communism vs Corporate Capitalism

During a nice break for the Holidays, I got to thinking about SOA and its similarities to communism, and on my return I have been chatting to a number of SOA users and have confirmed my suspicions. SOA is just a communist plot!

Seriously though, there is a real issue here that is starting to affect companies as SOA penetration increases. Once upon a time, IT investment was funded primarily through a central IT budget with all business units having to share the burden, but over the years this became unacceptable to many who wanted a more capitalist view where funds came from the people generating the business and were justified based on returns. So nowadays IT budgets typically fall into two pieces; a central component for the IT ‘infrastructure’ that everyone shares, and project-based funding attached to specific business initiatives.

Then along comes SOA. In its simplest terms, SOA is about two things – packaging functionality in business services, and encouraging the sharing of these services across different business needs. But who owns these services / is responsible for funding them? Are they infrastructure? Well, not really because they are business-driven. So are they funded by a project? But in that case the project is now having to fund something being done ‘for the good of the whole’.

This problem can be seen more clearly if we look forward. Imagine a company where SOA has become a way of life, and all applications are now made up of shared SOA services linked in different ways. Does that mean everything is now infrastructure and should be centrally funded? Then that takes us back to the centralized funding days, losing the link between business need/return and targeted investment. In reality, this introduces the principles of communism, where everyone owns everything, and the problem for companies is that this model stifles business performance and progress. Perhaps one way around the problem is for monitoring and management software to keep pace with the changes, so a clear picture can be built of which business operations drive which services. At least this would provide some more granular level of investment/return linkage.

However, my personal view is the problem will sort itself out – once the initial funding hurdle of SOA has been overcome, project funding to achieve a particular business end will be happy to build the required functionality in ‘SOA mode’ because it will be just as cheap as not doing this, and this will have the convenient by-product of helping other projects. In other words, the kick-back against SOA by projects today is based on being forced to increase investment ‘for the good of others’. If SOA works out right, the future should see projects tomorrow investing less but also seeing others benefit, a much more palatable situation.


Jitterbit kick-starts an OSS solution marketplace

An article in ebizq alerted me to Jitterbit’s just launched “Trading Post” for integration-specific solutions.

Jitterbit claims to the “World’s most popular Open Source integration platform” – which surprised me as I had not heard of them before.

The idea of setting up sites to enable the selling of software components is hardly new (although rarely successful) and of course sharing is precisely what an OSS community is supposed to be about. What is more interesting about the “Trading Post” idea is that

– It focuses on solutions: i.e. not just source code for the bits of the puzzle but also the patterns and knowledge essential to deliverying the complete solution.  And directs potential users to the services provided by “Trading Post” providers who can help to deliver the solution and

– It focuses on both application specific solutions (such as JD Edwards) and industry specific solutions.  Again moving the emphasis away from raw technology towards problem solving.

– It provides an interesting revenue opportunity for OSS service providers/vendors who often struggle to drive revenue from support/maintenance alone.  This is because it crisply defines the value they (as Trading Post providers) can give around specific solutions.

While just launched, it is already ‘pre-stocked’ with 50 solutions which demonstrates a certain amount of apparent momentum.  Perhaps it is a model other OSS vendors should take a look at…