Bimodal IT doesn’t mean complexity

bimodal_itFor over a year the Gartner analyst group has been talking about the need for ‘bimodal IT’. An article in InformationWeek described it as the need for an IT organization to

split its focus between the core services that make other things possible and the more exciting possibilities of digital innovation.

When I first heard of bimodal IT I was still working in the ERP software space. Coming from that traditional background I used to think that any bimodal IT effort had to be somewhat big and complex. But now I’m at a cloud software company I’m beginning to see things differently. Continue reading


Responsiveness of cloud-based software

For a while I have been using a web-based service called Mammoth. Mammoth allows you to save text, images and other online content, as well as notes, into a single place for later use. In my case, I use it when researching issues I need to write about, or reference, for my job as a product marketer.

Mammoth allows you to create ‘boards’ which store the content about a particular subject. Boards can be shared so that people in different locations can edit the content collaboratively. A standard board in Mammoth is ‘Talk to Us’, which is shared with the Mammoth support team, and this allows me to address any issues I have with Mammoth online. Whenever I have logged an issue, I get a response via the board usually in a few hours.

In one case, Mammoth made a change to the user interface (UI) which made it look worse for me, so I logged a note on the Talk to Us board. There was a bit more discussion and clarification about the UI issue on the board, but what interested me was that 24 hour later when I logged on to Mammoth, the UI problem had been addressed. The application was fixed and changed without me having to do a thing.

It made me re-evaluate my view of cloud-based services.

  1. A problem with an on-premise application always requires the user to do something to fix it, usually download and install a software patch. With a cloud service, the problem is fixed once in the cloud, everyone gets it at the same time, and new software has to be installed.
  2. A problem with on-premise software is reported either by a phone call or an email, which then has to be discussed and confirmed before it can be transcribed and referred to the software development team. With a cloud service, you log an issue online in one place, the issue can be quickly confirmed and then be relayed speedily to developers.

Imagine if you could do that with enterprise software – ERP, CRM, warehouse management.

  • Customers could report problems so much quicker, and probably have a better support experience
  • No need for each customer to update the software with maintenance releases to fix bugs
  • Customer could log enhancement requests in a more effective way, and perhaps even get previews of enhancements before they go live
  • The development team work on supporting one codebase, in one location, for everyone
  • No need to ship CDs of software around the world

Wouldn’t that world be better? Oh wait, it’s called Software-as-a-Service and it’s here already.

The problem is that while the promise sounds simple and wonderful, the realities of transforming to that promise require major changes in thought, approach and practice – and moreover, for traditional software vendors, major investment expense.

Microsoft’s core strength

While I’ve not been a big proponent of Microsoft in the enterprise software space (I don’t believe they really understand it), I’ve always been impressed with their work in the server and development areas (the core areas that the company was built around). It’s in that latter area that I’ve had seen where Microsoft is doing good work – it’s the platform on which SYSPRO built its new Workflow Services product.

With the new version of SYSPRO 6.1 comes a new product, SYSPRO Workflow Services (SWS). Microsoft published a case study this month about it – Global Software Company Cuts Development Time for Workflow Solution by 80 Percent.

Because of our development track record, Microsoft invited SYSPRO into their Technology Adoption Program, which gave our dev team the opportunity to use the beta versions of Visual Studio 2010 and .NET Framework 4 for the development of SWS. .NET 4 included new features in Windows Communication Foundation and the new Windows Workflow Foundation (WF). Without WF, we could not have produced SWS.

What Microsoft did in VS 2010 was to deliver templates which effectively provided a rapid development environment. Project templates contain the project settings, references, and files that  are need to begin a certain type of project. Some of the default templates used were:

  • Activity Designer Library
  • Activity Library
  • WCF Workflow Service Application
  • Workflow Console Application
  • WCF/WCF Service Library
  • WCF/WCF Workflow Service Application

The project duration for SWS was about 3,500 man hours, and an in-house development methodology was used, which has elements of agile and scrum. Our Software Arcitect estimated that without the .Net 4 and VS2010 features, the development time for SWS would probably have been tripled or quadrupled.

The product that Microsoft provided SYSPRO to do the development was first class, and it makes me wonder why Microsoft doesn’t focus more on this core strength, an area in which they have long and deep experience. Instead, they get distracted by going into ERP (Dynamics), mobile phones (Windows Phone 7) and music consoles (Zune).

I have commented on this before – Is Microsoft like ‘old’ IBM?, The Microsoft-IBM analogy again. Do you think Microsoft is trying to be all things to all people?

How do you make A/P sexy?

So I am late into the debate that started some time ago – should enterprise software be sexy, like consumer software? There’s a nice summary of all the blog arguments here.

My comment is how do you make a tedious but essential process like Accounts Payable (A/P) sexy? What about the designing of a Bill of Materials structure?

Design and implementation of complex systems mis-understood

Having worked on a number of ERP projects, and seeing how they so often seem to run over time and over budget, I was heartened by some news:

  • the late delivery of the Boeing 787 Dreamliner
  • – the problems one of our customers has in delivering their designs and builds on time
  • – stories from engineer friends of mine who are struggling to keep projects on track and on time

The common thread to me is that these are all projects involving the design and implementation of complex systems, much like ERP projects.

The more I deal with manufacturing companies making complex products, the more I begin to think that sponsors and managers have unrealistic expectations about projects before they start. There also seems to be a general human problem that prevents people from grasping just how complex a system will become, especially where there are multiple points of integration.

Perhaps to be fair, Michael Krigsman’s IT Project Failures should also cover project failures in other industries. I’m sure the list would be just as good as the top 10 IT failures.