The Wrong Orientation?

In an odd confluence, multiple streams of activity have come together to convince me that current IS thinking may be suffering from a bad dose of "the wrong orientation".

Firstly, at National Grid, I've been looking into how to better manage asset information. I'm absolutely convinced that the major challenge is to bring data from disparate sources together into a coherent whole (or at least the illusion of such), but it seems very difficult for some people to think this way, and many conversations descend into the rights and wrongs of individual applications and their provisioning.

Next, I spent two days last week on Alec Sharp's excellent course in Business Process Modelling. (I can heartily recommend this to anyone who wants to really understand how processes flow in an organisation.) One of his key tenets, which made absolute sense to me, is that any given business process focuses on the flow of one core "token", or business entity. For example, in newspaper publishing one process might handle an advert from sale to preparation to billing, but a very distinct process would handle the combination of multiple adverts and editorial items into a published issue.

This resonates very well with my view of application integration. I've been working on my slides for the IRM Enterprise Architecture Conference in June, and a recurring theme is how National Grid have benefited from a strong canonical model carrying enterprise data through successive transformations.

As another strand, those of you who have read my reviews of the iPad will know how depressing I find the iOS reversion to an architecture in which each "app" has its own little squirrel store of data, where something as simple as downloading a document for review from the PC and tidying up afterwards means up to ten separate file management operations.

Yesterday, I spent a day at Oracle, on one of their "developer days", learning about the integration capabilities of the latest SOA Suite 11g. Now to place credit where it's due, Oracle's achievement with their Fusion toolset, grown from extensive and rapid consolidation of the Java-based vendor space, is pretty impressive. By my count, their core integration tools stem from at least four heritage lines, and other components are similar. The latest version of JDeveloper knits together business process automation tools, human workflows and web service-based application integration, seamlessly, under a common user interface, with a powerful test and tracking framework. It's a capability set which none of the component suppliers could have aspired to.

But, and, it's a big BUT, it all feels terribly cumbersome. Each step in the process has to be built by first dragging an appropriate icon into the graphical model, and then setting multiple properties, each of which frequently requires navigating a complex hierarchy of forms and menus and back up. The graphical connections between objects have to be fully specified by choosing which data items map to one another, and how, at every step. The same business rule or, much worse, conflicting versions, can be encoded in multiple places. I suspect even an experienced developer will get frustrated by omitting a key step, and spending ages trying to track it down.

Now admittedly some of this might be Oracle's traditional inability to get the usability of their development tools right. You could imagine a Microsoft implementation of the same idea being much slicker, with a "flatter" interface, more intelligent defaults, and things like code generation steps hidden better behind the scenes. To a certain extent that might be true: I don't remember BizTalk being as bad, but I do remember some similar frustrations, and what that tells me is that the underlying model is wrong

I think the problem is that these tools lose sight of the underlying flow of key objects through the business process, and I think that that stems from an error of orientation.

Early software had a resolutely "action-object orientation". You chose the action you were going to take, from maybe a top level menu or by typing the name of a program to run, and then specified the data on which the action should be performed. In the late 80s and early 90s a lot of people realised that this was the "wrong way round", and it would be much more natural to allow the user to select the data first, and then specify one or more actions on that data. If you think of a word processor, or drawing program, or almost any game, you will immediately think in terms of this "object-action orientation". Every time you right-click on an object in Windows to get a context-specific menu, you're also following the model.

However, a lot of people realised that the model didn't have to be restricted to productivity software and games, and could apply equally to business software. The apex was probably the work of people like Richard Pawson on concepts like "naked objects", which generated whole business systems based on graphical representations of the data on which users could directly invoke actions to progress business processes.

Then a few things got in the way. The biggest was probably the crudity of early internet technology, which could only really present text-based interfaces, and which didn't have an effective way of conveying objects and actions upon them. Even when we got SOAP (which, remember, originally stood for "Simple Object Access Protocol") this was used to express "services", and we were back to choosing an action, then specifying the data.

This model persists in the world I saw yesterday at the Oracle workshop. Even the cleverest composite applications are just "bundles of services in order", and it becomes very difficult to follow the flow of the underlying data.

Object-action is not only better for user interfaces, but also as a programming model. It would surely be better to have an object representing the core business entity visibly flow through the business process being progressively transformed and enriched, following the best analysis practice. Changes to the object should be made through services expressed as methods on the object. Business rules should be centralised within, or at least through, the object, avoiding any risk of fragmentation or conflict. (The rules could still be held and managed in a business rule service, but would associated with the object rather than a process step.) Using web service standards would free us up from platform- or location-specific issues, but the core object-based model should be preserved. Maybe I'm missing something fundamental here, but putting the object at the heart of the process must be better. Even in Oracle's composite application examples, having a central object would immediately remove much of the complexity in defining exactly what passes from process step to process step, as all would automatically reference the same core data and state model.

Object-based systems are easier to both build and use. Isn't it time we remembered this, and challenged the forces driving us towards weaker models?

Just to say that I agree with your conclusion, and to note that Naked Objects is alive and well, both on the .NET platform and on Java.

The .NET version, Naked Objects MVC is under Richard Pawson’s stewardship, and now runs under ASP.NET MVC + Entity Framework 4.

Meanwhile, for Java platform what was the original Naked Objects framework has been accepted into the Apache Software Foundation’s incubator, and is called Apache Isis.

Cheers
Dan

Thanks, Dan, I’m very pleased to hear it. I was very pleased to contribute to the original book, and the ideas I gained at the time have guided me strongly in the interim.