Orchestration gets everyone one on the same page

So here the irony: the person with the word “Information” in their job title. The CIO, has no information about how their business is running.

Yes, I know they think they have information, but the reality is they have opinion masquerading as pretty Gantt charts fooling them into thinking they have data about the state of their business. If we continue to think that going to status meetings is the way to get status we will continue to struggle to run IT and we will never deliver the kind of quality, value for money and timeliness the business is demanding.

When the CFO asks if invoices are paid we do not have a status meeting. We offer up empirical data showing the exact disposition of each and every invoice accurate to the penny from our computerized systems.

So why can’t we do that for IT projects?

As one customer said to me recently in New York, “because developing software is not like invoicing” and they are right. Invoicing is incredibly complex and integrated into the fabric of the business so deeply that just about everything we do affects invoices.

Developing software is a straight forward process, follows a more-or-less linear progression, the rules are really clear and we have software to enforce them. My mentor and friend, Doug Troxel, once said to me “How can your job be so difficult when all you have is a ‘1’ and a ‘0’?”

So why is it that we continue to try and run IT as a manual process?

I know we think we have automation but what we have a hundreds of point tools (723 according to a  VP of development at EADS and over 200 according to a VP of development at Ford). These tools help individuals complete their part of the lifecycle but they do nothing to assist in the hand over of information from one silo in IT to the next.

This is what I call the Archipelago Problem. Lots of islands of technology but no integration between them other than rickety rope bridges and a few dugout logs acting as row boats. What we need is Highway 1 from Key largo to Key West that is high speed, uniform and consistent.

Today’s software delivery processes are error prone, contain much that is duplicative and involves significant amounts of rework. If we sent invoices out that were wrong what would we do? If we sent invoices out twice what would we do? If we had to correct invoices and resend them what would we do?

That’s right – we would find where the error was in the process and fix it and we would try to automate it so it doesn’t happen again.

This is what we must do for the software delivery process.

In the next three posts on Orchestrating Application Delivery I will look at how that might be achieved.