Integration technology has been on a journey that has radically improved agility and reduced TCO. It has moved from a manual craft to something more modular, reusable and business focused:
• Hiding complexity behind well defined and open interfaces that encourage reuse and sharing
• Replacing point to point with many to many
• Minimising the custom coding required for any particular solution
• Abstracting away complexity, becoming more model driven and “business technology” focused
• Adding management capabilities to monitor and improve usage

As a result, integration at the data and process levels have been transformed, and the enabling integration technologies have become widely adopted. This explains the popularity of approaches such as BPM.

However, these approaches still leave users stranded with too many applications on their desktops, including major enterprise applications that are complex and difficult to use because they are not dedicated to the task at hand. This is primarily because they do not extend to delivering the simple, intuitive, flexible UI required to make people more efficient and to reduce the cost of building and maintaining applications for people. If I want to create an integrated (composite) application for users in my business that spans several functional domains (such as billing, CRM and order management) then:
• I have to custom code the UI for all the functional domains and how they are to be combined, or i have to take a packaged application like CRM and begin to develop new screens that lock functionality from other domains into its code
• I have to do this each time I need a new solution
• There is no equivalent of a “process model” that lets me involve the business and make changes rapidly, and there’s no reuse or sharing at the UI level
• I’m on my own when it comes to measuring and monitoring usage

In other words integration for people has missed out on the principles above. Applications for users are still crafted individually, rather than being assembled. It’s only been economical to build / buy applications for the largest user groups or to deliver specific functional applications which the user must “swivel” between. Users and processes become inefficient, and as more and more point solutions build up on the desktop, developing and integration solution becomes harder, as functionality is baked into these applications. The success of SAAS applications actually re-inforce the proliferation of applications on the desktop with yet a new generation of applications.

The answer though is simple enough: extend the same principle applied to data and process integration all the way to the user interface and the building of user facing applications:
• Service enable ui : create UI services, well defined and open interfaces that encourage reuse and sharing rather than point to point integration
• Develop business friendly mode to orchestrate the UI services
• Provide management capabilities to monitor and improve usage

This is what enterprise mashups really ought to focus on: addressing the last mile of integration to make people more efficient.

Labels: application development, architecture, business alignment, contact centre, CRM application, customer experience, Lean Software, mashup, SOA, user experience, Web services

Recent blogs from the worlds of enterprise mashups and CRM have reinforced my impression that a lot of people are struggling with the dilemma of how to move to the flexible IT and business architectures they know they need for future success when the investment environment is focused on short term returns.

A posting by Susan Bouchard at Cisco kicked off a discussion that led to Stefan Andreasen from Kapow asking (in respect of mashups)

Companies traditionally only purchase IT products as part of building a dedicated business application with a defined ROI and timeline.
So the big question is how to resolve this?`
It seems identical to the "Long tail economy", selling many low-price items. It makes no economic sense before you start selling a lot, but then it's hugely profitable.
It's the same with mashups, but how do we get over that initial barrier?

Meanwhile, Colin Beasty, blogging on CRM Outsiders wrote

… whenever you add new channels to a CRM process you add complexities, and it seems businesses are struggling with fostering and tying all these new channels into that seamless experience that the customer can pick up on. I think the contact center industry in general is trending towards the delivery of these channels in a more service-oriented approach.
Breaking down the silos has always been and will continue to remain a key driver of industry software and best practices. Web services, standards-based software, and open source seems to be taking the lead in tackling a lot of these issues, but on the flipside the economy isn’t leaving businesses with a whole lot of cash to pursue these interests.
For the short term future, I think businesses remain in a Catch-22 situation: the economy demands that customer retention and experience is a priority…and thus consolidating these channels into a single experience…while lack of revenue and profits doesn’t leave the financial vehicle by which to accomplish these goals

It seems to me that this pair of postings ask questions that a lot of people are thinking about at the moment. They also illustrate the challenge and the opportunity for enterprise mashups. On the one hand, when enterprise mashups are simply seen as addressing long tail “micro-requirements”, many of which need satisfying to justify investment in a mashup infrastructure, the business case “initial barrier” is a real one. On the other hand, there are many requirements for process based integration for end users – such as combining allowing agents to work across multiple channels in the contact centre – that are further up the long tail – slightly more complex, still out of reach economically from traditional SOA and application integration but offering much more substantial payback. The trick is to bring the two together – using mashups to build process-based applications for users one at a time, with each generating payback quickly, and creating lightweight reusable services (“mashables”) as a result. That way the need to minimize cash outlay is achieved, operational improvements are delivered and the organization is left with a flexible, service based approach to build on further.

For some people who have only seen mashups as simple “dashboard” type applications, this requires a broadening of how they think of mashup technology. However, we are seeing that this approach is essential to resolving the dilemma faced by apparently contradictory short and long term pressures.

Labels: CRM application, enterprise mashup, SOA, Web services