A recent paper from Gartner (Top Business Processes for Customer Service, 2010 to 2012 - subscription required) about customer service process priorities adds to my impression that the agent desktop - and in particular the complexities of using the applications on it - is in danger of being the “elephant in the room” when improving service delivery in the contact centre.


The report discusses the process improvement priorities for customer service, looking at problem resolution, feedback management, workforce optimization and field service processes. Within the first category it examines agent facilitated, self service and collaborative problem resolution. As it suggests, it is essential – in both financial and customer experience terms- to move as much interaction as possible to the self service and social arenas. However, most organizations will still need high quality agent facilitated support, either because of the complexity of the issue or because of customer preference.


In this arena it cites a familiar set of challenges

• Problem definition and understanding — both by the customer and the agent
• Process handoff steps, both intra- and inter-departmental within the organization
• Transfer of customer from one department to another, or transferring from one channel to another
• Ability to resolve the problem for the customer
• Cost to the organization of resolving the problem for the customer
• Time to resolve the issue for the customer
• Keeping the customer informed of the status of the issue resolution
• Tracking inquires linked to the same issues over multiple contacts

I completely agree that the technologies cited as relevant to addressing these challenges - Call handling and case management, trouble ticketing, training, knowledge management, cobrowsing, automated call distribution (ACD), call recording and workforce optimization – are important. When it comes to the “moment of truth” and the customer is on the phone, the only thing that really matters is “do I have access to the knowledge, information and tools needed to fix the problem?”. And for most agents this all comes via the desktop, which will typically be cluttered with CRM, KM, trouble ticketing, case management etc as well as a set of operational applications such as billing, tests, returns management, field service bookings, logistics, order management and diagnostics. So we have all this investment in systems to help the agent, but then deliver them through an unusable clutter that frequently undermines the bigger strategic objective.


Like the proverbial elephant, this rarely gets mentioned, even though it’s a fundamental determinant of the agent’s performance and hence customer service. I can think of a few possible reasons

• We are conditioned to having to work this way
• Technologies that have offered a solution have failed, reinforcing acceptance
• “The agents can manage” so we can act like it doesn't matter

This elephant needs to be sent on its way if the challenges are to be met. We need to give the agents the right tools, not handicap them with horrendous desktops. Why do you think we tolerate his presence?

Labels: agent desktop, agent desktops, call center, contact centre, contact centre agents

I attended an excellent event delivered by Sabio, one of our strategic partners, last week. Focused around the Sabio Best in Class benchmarking framework called Insight, the agenda covered individual areas of focus for Contact Centres each illustrated perfectly by a case study. Targeted at Operations Directors, IT and Senior Contact Centre Management, the event covered Demand Management, Automation, Accessibility, Optimisation and Efficiency in the Contact Centre from a strategic and underlying technology perspective. The balance between prescriptive advice, practical reality and input from the attendees was refreshing. As were the case study presentations, for once not all about how great things are but illustrating real examples of the progress and real performance improvements that each company had made, with the recognition that there were still many things that need to be addressed and that much of the time they were fire fighting.

HomeServe talked enthusiastically about how they had improved resource optimisation through forecasting and identifying the key factors that influence call volumes. However they accepted that their forecasts would never be 100% accurate because of factors that they couldn’t predict such as the more recent freak weather conditions. They talked about the progress they had made in multi-skilling through simplifying the desktop, making it easier to train agents and to broaden their remits. The result of this was their ability to successfully blend work between teams to address forecast anomalies better but recognised that there was still progress to be made here to make it seamless.

Egg spoke about managing demand and driving greater automation, their desire to move customers to self service wherever possible whilst admitting that in some cases automation was not possible and that the customer would have to call and speak to someone. Egg uses extensive measurement and monitoring processes to identify contact trends that can be addressed by the business. On the whole their move to self service continues to be successful for the majority of transactions but they explained that it was important that if the customer did have to resort to calling that the integration between the channels was seamless and the customer service levels were consistent.

In a very energetic presentation from Lego, the senior customer services director described in detail how Lego were working towards achieving better customer accessibility. Lego were unique in their desire to increase direct customer engagement to ensure that they continue to grow and meet customer needs. The recognition that their customers were multi-lingual, spanned generations and that the majority of Lego is sold during what they called Main Season or to the rest of us – Christmas has massively impacted their contact centre strategy. They needed to achieve improved customer contact across multiple segments whilst recognising and developing Lego as an emotional brand that their customers felt part of and involved with. Something that they realised they lost sight of in the early part of last decade, but had since 2007 been striving to put right with some excellent success rates.

Finally a presentation from Telefonica O2 Ireland that talked about delivering operational efficiency through measuring in call performance, aligning the agent with the customer needs and the work that they have been doing to segment the customers and align service requirements to those segments but doing this within the unique challenges of the local market.

These sessions in addition to some interesting conversations with many attendees led me to believe that the priorities of senior contact centre directors both in operations and IT are many and varied but that the underlying principle they are looking to achieve is the right level of customer service.

There are many areas on which they can focus their attentions in order to achieve their business strategy, technology being one of them. This led me to think that the key defining factor in any technology implementation within the contact centre has to be its impact on the customer. There are so many technology options that will deliver clear business benefits but where should they focus to improve performance – it was made clear that they should begin with the customer journey looking at the major pain points. Ultimately much of that customer journey is controlled by what is going on at the agents desktop. There are some technologies that will have a more wide reaching impact than others, Enterprise Mashups being one where quick wins can be made and strategic value delivered. One thing that was clear is that companies with extensive sector and technology expertise as demonstrated by Sabio can clearly help to bring together the strategy and technology elements to address these pain points, reduce the fire fighting and help contact centres to meet their ambitions to perform.

Labels: agent desktops, contact centre, customer experience, Enterprise Mashups, operations, Sabio

I have been reading Jack Trout's "In Search of the Obvious, the antidote for today's marketing mess". Trout's view is that to succeed in differentiating your offering, you need to look for 'obvious solutions' that will set your products apart from your competitors in a way that is equally obvious to your customers. To help in 'identifying the obvious (sic)', he devised 5 tests, the tests of Obviousness of your marketing strategy or new product concept:
1. The problem when solved will be simple - the obvious is nearly always simple, so simple that generations of people looked at it without seeing it
2. Is the time ripe?
3. Does it check with human nature? i.e. would everyone understand it, without requiring any specialized knowledge?
4. Does it explode in people's mind? i.e. "why didn't I think of that?"
5. Put it on paper - does it still make sense when put on paper?

Trout's focus is mainly on consumer products for both differentiation within a category and for new product development. I thought it would be interesting to check enterprise mashups against the principles highlighted by Trout (ignoring the last one!):

1. Enterprise mashups turn integration on its head. They take the often abused but appealing “lego brick” analogy of SOA at face value and make it work. Pieces of IT are really laid out like bricks – simple, visual and tangible - and are then simply combined to create useful new solutions. And it turns out that a lot of very valuable integration can be done by using these building blocks in a straightforward fashion, without the usual paraphernalia and complexity of integration. Simple – it just took the courage to do it the obvious way (and to figure out what the right sort of lego bricks are)!

2. Is the time ripe?
Is integrating applications to make people more efficient a major issue? One only needs to look at the mess on most contact centre desktops (and the associated inefficiencies and costs) to agree. Do customers need a way to achieve this without major investment? Of course, especially in today’s economic climate. Do companies need to combine internal legacy applications with new generations of web-based services? Definitely, whether it’s to capitalize on social web trends or to benefit from cloud computing.

3. Does it check with human nature?
People understand the problems, associate with them, and see the value - everyone has experienced the issue of working with multiple applications to complete a task. Everyone has been on the receiving end of the same issue when dealing with contact centres. We intuitively understand the idea of combining the different and relevant bits of applications – a bit like creating a collage of the desktop - to make a job easier.

4. Does it explode in people's mind? When you show people what mashups do, the light switches on. The issue is almost the opposite: if this is so obvious, why has this not been done before? Together with the history of failure in integrating effectively applications for people, customers initially tend to think this is too obvious and too easy - there must be a catch.

I think Enterprise Mashups pass the tests. Obviously I would, being at Corizon. Let me know whether you agree.

Part 2

This blog post is co-written with Lee Provoost from the social business consulting firm Headshift and started over a bowl of porridge

The end-user of your product doesn't care what kind of data silos are laying underneath your IT system. They just want the information they need to do their work, but very importantly: taking in account the context of the work! Put yourself in the consumer’s shoes, your customer doesn’t talk to you in silos and certainly doesn’t want to be treated in silos. Have you ever called your bank, only to be passed to several different departments? We know already that Interactions aren’t Connected and ultimately we are still running processes as if we are in the industrial age – an assembly line of handoff after handoff.

This is the same as going to a McDonalds and asking for a ‘Happy Meal’ but being told to get a drink from one counter, a sandwich from another, fries from a third and the toy will be sent directly from Mattel – oh and you want a straw, napkins and sauce – there’s self service for that. More of a Meal than Happy! Not quite so fast or convenient food. What happens when the meal then changes, there's a new toy, you add something else to the box - how is the existing process able to cope with changes easily?

We have now identified the impact of data ubiquity:

1. the corporate IT department being challenged by huge data silos (lock-in) and disparate solutions with complex processes that rely on humans to be the integration layer
2. the business end-user dealing with too many different and complex applications and not being able to make sense of all the data (filter failure), subsequently not being able to deliver the process

In many businesses the delivery of an end to end business process relies on users accessing multiple software applications that combine to deliver the complete process. The result of this can be disjointed processes, mistakes, slow access to required information, no single customer view and ultimately a dysfunctional customer experience that the business users can’t impact.

So, the goal we're trying to achieve is to provide business end-users Enterprise 2.0 systems with meaningful contextual information in a simple and elegant way – we like to call this fit for purpose!

Mashing it together

As a technologist, the first reaction would be to try to solve this data silo problem. (Let's ignore for a second the old approach to create a monolithic repository, called the black hole, where we dump everything in.) How can we make it more accessible, can we wrap a web services around it, can we apply on a large scale the principles of Service-Oriented Architecture and Model-View-Controller, can we add an open data API interface to it, etc. That will most likely keep us busy for the next coming years. Wake up call: your customers are not going to wait two years till you have your internal issues solved. This approach also often instigates new shadow projects that proclaim to deliver tactical, quick win solutions whilst waiting for the 'nirvana'.

As a business end-user, you're faced with a proliferation of applications. A lot of time and money have been invested in building these, so... why not starting by reusing the useful bits of the existing apps to get immediate value?

This is the approach pioneered by Corizon. An user-centered focus approach, starting with the end users and working down - understanding the process in which they go through to complete a task, be it solve a customer enquiry in the front office or manage work in the back office - referred to as the user process. All too often, technology's answer to a problem is upgrade to the latest version as it has all these new features. The problem with this is that this doesn't necessarily resolve the original problems, complex process, too many applications.

Once the user process is clearly defined, we then (or can in parallel) look at working up - understanding what data & applications we need access to to effectively and efficiently complete the defined user processes. We will now understand the pattern, what gets the most use, by who, how. This firmly puts the cross hairs on which applications to enable for reuse. Unlike traditional data re-use approaches, this approach enables the useful & required bits of applications, but also defines reusable UI and stores these in a library of reusable services.

Now we have two key elements defined, a clear user process and a set of reusable UI services. Corizon's solution then allows you to mashup these to create the optimal interface, be it a standalone UI or consumed as a widget in your Enterprise 2.0 application. Adding new, or removing legacy applications becomes a much less complex task - the UI Services approach allows you to interchange these without affecting the interface.

Good is good enough

At first sight, this approach might sound a bit unconventional, but we'd like to invite you to an excellent post by Peter Evans-Greenwood (@pevansgreenwood) that talks about "The Price of Regret".

Building the big, scalable perfect solution in the first place might be more efficient from an engineering point of view. However, if we make the delivery effort so large that we miss the window of opportunity, then we’ve just killed any chance of helping the business to capitalise on the opportunity. ... Size the solution to match the business opportunity, and accept that there may need to be some rework in the future. Make the potential need for rework clear to the business so that there are no surprises. Don’t use potential rework in the future as a reason to do nothing. Or to force approval of a strategic infrastructure project which will deliver sometime in the distant future, a future which may never come.

One thing we've learned in this consulting business is that most of the times, good is good enough since perfection takes an eternity.

Labels: data silos, enterprise 2.0, enterprise mashup, Headshift, Peter Evans-Greenwood, SOA

This blog post is co-written with Lee Provoost from the social business consulting firm Headshift and started over a bowl of porridge
Part 1....

"Content and data are everywhere. People are creating and curating content like never before. As data storage becomes cheaper, businesses are storing,archiving, and mining more data than previously possible. The increasing openness of APIs and data portability make more enterprise data available for both consumers and employees to consume. Free flow of data also allows businesspartner relationships to be readily analyzed and optimized." (Emerging Opportunities in Social Business Design)

Filter Failure
With large corporations storing more and more data (be it for compliance, regulatory or internal mining purposes) in their Enterprise 2.0 (and overall IT) systems, we have the danger of getting big data silos or disparate solutions. To make matters worse, they are often stored locally in systems that are owned by different business units with different purposes. So, imagine that you have invested a lot of money and effort in a knowledge management system, just to realize after 3 years that it does not suit your needs anymore and you need something else? If you have a couple of thousands of files, it's still quite manageable. However, if you work in a very knowledge-intensive organisation, three years of data might have accumulated into several hundreds of gigabytes of data. Good luck with that migration.

Then go through a merger with your competitor or launch a whole load of new products or services and try to gain consensus and consistency across these disparate solutions.
With the increasing importance (and increasing amount) of data floating around your organisation, it becomes more and more important to think about open standards for data interoperability. Accept the reality of the day that a lot of your data is stored in silos. What we need to think of now is how we are going to make this data step-by-step accessible so that we don't need to do tedious and error-prone data migrations when the system doesn't cope with our demands anymore.

Perhaps to your surprise, I'd argue that the data silo lock-in is not your biggest problem. No, the inability to intelligently manage and reuse this volume of content in a meaningful way is a much bigger danger that has a direct impact on your business. Filter failure arises when individuals are unable to synthesize and understand the vast amounts of information being generated by an organisation.

Where the problem used to be getting enough information, now it's being able to make sense of it all. So in addition to filtering the underlying plethora of data and subsequent applications, you also have to be an inline translator. For anyone dealing with end users directly eg a front line customer agent dealing with lots of applications, they will always speak in their own language and never that of your systems, applications or processes. More importantly, they have no reason to.

The interface is the product
But what exactly are we trying to solve here? Why would we even care about this problem? Just a Bunch of Stuff That Happens perfectly coined it in the following cartoon:


Even this is being kind – the average knowledge worker will use between 6 and 15 of these apps, we have experienced people using upwards of 30 because of these data silos. The typical enterprise application looks much like "Your company's app" as shown in the cartoon. There is such a vast amount of data flowing around your company that you often end up with these kind of user interfaces. Instead of achieving the goal of bringing powerful information to the fingertips of the business end-user, it just confuses people. It just makes people unhappy and unproductive. For every new channel, (email, web, social channels, ...) and for every new product, the quick answer is often to bring in a new additional application. This all adds to the complexity and mess on the knowledge workers desktop.

And just in case you would forget, an IBM Design tweet nailed it:










Part 2 of this blog which will be published next week will go on to describe how the issues of data silos and increasingly numbers of application interfaces can be addressed.

Labels: application interface, data silos, enterprise 2.0, Enterprise applications, Headshift, knowledge worker

We've created a new video that provides an introduction to Corizon enterprise mashups and their use.

Labels: call center, contact centre, contact centre agents, enterprise mashup, mashup, process mashup

Labels: agent desktop, call center, contact centre agents, enterprise mashup

In a recent global survey of CIO, CTOs as well as non IT executives, McKinsey found that, during the recession, IT has become more important to improving business efficiencies. 39% of those surveyed now see the primary role of IT to improve business efficiency vs 31% a year ago.

This bodes well for software and other IT products focused on improving business processes, making people more efficient and increasing productivity. Furthermore, in 2010, more than 45% of respondents expect to increase IT investment confirming our view that when a short payback and low operating costs can be demonstrated, companies are increasingly interested in investing in new IT projects. Reducing overall management costs of IT itself remains high with 60% of respondents expecting operating expenses to decline or remain steady. Financial services is the most bullish sector with regards to IT investment.

Finally,

non-IT executives continue to say they want to forge a closer partnership with IT in order to improve performance and better manage risks and disruptions that lie ahead.

Labels: application development, business alignment, enterprise mashup

Labels: agent desktop, call center, contact centre, Enterprise applications, enterprise mashup, process mashup

Labels: agent desktop, call center, contact centre, contact centre agents, enterprise mashup, mashup

Dale Vile, from Freeform Dynamics, has written an interesting article discussing whether packaged applications are becoming less relevant:

Whether it’s SOA purists telling us that we’ll all be self-assembling solutions from components, enthusiasts of modern development environments wanting to build everything from scratch, or the SaaS evangelists saying it’s all going to go into the cloud anyway, it is trendy to dismiss application software packages as being out of touch with the needs of the 21st century….but the truth is that both vendors and their customers can only move so quickly, and while the latest incarnations of ERP, CRM and other packaged applications promise a lot, migrations and new implementations consume both time and resources.

It almost seems a response to a very frank article from ZapThink advocating the move away from packaged applications to self-implemented SOA solutions.

I agree with Dale - I don’t see companies in the current economic environment looking to rip and replace their current applications and systems. If they are, then they are likely to be looking at SAAs, but as Ray Wang emphasizes, this does not remove the integration issue:

Rapid SaaS Adoption Will Lead To A Repeat Of 1990’s Best Of Breed Integration Challenges’ and ‘Given these scenarios, CIO’s and line of business apps will need to rely on stronger enterprise architecture and integration in hybrid deployments. In fact, au contraire on the death of SOA!

So what everyone seems to agree on is the increased need for integration. However, resolving the integration challenge is far from being fully addressed today. A big gap still remains: integrating applications for people. Contact centres are a good example of this, but I would venture to say that most people involved in supporting key processes end up having to use multiple applications to do their jobs. SOA technologies do not yet address this problem: user specific solutions end up having to be custom coded, in effect ending up building new silos and legacy applications, destroying the point of establishing a flexible and re-usable architecture in the first place.

To address this issue, SOA technologies and approaches need to be extended to the user interface and user interactions. This needs to happen in ways that suit human centric processes, where change and speed of adaptations are key. Current SOA programmes are generally bottom up, complex and relatively slow to get off the ground. Much more agile, fleet of foot solutions to integration need to be provided. Solutions that can start delivering value in days but without building new legacy.

This is where enterprise mashups have a major role to play. They provide not only an approach to ‘clear out their application integration backlog more quickly and at less cost’ (Anthony Bradley), they also provide a route to delivering more effectively a modern, flexible architecture. How? By extending the SOA concepts of composition of services all the way to the User Interface. In other words they provide the capabilities to turn valuable UI (from legacy applications, modern solutions, SAAS applications) into re-usable components that can easily, quickly and cost effectively be assembled into user specific solutions. Whether your implementing new SAAS applications or need to evolve from legacy systems, enterprise mashups provide the answer to integrating applications for people .

Interesting research from Genesys has just been published and is given a good write up in MyCustomer.com by Stuart Lauchlan. First, I must say they deserve ‘la Palme d’Or’ for the highest number one can find in a customer service press release: $338.5bn! Having said that, I think it is interesting to quantify the actual costs resulting from underperforming customer service in this way. Where do the issues stem from?

"The biggest problems that customers experience and which undermines the customer satisfaction levels are familiar ones. They include being trapped in automated self-service, having to wait too long for service, having to repeat themselves and having to talk to company representative who lack the skill to deal with their problems. On the other hand, most consumers surveyed argued that they would be most satisfied when dealing with a competent, live customer service rep."

Delivering a positive customer experience, enabling customers to engage with a competent, live customer service rep is actually very difficult. It requires providing the agent with systems that not just deliver the right information at the right time but also guides him or her through the steps needed to resolve the customer query. This is the only way to allow the agent to focus on the customer interaction and ensure satisfaction. The most critical aspect is an effective user interface that prompts the agent in an intuitive way through each step required to complete the task and resolve the query. What is the main obstacle to achieve this? The multiplicity and complexity of systems that agents are forced to use.

The other interesting point here is that customers prefer to talk to a live person, to a human being, to resolve their queries beyond the most simple tasks. This reinforces our belief that contact centers are and will continue to be essential in maximizing customer value. Trying to resolve performance issues by automating away the contact centre does not seem to be the right answer. Providing agents with the right tools that make their jobs easier is.

Anthony Bradley from Gartner provided some interesting views on how he sees the enterprise mashup market developing this week in his blog posting: Enterprise Mashups in Major Transition.

The transition he has identified is chiefly concerned with a shift in the use cases he is seeing that drive demand. As Anthony says:

Just about everyone, including me was talking about enterprise mashups as a new paradigm for end user computing where business users would rapidly assemble and reassemble applications in a highly dynamic fashion.

And then…

… a shift in the need began. Instead of asking about end user empowerment, clients began inquiring about how to reduce integration costs with mashups. Some organizations were trying to use mashups to clear out their application integration backlog more quickly and at less cost. Others were facing new integration challenges due to mostly unexpected mergers and acquisitions.

This accords with what many of Corizon’s customers and partners are looking to enterprise mashups to provide in the first instance. I would add that this shift does not move the interest in enterprise mashups purely to the IT domain. Fixing integration problems does not only concern IT but also business unit leaders in that they have the potential to greatly impact the efficiency of their teams. In today’s environment, many businesses are looking for way to deliver a step up in people productivity with short and low risks projects: enterprise mashups are perfectly suited to that.

Finally, this type of pragmatic integrations will naturally create a pool of reusable mashable components if done with the right technology. Once created (and paid for) thanks to these projects, these components will make it easier for end users to create their own mashups in a safe way, with the buy in from IT. So the nirvana of end user empowerment is perhaps not as distant as Anthony fears!

Labels: application development, enterprise mashup, Lean Software, mashup, mashup patterns, process mashup

This posting is the second part of my colleague Toby Baker's observations based on his work with contact centres and their desktop integration problems.

My last blog asked why contact centre desktops are so broken, and tried to explain why. This one suggests what we could do about it.

Let’s re-cap – the main problems are:

• There are too many apps on the desktop. The average is 6, I have seen 60.
• The data is all over the place – across multiple screens and apps.
• No standard User Processes – it’s left up to the user to figure out how to make it all work.

So why is this a problem?
So many reasons! Here are the main ones:

• Complex ALT-TAB, COPY-PASTE operations means longer call times, longer hold times, higher abandon rate
• Lots of applications means lots of training
• Lots of double-entry means lots of errors
• Hard to find data means lower first call resolution
• Lack of standard process means compliance is more challenging
• System-centricity, rather than customer-centricity means lower customer satisfaction.

So what can we do about it?

1 - Look at the user processes you have, from a customer and agent point of view, and see where the bottlenecks are.

• How much ALT-TAB and COPY-PASTE do you see?
• How many screens do your agents have to go through?
• How many logins do your agents have to remember?

Imagine if all this complexity could be removed – how much time could be saved? What would be the benefit of automating and optimizing this process?

2 - Decide which user process to improve first, and figure out what the ideal process is. Create a roadmap towards that ideal process, creating early fixes that create payback fast. Involve your users, and start building a business case:

• What could you do with the call handling time that you save?
• What would it mean if your new agents became fully competent sooner?
• What would happen to your abandon rate, FCR or PCA30 if you did this?

3 - Split the problem into two halves: The user processes and the applications underneath. User processes change at a different rate from system interfaces, and you need to separate the two to deliver fit for purpose interfaces to your agents. Design the desired user processes working with analysts and business, then work with it to turn the relevant “bits” of applications into the building blocks of the solution.

• Add to your business case the benefit of being able to change screen flow and therefore user processes quickly
• Imagine how much benefit there is in re-using the everything you build in subsequent projects

4 - Start a project to build a model office, and start proving your business case. See what can be achieved quickly when you implement those quick fixes on the way to the optimized User Process.

Follow these suggestions, and the problems caused by broken contact centre desktops will start to disappear very quickly!

Labels: agent desktop, CRM application, CTI

Labels: agent desktop, call center, contact centre agents, CRM application, Enterprise applications, enterprise mashup

Just come back from Oracle Open World 2009, where the atmosphere was very different from last year: the key focus was on making things works with a lot less hype. Most of the Oracle keynotes I attended insisted, demo after demo, on the progress made in integrating different applications from the portfolio with fusion middleware. The CRM team did a great job in demonstrating new features and functionality delivered in the latest releases. Fusion Apps were announced but remained relatively low key. One key differentiation from the existing apps seem the clear focus on user experience. Early analyst feedback seem to confirm the success achieved there ( see Ray Wang or Paul Hammerman)

The feedback from customers was also focused on integration and innovation to take costs out. One key theme was "instant gratification": looking for technology and projects that would deliver very short term benefits at low risks but without building new legacy. Retiring legacy applications seem high on the agenda as well.

In walking the Exhibition Floor, it seemed less product companies were exhibiting than last year with SIs and other specialist consulting firms having replaced them. One exception was the presence of salesforce.com with a large booth and keynote to boot. Talk about extreme coopetition! The scale of OOW was as impressive as last year and the organization flawless which was no small achievement considering that more than 40,000 people attended. The power of OOW remained in the great potential for networking and meeting customers, partners and analysts. We had many very productive conversations in a few packed days which made the trip more than worthwhile.

Many good reviews were written about OOW. I have selected a few below that I thought were particularly worthwhile reading:

- Paul Greenberg
- Denis Pombriant
- Esteban Ekolski
- Michael Fauscette

Labels: #oow09, CIO, CRM application, Enterprise applications, ERP application, IT strategy, Oracle, social CRM

Last week David and I attended the Forrester Business Technology Forum in Chicago. The main theme of the conference was adopting “lean” approaches to IT – which seems a particularly appropriate term for the lean times we find ourselves in.

The lean concept applies across the full range of activities performed by an IT department, but I was particularly struck by the discussion on its use in application development in John Rymer and Dave West's session*. Four key ingredients were seen as essential to lean software:
• Making sure deliverables are “fit for purpose” for the business problem at hand
• A clear focus on hard, measured value
• Simplifying the delivery platform – moving away from overbloated infrastructure stacks if they aren’t needed
• Allowing efficient evolution – avoiding stovepipes without creating undue overhead

Overall, this combination of getting quickly to the right, “just enough” solution and then improving and reusing, while measuring all the time is both powerful, and with the benefit of hindsight obvious! However, it is sobering to remember how far from this approach so many enterprise application development and integration projects are.

Much of “getting to lean” is about methodologies, management techniques and people. However, the right technology for the right problem can provide powerful enablers if chosen appropriately – another key point from the sessions. Discussions at the conference confirmed that - when it comes to integrating applications for people - process based enterprise mashups can provide a key to a leaner approach:
• Encouraging building directly from the desired user requirements under the control of the business and process owners
• Allowing user and process execution to be clearly benchmarked and measured to show improvements
• Pragmatic, light-touch, standards based integration
• A first, “just good enough to make a different solution” in days, followed by iterative improvements and spinning out reusable “building blocks” as a natural by-product

Lean is an important theme. Using enterprise mashups won’t get you there by itself, but it encourages and helps you to work in a lean way – which can’t be a bad thing!

* How can lean software enable you to better serve the business by John Rymer and Dave West, Thursday 8 October 2009, #BTF09

Labels: #BTF09, application development, business alignment, CIO, Enterprise applications, enterprise mashup, Forrester, Lean Software

Recent studies have highlighted the current dilemma most companies have with contact centres: they are both critical in maximising customer value and considered poor in meeting customer expectations. A YouGov survey conducted in the UK showed that phone and email were by a significant margin the most likely channels used by customers to contact a company for customer service (75% and 70% respectively). Self service comes third with 43%. At the same time, consumers were unhappy with the quality of service provided: 83% were frustrated with the interaction and 60% of agents agreed with them!

This matters enormously because “on average, 40% of customers who suffer through bad experiences stop doing business with the offending company” according to a recent survey published in the Harvard Business Review by Dave Dougherty and Ajay Murthy from Convergys. They go on to define the same reasons for the frustration as identified in the YouGov survey: lack of knowledge of the agent and incapacity to resolve the query on the first call. With increasing access to relevant information online through the internet and social networks, I expect customers to become more and more demanding of the contact centre agent in the future. With the simpler queries being increasingly resolved thorugh self-serivice, interactions will become more complex and more critical and the cost of failure will increase.

So what stops contact centres providing the right customer interaction? The main reason is the proliferation of applications on the desktop. The Corizon Contact Centre survey of 90 Contact Centre Managers shows that agents have to use on average 5 different applications during a call. It is not uncommon to find more than 20 on each desktop. In such an environment, it is proving very difficult to provide to the agent, cost effectively, the right information at the right time and, crucially, the tools that allow them to resolve the query in a fast and efficient way and stop customers needing to call back.

Fixing this problem has proved very difficult as demonstrated by the generations of legacy applications one can find by walking in a contact centres, from ancient green screen applications to the most recent CRM systems. Resolving this issue cost effectively requires a new approach. This is where process mashups come in. They deliver a step change in agent productivity by providing a dynamic UI that guides the process and gives agents the right information at the right time. Agent desktops can be integrated using a step by step approach, fixing the most broken processes first and delivering immediate improvement. The process mashup approach enables the easy creation of fit for purpose desktops, changing the economics of integrating applications for people by extracting “mashable” components from existing systems to deliver an initial solution in days. Once initial process hotspots have been fixed the business can iteratively work towards delivering the ‘perfect’ application for the contact centre agent that can constantly evolve with the business needs, all within a governed and secure IT infrastructure.

Labels: agent desktop, Big Shift, contact centre, contact centre agents, CRM application, enterprise mashup

Enterprise mashups transform the way organisations combine IT applications to make people and processes more effective. However, in common with most new ideas, if they remain an abstract concept, or if people form preconceptions based on isolated examples (such as the ubiquitous map based mashup), then those who stand to benefit most may find it hard to get a feel for their power or relevance. In my experience, the missing link is a set of examples or usage patterns that make these possibilities concrete.

Labels: agent desktop, CRM application, enterprise mashup, process mashup, Siebel, SOA

I have just experienced two very different contact centre interactions. In the first, the contact centre agent was able to address my questions and resolve my issue in a personable dialogue, making decisions along the way and accessing information easily and rapidly to make these decisions. The result was successful and my perception of the company enhanced. In fact, this was a better experience than resolving the same issue online. I can clearly see how this contact centre could engage in social CRM and graduate to a two way relationships world, interacting on multiple platforms.

In the second experience, with a different company, the agent followed an inflexible script in an impersonal manner and was unable to resolve the query (systems too slow, needed to swivel between several applications, and ultimately the key data required was on a system the agent did not have access to). The result was a highly frustrating experience and need for a second call. Argh...

These two experiences made me realise how tough the job of a contact centre agent is. On very little pay and in a pressurised environment, these guys deal day in day out with often angry customers and are supposed to resolve all their issues rapidly and pleasantly. And we are increasingly expecting more from them: issues are getting more difficult to resolve because the simpler tasks are now done online, we expect a higher standard of service from the agent because we get already so much from self-service, and finally we expect them to make decisions there and then. In some industries, contact centre interactions are becoming a key driver of customer churn.

I can only see this trend accelerating. Younger generations are not willing to deal with companies in one way, push type relationships. They expect two-way relationships across multiple platforms where they take control of the relationship with the brand. This will put even more responsibility on contact centres agents and will fundamentally alter the role of the contact centre:

1. Contact centre agents’ value will increase as they to take on greater responsibilities and capacity to make decisions. Talent retention will become more important, compensation will increase and the role will shift from transaction to relationship management;

2. The contact centre itself will become a strategic asset essential for customer relationships. Investment decisions will shift from minimizing costs of interaction to maximising interaction value;

3. Off shoring decisions will need to include whether the processes and/or customer interactions require complex interactions where local knowledge is important to build the customer relationship;

4. Systems supporting contact centres will need to be more integrated (social media, self-service etc.) to enable support of customer interactions across platforms and at different steps of the interaction process (e.g. interaction initiated in self-service and completed with an agent);

5. Flexible, dynamic and user centric systems will become essential to ensure fit for purpose IT that empowers agents to do their jobs in ever changing environment.

I believe this is part of the Big Shift described by John Hagel in his latest blog. In a further blog, I will develop our thoughts on the implications of this type of shift for organizations processes and supporting IT systems. But first off on holidays!

Labels: Big Shift, contact centre, contact centre agents, social CRM

Micro Focus have just launched an interesting and needed campaign to promote the technology sector in the UK, which I fully support (here). The manifesto makes five directional recommendations for fiscal, entrepreneurial and academic action to promote a more vibrant and stronger technology sector:
1. Increase the availability of world-class technology talent in the UK;
2. Harness the expertise and goodwill of technology leaders of UK origin around the world to coach leaders of UK-founded, emerging technology businesses;
3. Radically change the tax incentives available to companies and individuals who want to invest in growing technology businesses;
4. Implement specific fiscal incentives for UK-founded tech companies seeking to accelerate world-leading R&D;
5. Proactively encourage international technology companies to invest in a UK hub.

One of the ways for government to help I found is often undervalued and which could have a dramatic impact in supporting new, innovative technologies, is the relaxing of the procurement process for technology start-ups. This would not only help in developing a vibrant, start-up environment in the UK (let’s not forget the key role played by government, in particular defence, in helping establish Silicon Valley), it would also help in improving government’s productivity.

A recent article from McKinsey highlights the need for improvement of e-government for example:

progress on the e-government front appears to have plateaued over the past few years. Many new e-government initiatives have neither generated the anticipated interest among users nor enabled clear gains in operational efficiency. In the face of unprecedented fiscal constraints, as well as users’ heightened expectations based on the integration of the Internet into their daily life and work, it is imperative that the public sector refine its approach to e-government to ensure that these initiatives achieve maximum impact.

One of the reasons indentified by McKinsey is the lack of Web-related capabilities. This means recruiting teams with the right skills to drive these initiatives and to leverage the new, innovative technologies out there to drive for more efficient government.

Relaxing procurement processes to allow innovative, tech start-ups without (yet) the balance sheet required to sell to government, would not only help in establishing world class companies, it would also allow for better government.

Labels: IT strategy

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

I spent a great couple of days last week at the Gartner SOA and Application Development and Integration Summit in London, emerging encouraged by the combination of pragmatism and innovation that I heard discussed.

Inevitably, much discussion centred on the economy and its implications. While technology –as Massimo Pezzini pointed out - might be seen as having helped the problem happen by “providing the infrastructure to enable the financial services sector to get into trouble faster than anyone expected”, I didn’t hear much discussion about what could (or should) be done to prevent that happening again! On the other hand there was lots of debate on how IT can help companies survive and reinvent themselves for the future. The (not surprising) prescription was to focus on strict cost control and alignment of IT projects with clear business cases, while keeping sufficient investment to foster innovation in key areas. In the short term for example, organizations need to use their resources to rapidly adapt sales and marketing patterns in response to changed customer behaviours. Longer term, much discussion centred on anticipated structural changes to industries (especially financial services) requiring better support for complex inter-company relationships and networks.

SOA adoption
The message I took on SOA – from both Paolo Malinverno’s opening keynote and much that followed - is that it has clearly taken root, especially in Europe and N. America. However there also seems no doubt that the recession is having a Darwinian effect, culling the projects without well-defined short term business benefits. Long term strategic business cases for SOA programmes are “out”, pragmatism in the form of prioritizing rapid payback from fixing business problems is “in”. As a result, lots of initiatives that have started bottom up with no focus on business problems (service enablement rather than SOA) risk being cut – one figure floated (and hotly disputed) was that this could kill up to 80% of the projects started thus far!

Enterprise mashups?
Given this background, where are enterprise mashups? Well there was certainly plenty of interest, with David Gootzit from Gartner talking about their having a key role to play as the “face of SOA” and becoming an important way to build composite applications. However, listening to talks and speaking with attendees confirmed to me that while a lot of vendors and users have focused on using enterprise mahups to build simple “dashboard” type single page applications, there is a huge need and interest in using them to address the new integration agenda of business focused pragmatism and innovation. The idea of using the mashup approach to rapidly build process based applications for different user groups and tasks, leveraging a wide range of enterprise IT assets is – to judge from the response we had – just the capability that many organizations need. It seems that there are many cases where business process improvements and flexibility are needed but custom application development is seen as too slow, expensive and hard to maintain, and full blown WS-* and BPM are not appropriate.

Conclusion? SOA isn’t dead, just growing up in a rather more austere environment than the one it was borne into. And enterprise mashups can make a massive contribution, so long as they focus on really changing the economics of building and using business applications.

Labels: enterprise mashup, IT strategy, process mashup, SOA

Labels: agent desktop, call center, contact centre

One of the debates currently going on is regarding the lifespan and role of mashups (cpettey/Gartner). Are mashups just tactical, throw away applications for short lived micro-requirements that come and go in the business (aka situational requirements) with the associated business case challenges? Are they just good to temporarily paper over a gap while your systems catch up with user requirements? In other words, are enterprise mashups short lived either for the simplest of “applications” or simply as lipstick on a pig as suggested to me recently by the CIO of a very large telco?

One of the great values of enterprise mashups is that they can deliver in very quick time frames by leveraging exiting systems and applications to streamline processes for people. This can be to address a “situational requirement” such as a dashboard, combining RSS feeds for data reporting etc. They can also help mop up legacy applications before retirement i.e. provide lipstick on your old architecture while you deliver the new one. They can prepare for the deployment of packaged application such as CRM or ERP. This provides the value of quickly testing in real time, with real users the required “user process” (i.e. the set of steps a user need to go through to complete a task). This can even be implemented in the look and feel of the enterprise application. Users will then not be disrupted by the deployment of the enterprise app while deployment will be speeded up by “learning” from the tested user process implemented in the mashup. Once the enterprise application catches up, then the mashup can evolve to do less, be retired itself or remain to provide the flexible, process driven UI that would continuously require updating. This will depend on architectural decision.

It is in the flexible delivery of process driven UI that enterprise mashup become a key part of modern architectures and are destined to power solutions that will remain in use for a long time. Why? Because modern architectures need lipstick as much as the old ones! With WOA, SOA or any component based approach, user-centric applications are still required when a business process need surfacing to a user and those end up being built bespoke for each user group. This is because user interfaces are not service enabled, not turned into re-usable components. This is where enterprise mashups play a key part: with the creation of visual, mashable components that can easily and quickly be mashed up into user centric solutions, they provide a “face” to web services and deliver the flexibility and process adaptation required at the user level to deliver flexible architectures from top to bottom.

The answer to the lifespan and role is that enterprise mashups provide real value when they address real process pain point, have a role to play in legacy and modern architectures and can endure for considerable periods of time while the content and function continually evolve.

What do you think? Do you see the same trends?

Labels: CRM application, customization, enterprise mashup, mashup, Siebel, SOA

Corizon’s recent launch of mashup extension packs for Siebel and eBusiness suite has prompted a number of conversations with journalists on the extent to which this value proposition transferred to enterprises adopting SAAS applications. I was surprised by the initial perception that enterprise mashups were required because of the difficulty of deploying applications on premise. Conversely there seem to be preconceptions that the need would be much less with on demand applications.

Enterprise mashup adoption is driven by the need to transform the economics of integrating applications to make people more efficient. The deployment of new applications, whether they are on-premise or in the cloud,increases the requirements for integration. The more new SAAS business applications are adopted, the more such integration will be required. This is exactly the experience reported by GE CIO Gary Reiner: implementation costs for applications:

“...they're largely around interfacing with existing systems, process changes and data cleansing, those three costs exist regardless of whether GE hosts that application or whether the supplier hosts that application.”

As a matter of fact, cloud computing is even more adapted to enterprise mashups. The key reason for this is that they promote the concept of keeping each functional application as vanilla as possible to reduce costs. Why re-invent a CRM package and not just adopt best industry practice? Differentiation is not gained by modifying each application but by integrating them to streamline your desired processes. For example superior end to end customer experience delivery is more likely to be achieved by seamlessly integrating the different applications required to support a particular customer journey (trouble ticketing, service diagnostics etc.) rather than customizing each application. This is where enterprise mashups play a critical role: by providing a quick and non intrusive way to create mashable components from existing applications and easily combining them to mashup a fit for purpose solutions that guide users to complete a task, they are perfectly suited to integrate your cloud with your on premise applications.

We are big proponent of service based applications at Corizon – this is where the company started! We also happen to believe they will be one of the key drivers to accelerate adoption of enterprise mashups. As enterprises adopt SAAS, they will be looking for new approaches to quickly, flexibly and cost effectively integrate their new cloud applications to allow people to do their jobs better. In the same way that enterprise mashups transform the economics of owning on premise enterprise applications, they will transform the economics of integrating cloud applications.

Labels: Cloud Computing, CRM application, customization, enterprise mashup, ERP application, IT strategy, mashup, process mashup, SAAS

• experienced agents need to be able to work in a less constrained way compared to rookies, and will find constraints demotivating and frustrating
• new products are often trialled and launched with very broad cones while the organization learns using highly skilled agents. As the products mature and the agent base grows, processes then need to become more constrained and more “spout heavy”.
• knowledge management solutions can be used to narrow the cone sooner by reducing the up-front analysis work for service desktops
• sophisticated propensity-to-buy and segmentation based intelligence can help to move to the spout quicker and optimize outcomes

Labels: agent desktop, call center, contact centre, enterprise mashup

Labels: CRM application, customization, E-Business Suite, enterprise mashup, ERP application, mashup, Oracle, Siebel

Spending time recently in a contact centre reminded me of a quip I heard from Lord Saatchi. He was talking to a senior director of a well know consumer brand and saying: “do you know the old saying about half of your marketing budget does not deliver but the issue is which half? Well for your company, I have worked it out: neither!”

So which half of your IT budget works in the call centre? Neither. You just have to look at how many applications call centre agents have to deal with during a call! Research shows on average 6 but in our experience the number is usually much higher. This is despite years of investment in technology in call centres. The reason for the failure? Each time a new requirement for the agent emerged, a new application would be built or an existing one would be modified. This lead to a proliferation of applications on the desktop, making the job of maintaining them (and integrating them) harder and harder for IT. No wonder release cycle of enterprise applications on the desktop can now be measure in months or years! This results in inefficient processes with dramatic economic consequences: high cost to serve customers while delivering, in a majority of cases, a poor customer experience. No wonder so many companies decided to give up on call centres and outsourced them despite the fact they are one of the most important (and inescapable) windows to customers.

This is why call centre is such a ripe environment for the deployment of enterprise mashups. By changing the economics of building and maintaining integrated solutions to call centre agents, they address the application proliferation issue, reduce dramatically the cost to serve customers by making agents more efficient and deliver clearly measurable ROI in short time frames. This is where we think the real value of enterprise mashup can be realized: in delivering real composite applications to address immediate business needs but in a way that is repeatable and complements modern architectures. A theme I will come back to regularly in this blog.

Labels: agent desktop, call center, contact centre, mashup, process mashup

Labels: Avaya, call center, Corizon partner, CTI, enterprise mashup

I have just completed a new whitepaper titled The Case for Enterprise Mashups. The paper discusses current troubles with software development and explains how Enterprise Mashups are in a perfect position to address them. You can download it here.

Labels: enterprise mashup, whitepaper

Labels: CRM application, customization, IT strategy, mashup

Why do we need Enterprise Mashups as a capability of IT? As Dion Hinchcliffe explains in this post, there is a lot unmet software demand due to small projects not being economically viable:

... almost any IT system is going cost in the hundreds of thousands or low millions even to get off the ground. This means that many smaller, niche demands, which statistically, are very likely to be larger than the demand for big IT systems in an organization (The Long Tail), are actually continuing to go dramatically underserved ...

As he further explains, Enterprise Mashups are in a perfect position to enable the business to fulfill this demand. What is not talked about, are the different deployment options of these mashups. Depending on the context of the functionality it delivers and the type of user it delivers it to, the deployment pattern of the mashup should change. For an "ad-hoc" pattern, you might want to deploy the mashup as a gadget on the desktop. For a "project" pattern you will want to deploy it inside a project portal, while for a "process" pattern you will want the mashup to be deployed as an extension to an Enterprise Application.

Choosing the wrong deployment pattern of a Enterprise Mashup could restrict its benefit and in some case dramatically increase the number of applications on the desktop. Especially when deploying an "ad-hoc" pattern where a "process" pattern would have been more appropriate, the user will suddenly need to become aware of what mashup are relevant to which task and where to find it. He or she will have to copy data to and from an Enterprise Application and mashups. The ultimate swivel chair nightmare!

So what does it mean to extend Enterprise Applications with mashup capabilities? It means facilitating the embedding of mashups inside these applications so that the business is able to add functionality to them for their specific "long tail" needs, e.g. extending a CRM application with a Network Diagnostics Mashup for the customer's region to enable the agent to anticipate and analyse possible causes of connectivity problems. By providing this capability the short lived, specific requirements of a business division can become part of the same application that is serving the long term requirements of an entire enterprise. But this time, it can deliver this to a specific user groups and for a specific process only, without requiring changes to the underlying application. This is what we at Corizon call "Integration without Customisation".

Labels: CRM application, Enterprise applications, enterprise mashup, mashup patterns, process mashup

During World War II the American government faced an unprecedented challenge: the need to increase industrial output while its workforce was depleted by troops away fighting in Europe.

To overcome the problem, the government published a guide to improving efficiency for its employees and departments. Some sentences caught my eye:

“Look for hundreds of small things you can improve. There isn’t time for major items. Look for improvements on existing jobs with present equipment.”

Sound familiar? Do you need to make changes to your business: to maintain momentum, manage through the downturn, or exploit new opportunities? How can you accomplish these goals when resources such as your workforce, sales revenues and operational cashflow are under pressure?

As the Dow hovers below 7,000 points, once-steadfast blue-chip shares trade below a dollar and every economist’s crystal ball has gone suddenly cloudy, this is not the time to throw away what you have and buy new.

Instead, any change should be incremental and designed to protect and maximize every valuable asset within your business: people, knowledge, technology infrastructure, software and successful processes.

This philosophy - to do things faster with fewer resources at lower risk - is at the heart of what Corizon does. We help businesses deliver faster, more cost effectively through an approach of incremental change: review existing processes; adapt existing applications (even eliminate redundant applications); drive user efficiency, through a succession of short, low risk projects - and by extension protect and increase revenues, profitability and customer satisfaction.

Today’s businesses and government departments would do well to leaf through some old government handbooks. There’s a lot to be learned from history.

Labels: IT strategy, mashup, recession

In a recent blog Deepakalur from JackBe proposes a new tier for Enterprise Mashup. In this architecture an additional logical layer is introduced, the mashup layer, which sits between the business and presentation logic: Assuming that the presentation logic includes the application logic, this architecture makes sense for the types of mashup he is discussing, i.e. data mashup. It isn't however applicable to all types of mashups.

Ron Schmelzer from ZapThink hilightes the difference between data mashups and process mashups as the different answers to the requirement for different levels of situationality and levels repeatabilty, with process mashups deemed more appropriate for repeatable processes that require some level of situationality. At its core, process mashup are about introducing a level of agility into the process of stringing together services into an application, or SOBAs as Ron calls them:

Situationality, therefore, is not always a priority with mashups, as situationality is less important than repeatability for most automated processes. After all, the reason you'd want to automate a business process in the first place is because you expect to run the process many times, otherwise automation would never be cost-effective. Situationality and repeatability, however, are two ends of a spectrum; the interesting processes from our standpoint are the ones that fall in the middle somewhere. Such processes have a level of variability that requires a measure of situationality to the applications that implement them, while being sufficiently repeatable to warrant automation. It is such processes that process mashups (and SOA in general, for that matter) are particularly well suited for.

At Corizon we have introduced this approach to support agile development of user facing application. In this approach user requirements are met by stringing together UI Services into User Processes, as discussed here in detail. For this, a new architecture is required, one that is built to support easy rewiring of UI functions, without rebuilding the UI.

In this architecture the, different user groups can combine UI functions as they see fit, without having to create many variations of the same UI. This is critical for the succesful deployment of a process mashup.

Different types of mashups solve different problems and each of these require different architectures. So when you're embarking onto the Enterprise Mashup journey, make sure you pick the right tool for the right problem.

Labels: architecture, data mashup, process mashup

In its lead column this week The Economist states: “The world has not seen a contraction like this since the first oil shock in the 1970s”.
 
The impact of the downturn is unprecedented for our generation, and is the largest slump to hit the technology-driven economy. It’s damaging and yet at the same time progressive, in that it drives us to think about new ways to do business and to deploy technology to innovate, transform and survive.
 
Businesses understand the need to invest in technologies that cut costs, enable knowledge to be shared and provide an essential competitive edge. Innovation and process transformation are fundamental, but the unpredictable climate means this is no time for big-bang approaches.  They must find ways to transform their operations that require low – or no – capital investment and which produce positive, measurable results with a quick return on investment.
 
At Corizon, we see this philosophy in action. Enterprises that handle high volumes of customer interactions, for example, need to increase the efficiency and reduce the cost of their call centre operations while increasing the value of each customer interaction. They need to find a way to cut the cost of servicing customers – e.g. by offering customer self-service – that doesn’t involve abandoning their existing IT systems and buying expensive new ones.

This need to innovate without spending a lot of money is prompting businesses to explore better ways to improve their existing processes, applications and data. Enterprise mashups fit the bill perfectly, by allowing organisations to transform their business processes using existing applications and data in short project bursts with demonstrable return on investment.
 
A recent post by my colleague David Davies highlighted the staggering results that Homeserve has achieved from its use of enterprise mashups: a 50% increase in cross-sell with slashed call handling times, all using existing applications and processes.
 
Technologies such as enterprise mashups enable innovation to go hand in hand with conservatism. The businesses that will survive are the ones that can be conservative and creative at the same time. 

Labels: agent desktop, call center, insurance, mashup

Labels: CRM application, customization, mashup, Siebel

Considering the views on what constitutes an Enterprise Mashup are so varied, I have decided to, in true Web 2.0 style, conjure up the collective wisdom of the interwebs, and started a poll on the subject here.

The poll will run until I have enough responses, after which I will do some analysis and report back. 

I'll be speaking at the 1st International SOA Symposium in Amsterdam on  7 October, i.e. tomorrow. I'll illustrate how enterprise mashups are key to a successful SOA approach.

More details here : Composite Applications for Users

See you in the Coca Cola Lobby , 11.15 - 12.00.

We're already on the penultimate day of Oracle Open World 2008. We've been geting loads of interested visitors at the booth, directly and indirectly via AIA. It's awesome to see people really getting the product, and being able to identify themselves with the problem it solves. Tonight is the big closing party on Treasure Island , to which Eric has managed to get tickets. It's hard work these conferences!

btw, here is a blog on the keynote in which Eric presented. Demo was indeed cool!

The team at Corizon is all set for the trip to San Francisco. In the next few days, Eric Guilloteau, David Davies, Toby Baker and myself will be attending and presenting at the Oracle Open World 2008. Full details can be found here : http://www.corizon.com/OOW/ .

Keep an eye on this blog in the next week for live reports from the conference.

See you there!

There has been a lot of talk around mashups and SOA recently, and how they do or do not fit together. One view is that mashups enable IT to visualize the SOA to the business. Another is that mashups have no place in the enterprise due to the lack of governance over what gets built, how it gets built, and who gets to use it.

In an ideal world, one would be able to provide a face to SOA in a controlled manner, a UI that has all the good things of a service: discoverable, manageable, secure, whilst providing the consumer with the ability to modify and recombine pieces of this UI as they see fit. At Corizon we have built precisely this capability: the UIService. A UIService implements a lightweight RESTful interface which provides structured access to UI elements, extending the SOA pattern to the UI:

• enables service producers to provide a UI with their business services
• enables service consumers to discover, consume, modify and mashup the pre-built UIs
• provides central IT with the required control

The UIService is the ideal marriage of lightweight technology and enterprise grade capabilities. To learn more about them, see http://www.corizon.com/Products/ui_services.php .

One of the big attractions of a SOA is the ability to connect to and consume running (web-)services, without having to worry about how to deploy, run, and manage these services. This wasn't always the way people thought of allowing reuse. In the not too distant history, these business services would have been built as reusable binary components, which would be shared between IT projects in the business. This type of component based reuse had several drawbacks. Here are a few of them:

• Updating a component required rebuilding and redeploying an application
• Components had design, build, and runtime dependencies, making them more and more fragile and complex to use
• Unforeseen differences in runtime environments caused unpredictable behaviour of these components that were difficult to debug and fix
• Components were development environment specific, e.g. VB components wouldn't be reusable in a Powerbuilder environment
• Components could, and often would, tie the consumer into vendor specific libraries
• Access to the binary components allowed the consumer to reverse engineer the code
• Access to the binary component put more requirements on security of the component internals
• No visibility on the use of the component

For these reasons, it made sense for businesses to move to an IT infrastructure that promotes the runtime sharing of services.

With this in mind, it is interesting to see the current approach to UI reuse. Several IDEs and frameworks are creating an environment in which UI component will be shared across the business at the binary level. This will create the exact same issues as we have seen with binary reuse of business components. The only way around it is to enable the runtime reuse of UI. The technology that allows this is called a UIService and is exactly the technology we have built at Corizon.

Although not fully embraced by everyone, it is undeniably true that agile development methodologies have a number of advantages over more traditional, waterfall approaches. The key is the “release early” & “release often” mantra, allowing for continuous feedback between the analyst, end-user and developer. The end result is an application that does more of what the user needs, and less of what others think the user needs.

SOA brings together the best practices of 20 years of software architecture and design. Admittedly, none of its components are new, but never before have all these components been put together into a single open architecture. Combine this with the ubiquitous http network, and you end up with design patterns and a base technology that can make a difference in the way the business can profit from its IT.

At Corizon, we have added the UI Service to this mix: a UI Service provides the means to discover and use UI as one would when accessing data or process services. The service enabled UI, unlike gadgets, widgets and portlets, provides enough metadata and structure to allow the consumer to easily make modifications to this UI, e.g. hiding elements, moving elements or seamlessly combining two elements into one.

These three ingredients open the door to agile development of fit-for-purpose Enterprise Mashups to the end user that wasn’t possible before:

• More agile : Using UIServices the solution developers don’t have to concern themselves with the problem domain of the underlying business processes, but instead can focus on the needs of the end users, reusing the prefab UI components, and assembling them into a solution.
• Fit-for-purpose: The prefab UI components are built and maintained by the domain experts. This guarantees the highest quality of “raw materials” for the consumer. In addition by providing the UIService consumers with the capability to modify the UI to fit their needs, the solution developer is able to deliver an application that is fit-for-purpose.

Without UI Services, this agile development of fit-for-purpose Enterprise Mashups will require too many compromises, resulting in a slower release cycle and a far from ideal user interface.

Recent coverage under the heading “Corizon sets new SOA perspectives” seems to have caused some consternation. It triggered a letter from Tim Holyoake at SoftwareAG in the December print edition of Information Age (seemingly not available on-line) complaining that

“[The article] gives the impression that Web 2.0 user interface concepts are a panacea for delivering effective and usable applications to end-users. … The consideration of application users' interface needs to form part of the whole, not an alternative. The key message is that one crucial point must be considered when the SOA delivery approach is chosen, regardless of whether Web 2.0-style user interfaces are deployed or not: effective SOA governance must be in place from day one.“

Absolutely! Effective architectures need a well thought out and implemented approach to governance.

The question to ask is this: if software services underpinned by governance are key to allowing re-use and agility with control, why don’t those concepts need to apply to the user interface? An SOA that only talks in terms of services that provide data and logic puts the creation of UI fully in the hands of the consumer, with every chance of the poor results summed up by Geek and Poke...

UI must be built each time it is needed, with no possibility of re-use, consistency or control and all existing investments in UI must be thrown away. That doesn’t seem like making UI “part of the whole” in terms of SOA.

The Corizon vision is to close this gap, allowing services to provide re-usable self describing UI as well as their more familiar data, in a secure, safe, governed fashion. So we agree, it’s just that we think governance and re-use need to go further.

• Frequently cited uses of enterprise mashups - "mopping up the long tail" and building "situational" applications - are great, but if that’s all there is to mashups then a huge opportunity is being ignored. The processes that businesses rely on need people. Those people need transactional applications that support them as they work through their tasks. Look in any call centre or back office and you will see that even after years of investment in application development, customization and integration, the IT they have to work with is anything but streamlined or joined-up. Boosting performance by giving these users fit-for-purpose productivity applications in a responsive, agile manner is where a mashup style approach is desperately needed. Of course, focusing on this problem space also raises the bar for enterprise mashup functionality, scalability and robustness!


• Contrary to a lot of the hype currently circulating, end users don’t have the skills, time or inclination to build or maintain more than the simplest mashups; shop workers, outsourced back office staff or call centre agents probably shouldn’t be spending time reconfiguring the applications they use every day! Rather enterprises need to put process owners and analysts in charge of the construction, deployment and improvement of the applications their teams use.


• The combination of complex functionality and simple assembly needed by Enterprise mashups needs re-usable UI to be available as a service. Just as most mashup builders wouldn’t think to build their own mapping UI, and naturally re-use one from Google or Yahoo, so enterprise mashups need to be able to combine functional UI building blocks that service difference functions (billing, service management, account management etc) into a new application. That way application developers and owners can “produce” common business functionality for re-use across the business while “consumers” can customize and combine it into new applications without the skill or knowledge that the producers need. This kind of production and consumption isn’t available in most SOAs and mashups, which might explain the some of the disillusionment that can be found in real world projects.

At Corizon we’ve created technology that acts on these ideas. Now that enterprise mashups are getting more attention, we want to share our ideas and what we’ve learned more widely, and we’ll use this blog to do so. Let us know what you think and keep an eye out for future postings.