Combining High and Low Ceremony

Following on from my last piece on cim (the computation independent model), i thought i’d take a quick look at Aptero Solutions’ technology offering.

I have to admit that I seem to be rather on Aptero’s wavelength and probably have been since the days of Select Business Solutions. Both Aptero and another company whose approach to automated software development and systems engineering I like, Atego, have roots in Select; a company I’ve been following since way before I joined Bloor, although the fire seems to have gone out of Select of late.

When I met Aptero first, what struck me was the breadth of its offering, from low ceremony business process automation through to high ceremony MDA if required—and the possibility of moving between these approaches without major rework.

This could address a concern I’ve had since the early days of CASE—development automation is “owned” by people who write code and expect things to be complete and correct at all times. This is feasible (although, sadly, not always the case) in the abstracted model of the real world represented by the code of a computer program—but the real world just isn’t like that. The real-world works on fuzzy logic, has “chaotic” behaviours (in the mathematical sense) and features self-healing systems (in the General Systems Theory sense) in dynamic equilibrium with their environment. The business works at a “make do and mend” level, with “just enough” completeness and consistency to get the job done without breaking the law—and that isn’t very easy for the technology side of IT; and even more uncomfortable for the people in IT.

However, to my mind (and I started off as an assembler programmer, database systems programmer and DBA), the code side of IT is the easy bit—it’s translating the ambiguity and chaos of real world business systems into the rigidity of code and providing manual procedures for the special cases and risk management where the fun is!

Anyway it seems to me that conventional model-driven approaches tend to be either high ceremony, which isn’t always appropriate or agile enough; or low ceremony, which is fine and agile until complexity increases and regulators etc. get interested. With agile, low ceremony approaches you often seem to fall off a cliff and have to re-engineer everything from scratch when things get successful (I think I remember the CTO at eBay or some such describing just such a scenario).

I think there’s a middle way and that what most people need is “just enough” ceremony—and that what “just enough” is changes as automation becomes more or less critical to the business; or customer expectations change…

I ran these ideas past Phil Webb at Aptero Solutions and his response was that “what you describe is certainly our philosophy, albeit not one which we have yet described in whitepapers and the like”. Nevertheless, Webb points out that it may be rather easier to describe this approach than to implement it, as yet, although the attempt is well worthwhile: “since we have two different tool-sets—potentially low-ceremony executable business mode delivery with Mendix and potentially higher-ceremony business-driven software engineering powered by MID—from two separate vendors, switching between approaches will be less straightforward, but it’s important, we feel, that we understand that both approaches are necessary in differing circumstances and that the offerings we provide are flexible enough to cope to as great an extent as possible. For instance, the Mendix offering allows more complex integration needs, or processing requirements, to be fulfilled through external Java libraries and the like which may be plugged in. One can therefore envisage the use of MDA techniques (provided by the MID toolset) to enable the production of libraries, which are then plugged into the agile Mendix processes”.

Once again, the issue, it seems to me, is that the technology stakeholders in the business process automation business are often too firmly in the driving seat. All the stakeholders, including those in the business, must share responsibility for business system automation—and putting the business too firmly in the driving seat would be a problem too. What I am also sure of, is that although software vendors are an important facilitator for all this, and should be treated as stakeholders, they definitely must notbe in the driving seat! Sometimes, they are; and sometimes IT, which like new toys, encourages them. It amazes me that there are aren’t more end-user communities with real teeth, to balance the undoubted power of the major vendors.