@Equate

Boundaryless Organization

2017-04-12T09:16:40+02:00

Conduct is een IT platform bedoeld om enerzijds het maken en onderhouden van gegevensstromen tussen afdelingen, niveaus en functies binnen een organisatie sterk te versimpelen en anderzijds het bewerken van gegevens sterk te versimpelen. Conduct doet dit door de afhankelijkheid met IT changes weg te halen. Wijzigingen in gegevensstromen en bewerkingen kunnen worden doorgevoerd buiten de IT organisatie om. Conduct doet dit zonder de veiligheid van gegevens uit het oog te verliezen.

Organizations that choose to move toward the Boundaryless Organization to improve their operational effectiveness are finding Information Technology resistant.

Over het algemeen ondervindt een organisatie dus weerstand vanuit de IT organisatie bij het realiseren van een boundaryless organisation. Met Conduct krijgen afdelingen, functiegroepen en andere teams binnen een organisatie de beschikking over hun eigen data lake. De teams kunnen zelf bepalen welke gegevens met wie gedeeld worden, en wat er met de gegevens gedaan wordt. Het delen en bewerken van de gegevens vereist geen inspanning van IT.

Op deze manier creëert Conduct een boundaryless information flow binnen een organisatie. De methode was ondermeer afgeleid van het Boundaryless Information Flow architectuur raamwerk dat indertijd is geformuleerd door The Open Group, om weerstand te verminderen en barrières te verlagen en zodoende boundaryless organisaties te ondersteunen.

Nadat de barrières zijn verwijderd krijgt een organisatie de volledige beschikking over de noodzakelijke gegevens en kan het naar eigen inzicht zichzelf verbeteren, om sneller marktwerkingen te volgen, en uiteindelijk op de markt vooruit te lopen.

Getting the most out of your big data

2015-07-12T14:35:51+02:00

Gartner

Gartner beschrijft in haar artikel “Organizing for Big Data Through Better Process and Governance“ hoe big data moet worden georganiseerd. Met big data kunnen voordelen worden behaald op het gebied van operationeel beheer, klantbeheer, risk management en bedrijfmodelinnovatie. Toch komt big data nog nauwelijks van de grond in vergelijking met de aandacht dat het krijgt. Het blijft vooral bij prototypes maar de weg naar operationele systemen is vaak nog ver weg.

Gartner geeft in hetzelfde artikel aan dat big data moet worden beschouwd als een proces. Dit proces bestaat uit 4 stappen. De eerste 2 houden zich bezig met exploratie, de laatste 2 met exploitatie.

Bij stap 1 worden ideeën verzameld, inductief of deductief. Deze ideeën worden in stap 2 getoetst door ze toe te passen in experimenten. Overleeft een idee stap 2, dan wordt in stap 3 een business case gemaakt waarbij waarde tegen kosten worden afgezet. Uiteindelijk moeten in stap 4 de ideeën worden geïmplementeerd. En dat is waar het veelal stokt. Gartner geeft aan dat de afstand tussen de big data teams en IT te groot is omdat ideeën vertaald moeten worden naar een vorm waarmee IT het kan implementeren. Toepassing van DevOps teams zou volgens Gartner een oplossing zijn.

Conduct

AvenQure biedt een oplossing die stap 4 overbodig maakt, en daarmee tevens stap 3. Die oplossing levert ze in de vorm van het product Conduct. Conduct is een process automation platform. Conduct biedt een platform waarop naar hartenlust geëxperimenteerd kan worden met big data doordat het enerzijds non-intrusive van aard is, en operationele processen dus niet geraakt worden, en anderzijds doordat het de automatisering van processen impliciet uitvoert; Conduct draagt zorg voor kwaliteitsaspecten zoals security, performance, availability én dus maintainability. Dit maakt het organiseren van big data een zeer flexibel proces. En in hetzelfde artikel beaamt Gartner dat juist flexibiliteit is vereist bij het organiseren van big data.

Conduct biedt een aantal mechanismes essentieel voor het werken met big data.

Binnen Conduct wordt gewerkt met contexten. Een context is een domein waarbinnen gelijksoortige gegevens worden verwerkt. Met een druk op de knop kan een kopie van een context worden aangemaakt waarbinnen naar hartenlust kan worden geëxperimenteerd.
Conduct werkt met cellen. Iedere cel bevat een stukje logica. Laat 2 cellen naast elkaar werken, 1 op basis van BAU logica, en de ander aangepast naar de inzichten van big data. Maak een 3e cel om de verschillen te evalueren.
Conduct werkt met 3rd party big data analyse producten.
Binnen Conduct kunnen standaard alle gegevens met een druk op de knop RESTful worden gemaakt en is zo integratie met 3rd party producten een eitje. Net zo makkelijk kunnen gegevens ontsloten worden met bestandsuitwisseling of database replicatie.

Conduct levert dus een korte feedback loop. Ideeën kunnen direct worden uitgeprobeerd en maakt het daardoor mogelijk dat het big data team in de business unit kan worden opgenomen, zonder afhankelijkheid met IT.

Complaisance, Care Duty and Ownership of Artefacts

2015-02-22T10:11:16+01:00

Having read several papers on artefact-centric business process modelling we have found two approaches [1]: (1) artefacts as finite state machines and (2) focussing on the life cycle of artefacts. Both approaches require business analysts to validate the artefact model. We strive however, to a situation in which not the business analyst, but the business specialist is in control. The business analyst plays no longer a role or at most plays an advisory role.
The business specialist must make his/her artefacts complaisant to other artefacts. Complaisance naturally seeks a balance between leanness and richness. Leanness is required to make data quickly available and richness to make as much data available at once. During design time artefact modellers will look for the primary source of data to quickly transition to a new state but will also look to get as much data as possible in one go to limit the number of states and to limit the number of events it subscribes to. Remember that artefacts subscribe to events which are interesting to them. These events carry the information of the artefact that triggered the event.
Primary sources are artefacts that obtain the data from the end-user. There should always be one primary source. In case a (primary) source is not visible to an artefact, the source may not exist, or the authorisation of the source is limited. In such case, the authorisation may be altered to grant read access or one may create an intermediary artefact whose sole purpose is to make the data available to other artefacts.
One may decide to use intermediary artefacts as an interface to other domains. for example, the financial controllers in a company will by default block access to financial artefacts. Only data that has been approved for disclosure may be shared with other artefacts. To prevent that the ACL of all primary sources are altered to disclose the data, a special intermediary artefact is created which holds only data that may be disclosed.

Therefore, in our case, a business specialist being in control means that he/she must be able to make the artefact complaisant to other artefacts. This requires that the artefact is taken care of, which in a changing world requires constant care. The business specialist has a care duty and therefore must own the artefact.

This brings us to the tuple: complaisance, care duty and ownership. An example implementation of an artefact system was developed by AvenQure [2].

1. Gerede, C.E.: Modeling, Analysis, and Composition of Business Processes. PhD thesis, Dept. of Computer Science, University of California at Santa Barbara (2007)

2. "Conduct by AvenQure | Non-intrusive Workforce Empowerment.", http://avenqure.com/conduct/, AvenQure, May 2016. Web. 18 May 2016.

Artifact as the Plug for BPM

2015-01-24T22:49:31+01:00

Silly me. In my previous post The Hole in BPM, I concluded that BPM lacked the concept of an type of business object or document. Little did I know that in 2007 IBM already introduced the concept of artifact-centric business process modelling in [1]. Artifacts are "business-relevant objects that are created, evolved, and (typically) archived as they pass through a business". Artifacts have an information model describing its data i.e. properties, and a lifecycle model describing the states an artifact can go through. The lifecycle is specified following an event-condition-action and/or condition-action style [3]. Indeed it seems that artifacts are the plug for the hole in BPM.

The idea of artifacts passing through a business [1] can be interpreted as a workflow mechanism where depending on the state, people have or have not access to the artifact. And state being the equivalent of the condition mentioned above. Depending on its state, an artifact is interested only in a limited set of events. After each action the state is re-evaluated as are the set of events. The set is determined by the set of actions that are appropriate for the state. In other words, when an action has been executed, the state is reconsidered. This also implies that the state does not change halfway through an action and that the action is considered atomic.

An artifact must contain a business rule to determine its state, the state business rule. This rule is evaluated after each action. The rule inspects the properties of the artifact to determine the state. Each action must specify during which states it may be executed thus being a pre-condition of the action. In addition to state, an action has another type of pre-condition, namely its access control list. For an action its ACL is simply put those who may execute it. The ACL's of all actions together form the artifact ACL.

In [2] the actions, or services as they are called, are specified in a declarative way using input parameters, output parameters, pre-conditions and post-conditions. Following the reasoning above an action has the following pre-conditions:

state of the artifact
set of events
its ACL

For read-only actions, the post-condition equals the pre-condition. Otherwise, we expect the post-condition must be defined with the action.

Although [1] does not mention ACL's and does it mention transactionallity, it does appear that artifacts can indeed plug the hole in BPM. More on ACL, transactionallity and inter-artifact relations in a next post.

K. Bhattacharya, N. S. Caswell, S. Kumaran, A. Nigam, and F. Y. Wu. Artifact-centered operational modeling: Lessons from customer engagements. IBM Systems Journal, 46(4):703–721, 2007.
Deutsch, A., et al., Automatic verification of data-centric business processes, in Proceedings of the 12th International Conference on Database Theory. 2009, ACM: St. Petersburg, Russia.
http://en.wikipedia.org/wiki/Event_condition_action