Business' Ultimate IT Platform

[woutdejong]

Originally posted at http://creetion.blogspot.com 

I have often wondered what the Ultimate IT Platform would look like. What raw capabilities would it require to support Business in all its forms and flavors? By Platform I mean a technological entity that provides the building blocks and toolset for expression and support of (potentially all!) business activity. Yes, that covers a lot, so I'm going to try to be a little realistic here and not too Utopian, but some nice dreamy elements will probably seep through. 🙂


History:
Let's analyze the venerable SAP ABAP Platform. It is 1 system (1 entity) upon which all business logic (mainly ERP) is built. The designtime and runtime are co-located (both serverbased!) and shared across many applications (modules), resulting in very high cohesion and consistency. The grey/blue SAPgui screens are infamous throughout the world...
The ABAP source code is open for display to anybody. Via System->Status anyone can see in which screen of which program he is. Every minute step of business logic execution can be followed via the Debugger. This transparency has saved many implementation projects, for example, it helped shorten the bugfixing cycle as ABAP consultants could point out the problem area to SAP in detail. Unfortunately, not many Business people can actually read and understand ABAP. However, ABAP usually manages data in tables (via the excellent Data Dictionary), and tables are very comfortable structures for Business people.
SAP's flagship ERP product harbours a tremendous amount of ABAP business logic, which reuses other logic in that same 1 system resulting in many dependencies among them. This chaos ("entropy") of elegant business logic and sometimes spaghetti-code, caused by programmers at SAP and consultants alike, somehow happens to function; just look at the thousands of SAP ERP customers. The ABAP Platform provides tooling to add and change business logic (with versioning) in this chaotic, complex environment in a relatively easy and fast way. You can immediately reuse all the other logic present in the 1 system. Another example, the where-used and what-use ("doubleclick") functionality helps to determine the impact of changes. Of course, with more business logic in the 1 system it is becoming more attractive to keep adding to the system, until a certain point that organizing the 1 system cannot be managed as it takes too many resources (time, money) to implement changes.
(I can continue for the next 5 pages detailing other great stuff and flaws of the ABAP Platform, but I will save that for another time.)

Present:
Although the ABAP Platform is good, it is hardly the Ultimate. I can think of a thing or two that is missing. Enter Business Process Management (BPM) and its supporting technology: the BPM Suite (BPMS). These types of Platforms are usually employed to create executable business logic in a process language (BPMN) that is much more suitable for Business people than source code. It is fairly common for BPMSs to be accompanied by Business Rules Management (BRM) systems, which use a formal language (SBVR) or sometimes even natural language (NL) to express business logic in Rules including decision tables, conditions and policies. Now, some Business people might even create executable business logic themselves, although that might be a bridge too far for Rules and two bridges for Process (BPMN).
Of course, any true Ultimate BPMS Platform would also show all the great features present in the ABAP Platform, like very high cohesion, debugability/traceability, transparency, fast development, ease of reuse, impact analysability, manageability, and so on. Otherwise it will be very difficult to convince providers of business logic (like SAP) to really start building upon the Platform.
So, the BPMS is a step towards the Ultimate IT Platform, but isn't there yet. More features are required. Let me start with a list (and I know, many features are interrelated to one another).

1. Goal-orientation. Perhaps the single biggest raison-d'être of Business is that it has one or more goals. Explicit linkage must be provided from activity to (sub)goal attainment, for example via Key Performance Indicators (KPIs). Hopefully you can think of concrete goals, instead of vague and abstract goals that are always true. Indeed, the higher-end goals themselves may initially be implicit or hard to capture. Still then it must be possible to start off with lower-end ones, and discover the higher-end ones along the way (resolving any conflicting goals in the process). Actually, come to think of it, perhaps we should rename this BPM into Business Goals Management (BGM)???
2. Process Management. The Platform must support scripted, procedural business logic, preferably in a graphic manner like BPMN. However, not only must it support a-priori design (usually very lengthy Require-Analyze-Design-Implement-Run/Monitor-cycles (RADIR)), but also on-the-fly, ad-hoc changes to individual, running process instances must be made possible ("instantaneous RADIR"). This Extreme-BPMN requires the complete merging of designtime and runtime; the latency between runtime and designtime should approach 0. Also, Tasks should be handled way more flexibly than we see now in BPMSs. For example, most current BPMS offerings support a concept called User Task, which is an activity in a process to be performed by a user, like a manager appraising a leave request. It usually means a user gets a single link in his inbox, opens this link, and is presented with a single screen/form to be completed upon which the process instance continues. This very rigid way of working might be fine for some people or process types, but not many. A manager might have to appraise 10 leave requests at a moment. He doesn't want to open them one by one. He wants to see all leave-request-Tasks projected on his team calendar (and more) to make well-informed decisions (approve or (re)propose or reject, maybe even reconsider an already approved request).
3. Adaptive Case Management (ACM), also called Dynamic Case Management; preferably based on Object-States. Originally this comes from the medical or judicial world, where things are organized in case-files, but it can be applied to lots of other activities. ACM combines naturally with Goal-orientation, as Cases (in an end-State) can be used for goals. To complete these Cases or subcases, certain activities have to be executed, to be determined by a human or computer-based Case handler. The order of the activities is not as strictly defined as with Process technology; it is left more to the judgment of the handler, it feels sort of semi-structured. During the execution various planned and unpredictable things (Events) need to be mastered that might affect one Case or the other. Governing these Cases are Rules, which act like "Swords of Damocles" to allow or disallow behavior (Events, Processes) to move from one State to the next one, for example.
4. Rules Management. Rules are quite necessary in the Platform, and not just as first-class citizens of the Requirements-world (RADIR). On the one hand, they limit the behavior of Events, Process-flow, Cases. They can be used to implement authorizations within the Platform. Another example, they can provide possible values (like dropdown boxes) in user screens (UIs), and check afterwards if the entered value is actually conforming before continuing the activity. On the other hand, Rules can also guide or project useful behavior, like determining the Leave Request Task priority based on how far in the future the leave is requested ("inference"). Rules should be very accessible to the Business, meaning that Rules should be expressed in (a highly formal) natural language.
5. Event management. Many planned and unforeseen things happen at many different times, especially in Business. These Events must be detected, streamed, handled, correlated and dealt with, as they may affect Goals (Case-States) or are actually required for Goal attainment. Patterns might be detected that could lead to the discovery of inference Rules. A simple example of a derived Rule of previously captured Events: if a customer buys laptops, then it is 90% probable that he buys or has bought an equal amount of smartphones in a period of -1 and +3 weeks.
6. User Interface / Collaboration Management. Let me kick in a big, open door here: people are the most important actors in Goal-attainment, so the IT Platform (which calls them "users") must support them in every possible manner. User Interface (UI) technology (web, Rich Internet Applications (RIA), online/offline forms and documents) is constantly changing, which the Platform has to provide for or at least integrate with. Business people should be able to customize and even build screens/forms/dashboards themselves, combined with features like Rules for simple field validations, for example. In addition, the Platform will have to offer many collaboration ("groupware", "Social BPM") options, we have grown accustomed to (Exchange, Google Apps, including video / voice / chat, etc), including support for the Org Charts of all involved in the value chain.
7. Content / Document / Data-object / Term Management. There is a lot of data in any Business, some would say: too much. And then there is the semantic confusion of various Terms with the same meaning, or vice versa. The Platform requires a big bucket to store all this content, be it structured or unstructured, in whatever form (as in Enterprise Content Management (ECM)). Of course, the stuff needs to be managed and organized, trying to mitigate the confusion and redundancy as much as possible. The Data will be in a constant state of flux, mostly supporting all of the features described above.

The list covers a lot of the coal-face features according to my idea of the Ultimate IT Platform. However, there are properties that go beyond these.

1. "Connections" Management. Connections may not be the proper word, but it is supposed to encompass relationships, dependencies and the like among the features (including different versions). For example, Event E sets off Process P, and is restricted by Rule R. This looks like some sort of meta-data management, we see in Enterprise Architecture tooling such as Avolution's ABACUS or Sparx' Enterprise Architect (although these tools usually require manual input, which is unfortunate). You could also compare it to a meta-data-warehouse, where these connections are automatically captured and managed. Basically, this may very well be the feature for being agile. Agility is not something that just comes with new technology per se, but has more to do with managing the connections among the various solution-parts. The fewer connections, the more agile, as it is easier to change. Again, expecting to become agile just by using BPMN or Java or whatever language/technology is unrealistic.
2. Search, Analytics and Mining. Building on top of both features and connections(metadata) the Platform needs to support analysis in its broadest sense. You must be able to traverse all the Events, Cases, Processes, Data, Rules, UIs, Goals in a Google-Search-like way (that is, if you are authorized for it). The Platform might be even a little intelligent by detecting trends and patterns automatically, using webspider-like mining capabilities and inference Rules. All this information might be overwhelming, so standing back ("zoom out") a little from all the nitty-gritty details should be supported. Also, problems and suboptimal behavior will become faster apparent, as you are less likely to run into dead-ends, because everything is connected. This will reduce RADIR-cycles, which helps attain goals faster. With enough usage, it can become the Knowledge Repository that many Knowledge Management initiatives have pointed out.
3. Cohesion. Yes, again: all of these features must feel very highly cohesioned. I'm tempted to say "be cohesioned", but in this multi-versioned, distributed, virtualized and cloud-based computing world it is very hard to build the 1 system that "binds" them. I keep stressing cohesion so much, as without it you get a brittle and very inflexible foundation, made out of disparate runtime and designtime systems. The RADIR-cycles will then become unnecessarily lengthy due to technical prerequisites which need to be fulfilled first before it can be used productively. When components are cohesioned, the distance between them is relatively short. The threshold to reuse will be quite low, as it is easier to determine impact.  As the Platform will evolve and new features are becoming necessary (and old ones legacy), high cohesion makes it easier to absorp those changes. It is comparable to programmers refactoring their source code to make it more robust, elegant, extendable, etc without changing the behavior (much).

Yeah, the Ultimate Platform seems to be the "ultimate kitchen sink", capable of nearly everything. Of course, that was the whole idea behind this writing. 🙂
Is the Platform out there?
Could be, but I haven't noticed it. Discohesive, fragmented parts of it are available. It would be nice if the Platform was to be built on top of itself, like Java was used to develop lowlevel APIs for usage by higher level Java programs, or ABAP to build huge parts of the ABAP Workbench. At least, housekeeping and administration of the Platform should use the features it provides itself.
When is the Platform going to be a success?
I guess if it passes the "MS Office"-test, then it definitely is. Basically the Platform must be so pervasive that Business all forgets about Outlook & Excel, and immediately turns to the Platform (of course it has builtin spreadsheet and collaboration capabilities). This indicates it really is the Ultimate, I would say. 🙂