A shared data foundation

Getting reliable access to useful data is one of the prerequisites for empowering process owners — the people who are nominally responsible for running a business but who all too often have little or no control over what is actually going on it. Very early on, they discovered that IT, which had promised to give them better control over their business operations, instead made them so impenetrable that they had even less idea what was going on than before. IT's solution to this particular problem was the data warehouse.

By abstracting operational data into separate dedicated data warehouses, so the theory went, business people would be able to view and analyze the information in various ways, without impacting the continued operation of the original systems. Instead of having no information to speak of, they could have as much as they liked — so long as they didn't mind it being last week's rather than anything more up-to-date. That wasn't perfect, but it was better than nothing, which, you'll recall, was what they had had before.

But that was some while ago now, and today the Internet has led us to expect our information on demand. Analyzing stale information stored in a separate warehouse system is starting to look decidedly archaic, and there are other drawbacks too, like not being able to act on a problem thrown up by the analysis without having to change across to the separate operational system where the transactions are performed.

The solution to this separation of analysis and action is to enable both functions to work from the same data source. And so today there is a movement towards taking the three-tier data/logic/presentation model of present-day applications and applying it across the entire enterprise, so that the data becomes a foundation layer accessed by a separate layer of logical services, from which applications are assembled.

Vendors as diverse as Kalido, Composite Software, Above All Software and CXO Systems, along with others, are each developing their own responses to this movement. I'd like to take a more detailed look at each of their approaches, and I will do in due course, but first I need to raise some further issues that I'll deal with in my next posting.
posted by Phil Wainewright 8:18 AM (GMT) | comments | link

Putting process owners in charge

Who would you prefer to design your business processes? Your managers, or your software vendor? Amazingly, it has become the accepted norm for businesses to rely on backroom developers at enterprise software vendors to define their business processes for them. The doctrine of 'best practices' has sought to justify this cookie-cutter approach to process automation. But although everyone follows the mantra, no one really believes in it.

The result is absurdities like the case of Hackney Borough Council, a metropolitan district of London, which implemented Oracle Financials and then embarked on a major customization to tailor it to its specific needs. The result, reports Information Age, was a complete lack of flexibility: "The Oracle system was so heavily customised it prevented them from making any change to their business processes ... It locked them into the historical way of working."

This illustrates the typical dilemma faced by today's enterprises. The cookie-cutter 'best practice' processes offered them by the enterprise software vendors aren't right for their individual businesses. But if they try and customize the software to tailor it to their own processes, it becomes totally inflexible.

The more applications a business has, the worse the problem becomes. Processes inevitably cut across multiple applications, and integrations between those applications are, by definition, customizations — which simply leads to even more inflexibility.

Vendors have a new proposition, though, to help customers out of this quandary: cookie-cutter integrations. Take Siebel's UAN for example, as described by executive vice president David Schmaier in a Computerworld interview: "Today we have 140 integration applications. These are our UAN integration applications ... We found out that these business processes were not only not understood, but nobody wrote them down anywhere. So we decided to write them down. It's free with the software." Until, I guess, you want to change them anyhow.

What if a business wants to innovate its own business processes — perhaps to achieve competitive advantage, for example. If you're a big customer of a responsive software vendor, they'll develop that new process for you and deliver it within around nine months. Then they'll deliver it to all your competitors in their next upgrade cycle. That's their business model: big companies establish best practices, and software vendors automate them for everyone in the industry. They're quite overt about it. In fact, it's supposed to be one of the advantages of packaged software. It's how they add value to your business.

There is a different approach emerging, one that puts process owners in charge, and forces software vendors to take a back seat. Professor Richard Welke, head of the computer information systems department at Georgia State University, cites GM as one adherent of this new approach: "General Motors tackled its [non-communicating] silos — which were geographical rather than functional — by appointing process information officers; they have titles like supply chain PIO, product development PIO and customer experience PIO, and each answers to a chief process officer."

There's more to this than creating a few new job titles, of course. The underpinning is a service-oriented architecture that provides loosely-coupled access to data sources and application functions. Above that infrastructure sits a new service assembly layer that allows process owners to mix and match the information and automation they need to react to changing business requirements.

This service assembly layer is more than simply orchestration or choreography. As Adam Bosworth recently observed, "In a site filled with pages (or pages filled with rich UI interactive gestures) the user is in charge, not the controller. There is no directed flow. Occasionally we build directed flows and call them wizards, but in general sites are not written to move from task to task in some ponderous choreography."

Service assembly is an emerging new category that allows business users to build and modify their own applications on the fly, and then operate them according to the demands of their external environment, no longer constrained by the limitations of inflexible prepackaged system development. I'm going to be writing about this some more in the coming days. For now, I'm going to stop at tantalizingly noting the existence of this new phenomenon without properly describing it, because a full description will mean introducing a number of other new concepts while simultaneously slaying several more sacred cows.
posted by Phil Wainewright 10:06 AM (GMT) | comments | link