Enterprise Mash-Up

You are currently browsing articles tagged Enterprise Mash-Up.

The original mash-ups were simple things. Solutions like the Chicago Crime and AlertMap pulled together data from two or more sources (maps and crime databases, in the case of Chicago Crime) to create one single view. Previously I would have had to access these data sources separately–find, select, remember, find, correlate, click. With the mash-up this multi-step and multi-decision workflow is reduced to a single look, select, click. Many decisions became one, and I was no longer forced to remember intermediate data.

TQM, LEAN, et al tell us that unnecessary decisions are a source of errors. If we want to deliver high quality at a low cost (i.e. efficient and effective knowledge workers) then we need to eliminate these decisions. This brings a few immediate benefits:

  • More productive knowledge workers. Our knowledge workers only spend time on the decisions that really matter, rather than on messy busy work.
  • More effective knowledge workers. Fewer decisions mean fewer chances for mistakes.
If we were to use mash-ups in this way to simplify key, call centre processes (for example) then we can can translate these two points direct into business benefits:
  • Reduced staff on-boarding costs, cutting training time, and reducing time to competency by providing a simply and more direct workflow, one which leads the call centre operator through the workflow.
  • Reduce call servicing costs, including reduced escalations and improved first call resolution by avoiding mistakes and and ensuing that the operator has all the information required to solve the customer’s problem on hand.
  • Improved staff retention, by allowing them to focus on the customer engagement, rather than soul destroying swivel chair integration.

With a typical call centre agent using six applications per call, this represents a drastic simplification of the call centre work environment.

A third benefit is the decoupling a mash-up creates between presentation and back-end applications. As all user interaction is mediated by the mash-up, there is not direct connection between the data and function provided by a single application, and the work surface the knowledge worker interacts with. This enables us to evolve the UI and back-end separately, allowing us to keep the user interface in sync with business demands while continuing to pursue a separate, and longer cycle consolidation effort to consolidate backend systems to reduce operational costs.

It’s easy to extrapolate these (potential) benefits to other solutions. My favourite is human services, where providing a case worker with the right information at the right time, and removing unnecessary distractions, will result in a material difference in the quality of life for the people under their care. However, these benefits can easily be applied to any high value knowledge work processes, such as logistics exception manager, utility field worker, sales personnel, and so on.

Posted via email from PEG @ Posterous

Tags: , , ,

Inigo Montoya

Inigo Montoya

[Vizzini has just cut the rope The Dread Pirate Roberts is climbing up.]
Vizzini: HE DIDN’T FALL? INCONCEIVABLE.
Inigo Montoya: You keep using that word. I do not think it means what you think it means.

The Princess Bride

We keep using words these, but the don’t seem to have any meaning anymore.

Agile. It started with agile software, and seems to have spread like a virus to (agile) testing, (agile) architecture etc. At some stage we confused two ideas: agile delivery and agile outcome. One does not imply the other; while your process might be agile, being able to redeploy the team quickly does not guarantee an agile result for the business. You can make your architecture/development/testing team as agile as you like, but if the solution they are working on is a giant furball, then business agility will elude you. And by getting this wrong in the eyes of the business, we’ve made the term next to meaningless.

Architect(ure). Back when I was a lad, every geek wanted to be a grow up to be a systems analyst. None of us really knew what a system analyst did, but the title sounded good, they seemed to be senior and the pay was ok. Some time in the last few years, architect (and architecture) have replaced system analyst in the minds of aspiring software engineers. The minute we reach something like team lead we start calling ourselves “architect”. This puts software engineering in the strange position of having a surplus of architects, but very little real architecture.

Chief Technology Officer. Full disclosure, I carry the CTO title. I prefer to use the acronym rather than spell it out–to avoid confusion. With technology playing an increasingly important role in business, using technology well (or not) can have a disproportionate impact on a company’s performance. The idea behind a CTO is a good one: someone to advise how to leverage technology at a senior level. Though most CTO roles seem to be something else: head of development (nee VP Engineering) product management (Dir. Product Management), or just “big solution architect”. Using one title in so many different ways means that the title has little meaning to the business. I prefer to use the acronym, focus on helping the business solve problems, and let them make up their own mind on what it means.

Innovation. We have big innovations, and small. Industry defining disruptive innovations, and incremental innovation. There’s whole ontologies of innovation. We’re told to innovate our way out of recessions, and to innovate to remain competitive in bull markets. There’s a surplus of innovation activities, yet very little seems to happen. All this thunder without rain makes me yearn for more obliquity. Innovation should imply doing something useful, making a difference, rather than being reduced to a label for an ever growing consulting industry and a lot of talk.

Mash-up. From that first push-pins on a map solution, fusing data from a range of sources (GIS, reviews, yellow pages …), the mash-up concept seems to be growing to include an UI concept that we want to generate buzz around. iGoogle and NetVibes as mash-ups? Aren’t these just a SaaS version of the portals of old?

Synergy. Many things in the business world are done to release “synergies”. Mergers and acquisitions are driven by the quest for synergies. PowerPoint business plans are often considered incomplete unless they line up A and B, proudly announcing that synergies will make it all worthwhile. Why then, do promised synergies so rarely eventuate? We seem to use the term as a vague aspirational statement, rather than a call to action.

More terms as I find time. Send in your own and I’ll add them to the list.

Update: The Economist points out where synergy went wrong.

Update: Added “mash-up” after commenting on Enterprise Mash-Ups in Transition.

Update: You can find my attempt at a clearer and more consistent definition of mash-up over at We need a better definition for “mash-up”.

Posted via email from PEG

Tags: , , , , , , , , , ,

We seem to be torn between two masters. On one hand we’re driven to renew our IT estate, consolidating solutions to deliver long term efficiency and cost savings. On the other hand, the business wants us to deliver new, end user functionality (new consumer kiosks, workforce automation and operational excellence solutions …) to support tactical needs. But how do we balance these conflicting demands, when our vertically integrated solutions tightly bind user interaction to the backend business systems and their multi-year life-cycle? We need to decouple the two, breaking the strong connection between business system and user interface. This will enable us to evolve them separately, delivering long term savings while meeting short term needs.

Business software’s proud history is the story of managing the things we know. From the first tabulation systems through enterprise applications to modern SaaS solutions, the majority of our efforts have been focused data: capturing or manufacturing facts, and pumping them around the enterprise.

We’ve become so adept at delivering these IT assets into the business, that most companies’ IT estates a populated with an overabundance of solutions. Many good solutions, some no so good, and many redundant or overlapping. Gardening our IT estate has become a major preoccupation, as we work to simplify and streamline our collection of applications to deliver cost savings and operational improvements. These efforts are often significant undertakings, with numbers like “5 years” and “$50 million” not uncommon.

While we’ve become quite sophisticated at delivering modular business functionality (via methods such as SOA), our approach to supporting users is still dominated by a focus on isolated solutions. Most user interfaces are slapped on as nearly an after thought, providing stakeholders with a means to interact with the vast, data processing monsters we create. Tightly coupled to the business system (or systems) they are deployed with, these user interfaces are restricted to evolving at a similar pace.

Business has changed while we’ve been honing our application development skills. What used to take years, now takes months, if not weeks. What used to make sense now seems confusing. Business is often left waiting while we catch up, working to improve our IT estate to the point that we can support their demands for new consumer kiosks, solutions to support operational excellence, and so on.

What was one problem has now become two. We solved the first order challenge of managing the vast volumes of data an enterprise contains, only to unearth a second challenge: delivering the right information, at the right time, to users so that they can make the best possible decision. Tying user interaction to the back end business systems forces our solutions for these two problems to evolve at a similar pace. If we break this connection, we can evolve users interfaces at a more rapid pace. A pace more in line with business demand.

We’ve been chipping away at this second problem for a quite a while. Our first green screen and client-server solutions were over taken from portals, which promised to solve the problem of swivel-chair integration. However, portals seem to be have been defeated by browser tabs. While these allowed us to bring together the screens from a collection of applications, providing a productivity boost by reducing the number of interfaces a user interacted with, it didn’t break the user interfaces explicit dependancy on the back end business systems.

We need to create a modular approach to composing new, task focused user interfaces, doing to user interfaces what SOA has done for back-end business functionality. The view users see should be focused on supporting the decision they are making. Data and function sourced from multiple back-end systems, broken into reusable modules and mashed together, creating an enterprise mash-up. A mashup spanning multiple screens to fuse both data and process.

Some users will find little need an enterprise mash-up—typically users who spend the vast majority of their time working within a single application. Others, who work between applications, will see a dramatic benefit. These users typically include the knowledge rich workers who drive the majority of value in a modern enterprise. These users are the logistics exception managers, who can make the difference between a “best of breed” supply chain and a category leading one. They are the call centre operators, whose focus should be on solving the caller’s problem, and not worrying about which backend system might have the data they need. Or they could be field personnel (sales, repairs …), working between a range of systems as they engage with you customer’s or repair your infrastructure.

By reducing the number of ancillary decisions required, and thereby reducing the number of mistakes made, enterprise mash-ups make knowledge workers more effective. By reducing the need to manually synchronise applications, copying data between them, we make them more efficient.

But more importantly, enterprise mash-ups enable us to decouple development of user interfaces from the evolution of the backend systems. This enables us to evolve the two at different rates, delivering long term savings while meeting short term need, and mitigating one of the biggest risks confronting IT departments today: the risk of becoming irrelevant to the business.

Tags: , , , ,

Luis Derechin, of JackBe has just published a nice definition of enterprise mashups over at the Enterprise Web 2.0 Blog:

Enterprise Mashups are secure, visually rich web applications that expose actionable information from diverse internal and external information sources.

This seems to cover all the bases and should keep most people happy. I’d like it to include something about how the data is integrated to provide a single consolidated and consistent view of the information, as a traditional (but AJAX heavy) portal would probably fall into under the same definition. On the whole it still works for me though.

The most interesting thing, however, is the approach they used. Rather than gather yet another small group of smart people to write yet another manifesto, they took a more democratic route.

The team used a series of games and contests to engage the broader community, largely relegating themselves to a roll of guiding and coordinating the action. The end result were answers to three key questions:

  • What is an Enterprise Mashup?, (the definition from above)
  • How do you do create an Enterprise Mashup?, and
  • Why should an organization care about mashups?’

The answer don’t have the obvious “designed by committee” smell that these things acquire. I particularly like the statement on why to use enterprise mash-ups,

Poor decisions are often made because decision-makers do not have the right information at the right time. Enterprise Mashups deliver new insights and enable better decisions through personalized access to the right, real-time information for the specific problem at hand.

as it nicely captures the shift to a more use centred approach–something badly needed in enterprise IT.

Often it seems to the be the enterprise IT community that is the most resistant to change in an organisation. Sure, we might like to use the shiny new toys, but don’t you dare change how we go about our business. We’ll tell you what you need and the best way of doing it.

It’s nice to see that an old dog can learn new tricks.

Posted via email from PEG

Tags: , , ,