Columns

Reporter’s Notebook: Risk is real

• By Jack Vaughan
• July 31, 2003

It may be early yet, but it is quite possible that the notion of the real-time enterprise will confront the IT development manager with a risk-reward problem of the kind that can make or break a career.

Application integration has gradually become the number-one job for a lot of IT departments -- that much is well known. The growing question will be how fast can users move data between apps and, while you are at it, could you please arrange it so that one app quickly kicks off another app (and so on) in a sequence that matches a new enterprise business process model?

Some people call this “orchestration,” while others call it “choreography.” Both terms belie the work involved in making the real-time enterprise happen.

Data integration specialists emerging from multi-year efforts to build corporate data warehouses know the song, too. “Why can’t our operations and analytical data pools be one and the same?,” they are asked. Or “Why can’t I get those sales figures every 40 minutes, instead of every four hours?”

The system elements that would support such functionality are within the reach of today’s technology, and there are even a handful of real-world examples of real-time enterprise systems. Automation has always been IT’s objective; the real-time enterprise is merely a version of automation that wrings out every last bit of latency. The problem is that those last few seconds of latency a’wringed may cost the corporation more than they are worth.

This is where application development resembles aspects of other professions. It may be difficult to convince the stock buyer, home builder or CEO that (a) the stock is too volatile or (b) that the color will make them nauseous or (c) that they’ll change their mind when they see the bill for that executive dashboard. You have to make the case if you are true to your principles, yet some compromise must be struck. As it was said of IT management in these pages last month, “You don’t succeed long ... just saying ‘No.’”

On a larger stage, this problem was summed up by Jawaharlal Nehru, the first Prime Minister of an independent India, who said: “The policy of being too cautious is the greatest risk of all.”

************************************

The real-time enterprise should be pursued, not avoided. The real-time enterprise is an intriguing concept, and our bet is that it will come to life during the coming years. This was borne out in a recent conversation with Jnan Dash, an eminent technologist who is much interested in the real-time enterprise these days.

In stints at IBM and Oracle, Dash played important roles in the development of DB2, Oracle8i and Oracle9i. Today, he consults and “acts as mentor” to a number of promising start-ups in real-time enterprise software, networks and related fields. We spoke to Dash as he was preparing a session he will moderate at the Application Development Trends Management Symposium in Boston (August 13–14, 2003).

For CIOs today, the drive is on to cut down on latency and labor, said Dash. He provided a quick view of how we got here.

“We started this thing back in the late ’80s at IBM where two of my colleagues coined the phrase ‘data warehouse.’ In those days, a 50-Mbyte-size data warehouse was considered a big deal. It is as hard to remember those days as it is to recall what life was like before electricity!

You would take your transactions over time and that would become your data warehouse. The poster child for this was Wal-Mart.”

Star schemas appeared, then OLAP and multidimensional data views. At times it got silly, Dash remarked.

“We got into a funny debate of ROLAP vs. MOLAP. What a waste of time. Who cares as long as I can give you the information in four different ways. You are the sales manager and you want to see sales by region. You are the product ‘guy’ and you want to see forecast by product type.

Then there was another group that said ‘This pie in the sky warehouse is too big a risk.’ We’d like to do this departmental thing called data marts. So some people got carried away on that path and created too many data marts, and then we were back to square one.”

Without an overarching architecture that guided planning, the means they used to solve the problem tended to increase the problem, Dash said.

Then came the Internet, click-stream analysis, customer profiles and the like. Another force that came into this picture was the packaged application.

“The packaged apps were mostly designed for clerks who might do order entry all day. High-level executives and knowledge workers were left out.”

So IT started to pursue the notion of key performance indicators, which were rolled up to the top executives.

“Now we have gone through the Internet boom and bust -- everybody’s gloomy, but the truth is that’s a very natural cycle. It is nothing new. Too many companies ran into this space [and] now we are saying: ‘Let’s be careful and figure out what this is all about. And this is the beginning of the notion of the real-time enterprise.

I meet with CIOs, and they tell me: ‘The pressure on me is to cut down latency and labor. Everything that took four hours should happen in four minutes. Anything that took four days, I’d like to do it in four hours.’

Dash tells technologists discerning risk-reward here to visualize two circles sitting side by side. One circle represents operational and transactional elements such as ERP, CRM and mainframe data. The other circle represents a snapshot of data, and this represents the data warehouse or analytical sphere. As these two circles move to partially overlap, suggests Dash, the real-time enterprise appears.

It is the frequency of the refresh of the analytical snapshot that defines the amount of “real-time” involved. A company pursuing a strategy like Wal-Mart’s may have to opt for what Dash calls “extreme crispness” in its snapshot. Others may rightly decide day-old data will do for certain functions.

************************************

How much risk can your project take? You run down a checklist and everyone agrees that there are no “showstoppers.” But deadlines, people power and requirements often merge in a mesh that comes to haunt you when the night is late and it is time to rest. Perhaps a book on risk and software might be what the doctor ordered. Such a tome recently came from Messrs. Tom DeMarco and Timothy Lister.

In their latest effort, “Waltzing with Bears: Managing Risk on Software Projects,” DeMarco and Lister look at the role of risk in software development, concluding that it is at least as important a factor in project success as are software development processes. It is a good read: food for thought that may sate the application development manager in the long night of a Death March project.

DeMarco and Lister have long been at the forefront of software engineering. Their 1987 book, Peopleware: Productive Projects and Teams, one of the must-reads of software development, took a look at why software projects fail, and came to the now-famous conclusion that the work culture of organizations pursuing development was more likely to influence project outcomes than the amount of technology employed or the size of the labor force directed at the task.

Their writings on risk are timely, as firms arise from the dark cave of risk aversion. “The business of believing only what you have a right to believe is called risk management,” the authors tell us. Risk can’t be avoided, they point out; if something is truly innovative, and can actually offer great reward, it will be worth doing and it will entail risk. In days when risk avoidance and cost cutting seem the only recipes offered for technologists, their words come as something of a tonic. DeMarco and Lister advise readers, “If a project has no risks, don’t do it.”

Among the core risks they cite in software projects are inherent schedule flaws, requirements creep, poor productivity and “specification breakdown.” This last risk refers to the collapse of the negotiation process that is at the heart of the requirements setting.

The Denver International Airport automated baggage system software fiasco of 1993 comes in for analysis, and it is an example of the authors’ refined sense of skeptical examination. The project planners failed at risk management there, but DeMarco and Lister suggest that the software development part of the operation may have been a mere cog in the overall crumbling mechanism of misplaced risk aversion.

The possibility of overall system failure -- if the critical-path auto-bag handler did not operate, the airport could not meet a publicized opening date --could have been mitigated by non-software alternatives, the kind of traditional “peopleware-based” bag handling operations that were well understood ... if several parameters in the airport’s overall design had left some leeway. Software seemed to be the only suspect that “accident” investigators pursued here, the writers suggest.

“Waltzing with Bears” (its name taken from a Dr. Seuss song) is worth a read by workers at any stage of the software risk chain. The authors even offer a free, downloadable Monte Carlo risk calculator from their Web site for those who want to run their risks through a clever software grinder.

..............................

Click here to read the Briefing Book on real-time enterprise.