I make no secret of the fact that I see development these days as more about orchestrating and delivering holistic business services than about writing code—although writing some code is still important, of course, for the components that make up the services. Which is probably why I find myself at PCTY2010 (PULSE Comes To You) in London, the road-show version of PULSE (Tivoli's User Conference) user conference. It's good to meet the movers behind Tivoli in person rather than by Webcast, no matter what "techie 2.0" thinks about wetware interfaces.

I'm talking to Snehal H. Parikh (Director, Tivoli Product Management, IBM Software Group) about systems engineering (which, to my mind, bridges the gap between business process automation and conventional computer applications). We talk about using ITIL as a framework for automated business service delivery, in a future in which conventional systems development and programming is just one option (used for systems which give real competitive edge) and most IT systems are obtained as rental services (using PaaS or SaaS, Platform or Software as a Service)—although I should note that although IBM is seeing some IT systems obtained as rental services today, with the trend growing, this represents only a minority of current systems. We talk about the vital need to break down existing silos: Development; Operations; Business Analysis etc. These are all more or less equal players in the delivery of automated business processes which deliver business outcomes in line with the strategic vision of business management. The days when an IT group could proudly deliver an expertly crafted, high quality application for an area of business which is being abandoned as non-profitable should be well past!

At this point, I usually point out that a computer program has no value until it is running in an operational schedule doing real work for the business. So, application "design for operations" is vital—applications must be easy to implement, robust and resilient in operational use, secure and fraud resistant, easy to tune in operation, instrumented for operational monitoring—and easy to decommission at "end of life". Since an application is presumably designed to deliver business value, if its failure to deliver the characteristics needed by Operations delays its production use, the delay costs real money, the lost business value the application should be delivering.

This is really risk management—there is a risk in putting an operationally compromised application into production; but there is also a risk in depriving the business of the application and the value it delivers. "Design for operations" is all about addressing the operational issues by design, so that a new application can transition into operation quickly, efficiently and effectively. Also, as we shall see later in this series, the "values" I've been tossing around are not quite as simple as I imply: a future value is worth less than a present value (partly because there is a risk that you won't get it) and an application program does have a value before it is implemented, just a highly discounted value, because the inherent value of a piece of software is only realised in the years of use by the business—while Operations are looking after it.

In Part 2 of this series, I'll look at what is happening to the security silo.