Enterprise Application 2.0

Copyright © 2009 James Taylor. Visit the original article at Enterprise Application 2.0.

As organizations try to achieve agility, productivity and efficiency they often look to new technologies, new approaches to change the status quo. But when it comes to information systems, most large enterprises have an electronic backbone of legacy enterprise applications. Whether packaged or custom developed, these are “1.0” enterprise applications. Or, more bluntly, dumb applications. And these dumb enterprise applications have a number of critical problems:

• They wait when they should act
  At best they tell someone that something needs to be done, mostly they just sit there until someone comes along and tells them what to do next.
• They accumulate data but don’t learn from it
  If you ask them really nicely they might regurgitate all the data they have in a report or a dashboard but it is up to you to decide what this data tells you.
• They assume escalation not empowerment
  The assumption is that tasks require a person and that different tasks require a more or less senior person so tasks are escalated until the right person is found.
• And they’re opaque and hard to change
  Changing …

Copyright © 2009 James Taylor. Visit the original article at Enterprise Application 2.0.

As organizations try to achieve agility, productivity and efficiency they often look to new technologies, new approaches to change the status quo. But when it comes to information systems, most large enterprises have an electronic backbone of legacy enterprise applications. Whether packaged or custom developed, these are “1.0” enterprise applications. Or, more bluntly, dumb applications. And these dumb enterprise applications have a number of critical problems:

• They wait when they should act
  At best they tell someone that something needs to be done, mostly they just sit there until someone comes along and tells them what to do next.
• They accumulate data but don’t learn from it
  If you ask them really nicely they might regurgitate all the data they have in a report or a dashboard but it is up to you to decide what this data tells you.
• They assume escalation not empowerment
  The assumption is that tasks require a person and that different tasks require a more or less senior person so tasks are escalated until the right person is found.
• And they’re opaque and hard to change
  Changing their behavior requires editing code, changing configuration tables or other, geeky activities. These activities must be pushed through the IT bottleneck and have a heavyweight release cycle.

So what about Enterprise Application 2.0? While some things are widely held to be essential – service-enablement, component-level purchasing, social/web 2.0 enabled, etc. – I think there is more to it. I liked Tim Minahan of Ariba’s post – Enterprise Applications 2.0: Back to Basics. In this he identifies three key elements for Enterprise Application 2.0:

• Simple… lean techniques, Web-based delivery, and consumer-like interfaces – simplified configuration, a walk-up user interface more akin to Amazon.com than legacy enterprise software.
• Intelligent… advanced analytics and decision support within the context of the business process… advanced decision support tools to enable even the casual user to quickly analyze this wealth of information and test a variety of scenarios before making a final decision.
• Networked… Web-based networks and communities… partners across the street or around the globe.

A good list, though his comment on “Intelligent” is a little too passive for me. Anyway, here’s my list for Enterprise Application 2.0:

• Agile and transparent
  The behavior of the application is transparent to the business – they can see what it is doing, why it is doing it. And it is agile because these same business people have some ability to change that behavior quickly and easily – without a heavyweight release cycle and without being forced through a narrow IT bottleneck.
• Empowers a flat organization
  The application assumes that customers want to serve themselves, that devices/websites/kiosks need to be self-contained and that when staff are involved that the first staff member engaged on a customer problem should be able to resolve it. This mean avoiding manual approvals and escalations – it means an application that can act appropriately on its own.
• Uses the data it accumulates to act analytically
  The application does more than just collect data about customers, orders, returns, service calls – it assembles and analyzes that data using analytics to simplify it while amplifying its value. These analytics drive behavior so that the system “learns” from the data it collects.

A modern organization needs to be supported by a portfolio of 2.0 applications, yet existing applications cannot be ripped out and replaced – they must be innovated in place. Tomorrow, some thoughts on how to do this.

On this topic, I have a proposal in to speak at the Enterprise 2.0 conference and they have voting set up on their home page (http://www.e2conf.com/sanfrancisco/index.php). It is not the greatest interface – in fact, it’s terrible – but if you can grind through and find my proposal on Page 8 of 16 and then vote for it, I would appreciate it!

Link to original post