In recent years the construction and installation sector have been working closely together to define uniform standards for the building industry. The industry associations are well aware of the benefits and savings that can be achieved by the electronic exchange and provision of data.

In the past, the communication with customers and suppliers could easily be done manually – by email, post or via fax. Today we see in other sectors that electronic business is increasingly being adopted. Companies in the building industry more often receive requests from customers and suppliers to exchange data electronically and to provide product data in a standard format.

Industry associations have delivered an important contribution to this change of mentality by developing standards and providing facilities for sharing product data.

In 2012 ETIM and S@les in de Bouw under guidance of GS1 defined a common XML standard for the construction and installation sector. On June 1, 2015 the ETIM Building classification was officially published as an extension to the international ETIM standard for classification of product information in the installation sector. A development that sets the construction and installation sector closer together and offers benefits to all companies in the building industry.

It is important that continuous efforts are made to reduce the thresholds for participation. This requires commitment of all those involved in the building industry, from manufacturers to construction companies and calls for a director who encourages and monitors the use of standards.

What can we learn from electronic invoicing?

When I make a trip to the world of electronic invoicing, we see there that despite all standardization efforts the adoption in the past 10 years has been limited. That has, in my view, four major causes.

First of all, the perpetual debate over the preferred global standard, UBL or UN/CEFACT, and the emergence of various variants on these standards. That must/may not happen in the construction and installation sector.

In addition, the large growth of providers of B2B solutions with their own standards and networks. These providers solved the spaghetti-problem of EDI but managed to create a new problem that slowed down (still does) the adoption of electronic invoicing. The explosive growth of B2B providers brought the interoperability problem between providers – the lack of interoperability between the systems of information providers – one spaghetti problem went away and another one came in its place. Luckily (one would say) the providers invented the interoperability agreements (roaming). But these rather have a commercial purpose than that they really live up to what is promised due to the absence of uniform standards between providers and the improper interest in the own network.

Third, there is the one-sided attention for the electronic invoice leaving only the receiver of an invoice to fully enjoy the benefits of automated processing. In other words the lack of the supply chain thinking.

Last but not least – the starting point: what do we mean by electronic in other words is digital the same as electronic. A discussion that takes place quite often. Let me formulate my position as follows: I'm happy with the standard electronic messages of the construction and installation sector and I believe that integration of systems in the future can not be done without these standards.

Do companies in the building industry suffer from similar problems?

Indeed there are companies that experience such problems and we must prevent this.

Installation companies are urged by several parties to retrieve and exchange data electronically. These companies have to do with suppliers, customers and centralized product data pools that each have their own way of data exchange.

For these companies it becomes impractical over time to facilitate the technical and functional requirements of all these parties.

Let's look at what an average installation company has to deal with. An installation company in the building industry retrieves materials from wholesalers and from suppliers that deliver their products to the building and installation sector or to both. In turn they receive purchase orders from customers and must supply data to participate in major construction projects.

First of all, the company gets to do with the product-data pool from the installation sector (2BA or through artikelbeheer.nl) and from the construction sector (EZ-base). Further, the company has a number of vendors, each with its own EDI/XML Message Broker or B2B provider which should be connected.

How can we make life a lot easier for this company and others!

(How can we help companies to start exchanging electronic data and/or retrieve product data)

There are two routes that could be followed here:

Route 1: the construction and installation sector picks up the role of director and provides a platform/infrastructure – an information highway for companies to exchange messages and information with each other.

Compare it with the PEPPOL project (= Pan-European Public Procurement Online) of the European Commission. This project is aimed at simplifying Procurement between Government and businesses both national and cross-border.

Only (in my opinion) individual companies should be able to connect their information systems easier and faster. With PEPPOL this now is mainly done through service providers that act as Access Point providers. An authorized Access Point has to comply with all kinds of technical and functional requirements for which certification must be gained.

A Business Process Management system consisting of a process, a data, integration and service layer can greatly simplify the process of connecting and exchanging data. When participants through search-and invite can link with one another it would significantly reduce the threshold for participation. The challenge is then with the providers of information systems (ERP, PLM, and others) to open up their systems.

If we look at BPM systems (Pegasystems, E2E Bridge, ...) we see that they already have links to many existing information systems. When information systems offer their functionality as services then connecting on the information highway is pretty simple to accomplish.

Route 2: the company itself implements a BPM system and connects with the different providers of their customers and vendors. Here it is important that the BPM system can be implemented without high cost, is flexible and can quickly respond to new and changed requirements of customers or suppliers. But also that the existing B2B/EDI Providers offer these companies the possibility of free of charge data exchange with partners on their network.

By the way: I shouted years ago (2009) that Google, Yahoo or Microsoft should set up such a highway. In the meantime there are plenty of other players like Facebook and Linkedin who could do this.

Side Note:

I have spent the past weeks writing articles about the realization of process-driven and model-based information systems which are all covering the way the intermediate platform can be established and what systems can be used for this purpose:

Kunnen we proces-gedreven informatiesystemen ontwikkelen met BPMN2? [soon to be translated]

BPM systemen helpen bedrijven van hun maatwerk af [soon to be translated]

Process-driven value networks change electronic business

It would be nice to organize a discussion with all parties concerned or with companies who want to start with exchange of data and see what we can achieve. Visit: Electronic Business Knowledge Village on Linkedin.

Tags: Process Modeling, BPMN, e-Business, e-Invoicing, e-Procurement, enterprise service bus, datapool

De bouw en installatiesector werken de laatste jaren intensief samen om te komen tot uniforme standaarden voor de bouwkolom. De brancheorganisaties zijn zich zeer goed bewust van de voordelen en besparingen die behaald kunnen worden door het elektronisch uitwisselen en beschikbaar stellen van gegevens.

In het verleden konden bedrijven de communicatie met klanten en leveranciers gemakkelijk handmatig verzorgen – via email, per post of via de fax. De laatste jaren zien we in andere branches dat elektronisch zakendoen meer en meer wordt geadopteerd. Ook bedrijven in de bouwkolom vragen steeds vaker aan hun klanten en leveranciers om gegevens elektronisch uit te wisselen en productgegevens in een standaard formaat beschikbaar te stellen.

Brancheorganisaties hebben een belangrijke bijdrage geleverd aan deze mentaliteitsverandering door het ontwikkelen van standaarden en het beschikbaar stellen van voorzieningen voor het delen van artikelgegevens.

In de bouw- en installatiesector is door ETIM en S@les in de Bouw onder begeleiding van GS1 in 2012 een gemeenschappelijke XML standaard gedefinieerd. Op 1 juni 2015 is de ETIM Bouw classificatie officieel gepubliceerd als een uitbreiding op de internationale ETIM standaard voor de classificatie van productgegevens in de installatiesector. Een ontwikkeling die de bouw- en installatiesector dichter bij elkaar brengt en ten goede komt aan alle bedrijven in de bouwkolom.

Het is wel belangrijk dat blijvend inspanningen worden geleverd om de drempels voor deelname te verlagen voor bedrijven. Dit vraagt inzet van alle betrokkenen in de bouwkolom, van producenten tot bouwbedrijven en vraagt om een regisseur die het gebruik van standaarden stimuleert en bewaakt.

Wat kunnen we leren van elektronisch factureren?

Wanneer ik een uitstapje maakt naar de wereld van elektronisch factureren dan zien we daar dat ondanks alle standaardisatie-inspanningen de adoptie in de afgelopen 10 jaar beperkt is geweest. Dat heeft in mijn optiek een viertal belangrijke oorzaken.

Allereerst de eeuwigdurende discussie over welke wereldwijde standaard, UBL of UN/CEFACT, de voorkeur kreeg/krijgt en het ontstaan van verschillende varianten op deze standaarden. Dat kan / mag dus / niet gebeuren in de bouw- en installatiesector.

Daarnaast de grote opkomst van aanbieders van B2B oplossingen met eigen standaarden en netwerken. Deze aanbieders losten het spaghetti-probleem van EDI op maar veroorzaakten een nieuw probleem die vertragend heeft gewerkt (en nog steeds) voor de adoptie van elektronisch factureren. Door de explosieve groei van aanbieders ontstond het interoperabiliteitsprobleem tussen aanbieders – het ontbreken van informatie interoperabiliteit tussen de systemen van providers – het ene spaghetti-probleem verdween en een ander kwam daarvoor in de plaats. Gelukkig zou je zeggen hebben de aanbieders daarvoor de interoperability agreements (roaming) bedacht. Maar deze hebben eerder een commercieel doel dan dat ze werkelijk worden waar gemaakt bij gebrek aan uniforme standaarden tussen aanbieders en het belang van het eigen netwerk.

Als derde is er de eenzijdige aandacht voor de elektronische factuur waardoor alleen de ontvanger van een factuur kan genieten van volledig geautomatiseerde verwerking. Anders gezegd het ontbreken van de ketengedachte.

Als laatste maar niet onbelangrijk – het uitgangspunt: wat verstaan we onder elektronisch ofwel is digitaal hetzelfde als elektronisch. Een discussie die heel vaak en nog steeds wordt gevoerd. Laat me mijn standpunt als volgt formuleren: ik ben blij met de elektronische berichtenstandaard van de bouw- en installatiesector en ik geloof dat integratie van systemen in de toekomst niet zonder deze standaarden kan.

Hebben bedrijven in de bouwkolom last van soortgelijke problemen?

Inderdaad er zijn bedrijven en daar moeten we over waken die nu al dergelijke problemen ervaren.

Installatiebedrijven worden door allerlei partijen in de keten gevraagd om elektronisch gegevens op te halen en uit te wisselen. Deze bedrijven hebben te maken met leveranciers, klanten en centrale product-datapools die allen hun eigen manier van gegevensuitwisseling hanteren.

Voor deze bedrijven wordt het na verloop van tijd ondoenlijk om aan al de technische en functionele eisen van deze partijen te voldoen.

Laten we eens kijken naar waar een gemiddeld installatiebedrijf mee te maken krijgt. Een installatiebedrijf in de bouwkolom betrekt materialen bij groothandels en leveranciers die leveren aan de bouw- of aan de installatiesector of aan beiden. Op hun beurt ontvangen ze orders van klanten en moeten ze gegevens aanleveren voor deelname aan grote bouwprojecten.

Allereerst krijgt het bedrijf te maken met de product-datapool van de installatiesector (2BA of via artikelbeheer.nl) en van de bouwsector (EZ-base). Verder heeft het bedrijf een aantal leveranciers met elk een eigen EDI/XML Message Broker of B2B provider waarop aangesloten dient te worden.

Hoe kunnen we het leven een stuk eenvoudiger maken voor dit bedrijf en anderen!

(Hoe kunnen we bedrijven helpen om elektronisch gegevens te gaan uitwisselen en/of productgegevens op te halen)

Er zijn twee routes die hier gevolgd zouden kunnen worden:

Route 1: de bouw- en installatiesector pakt de rol van regisseur en zorgt voor een platform / infrastructuur – een informatie-snelweg waarover bedrijven berichten en gegevens met elkaar kunnen uitwisselen en delen.

Vergelijk het met het PEPPOL-project (=Pan-European Public Procurement Online) van de Europese Commissie. Dit project is gericht op het vereenvoudigen van Procurement tusssen Overheid en bedrijven zowel nationaal als grensoverschrijdend.

Alleen (in mijn optiek) zouden individuele bedrijven eenvoudiger in staat moeten zijn om hun informatiesystemen aan te sluiten. Bij PEPPOL gebeurt dit nu voornamelijk via service providers die als Access Point providers fungeren. Een geautoriseerd Access Point moet aan allerlei complexe technische en functionele vereisten voldoen en daarvoor gecertificeerd worden.

Een Business Process Management Systeem bestaande uit een proces-, een gegevens-, integratie- en servicelaag kan het proces van aansluiten en gegevensuitwisseling sterk vereenvoudigen. Wanneer deelnemers via search- en invite verbindingen met elkaar in stand kunnen brengen zou dat de drempel voor participatie sterk verlagen. De uitdaging ligt dan bij de aanbieders van informatiesystemen (ERP, PLM, e.a.) om hun systemen open te stellen.

Als we kijken naar BPM systemen (Pegasystems, E2E Bridge, …) dan zien we dat deze al beschikken over koppelingen voor veel bestaande informatiesystemen. Wanneer informatiesystemen hun functionaliteiten als services beschikbaar kunnen stellen is het aansluiten op de informatie-snelweg vrij eenvoudig te realiseren.

Route 2: het bedrijf implementeert zelf een BPM systeem en sluit de verschillende providers van hun klanten en leveranciers aan op het systeem. Hier is het van belang dat het BPM systeem zonder hoge kosten ingevoerd kan worden, flexibel is en snel kan inspelen op nieuwe en gewijzigde eisen van klanten of leveranciers. Maar ook dat de bestaande B2B / EDI Providers deze bedrijven de mogelijkheid bieden om kosteloos gegevens uit te wisselen met de partners die op hun netwerk zijn aangesloten.

By the way: ik heb het jaren geleden (2009) al geroepen dat Google, Yahoo of Microsoft een dergelijke snelweg zou moeten opzetten. Ondertussen zijn er genoeg andere spelers zoals Facebook en Linkedin die dit zouden kunnen doen.

Ik heb de afgelopen weken een aantal artikelen geschreven over de realisatie van proces-gedreven en modelgebaseerde informatiesystemen die allen betrekking hebben op de wijze waarop het intermediair platform vorm gegeven kan worden en welke systemen daarvoor gebruikt kunnen worden:

Kunnen we proces-gedreven informatiesystemen ontwikkelen met BPMN2?

BPM systemen helpen bedrijven van hun maatwerk af

Procesgedreven waardenetwerken veranderen elektronisch zakendoen

Het zou mooi zijn om hier met alle betrokkenen of met bedrijven die willen starten met het uitwisselen een discussie over te voeren en te kijken wat we kunnen realiseren. Bezoek het platform eZakendoen op Linkedin.

Tags: Process Modeling, BPMN, e-Business, e-Invoicing, e-Procurement, enterprise service bus, datapool

The online Cloud-based sales, purchase and supply chain solutions are increasingly in vogue. These environments often are a solution for a particular domain area within companies such as sales (CRM, Marketing), purchase (contract management, catalog management,) or distribution (transport management).

With the rise of these Cloud-based solutions there is a growing need for flexible integration solutions. Not only is integration with the backend systems of companies, customers and suppliers crucial for an optimal connection with business processes. But another form of integration arises – a Cloud-2-Business-2-Cloud integration.

When companies support their CRM process with a Cloud-based solution data from this solution (customer, product and order information) will be funneled to the corporate sales and production system.

For products that are manufactured by a company there will be a need for components that have to be purchased through the Cloud-based purchase environment.

When it comes to products that a company buys from third parties the sales orders from the online CRM solution should be channelled to the online purchase environment.

The complexity of all connections that companies have to handle increases with the emergence of more and more service-oriented solutions – in a private or public cloud or on-premise.

The foundation to keep all of this up and running in the coming years are process-driven and model-based integration solutions with a small server and memory footprint. Solutions which do not require a fast processor and much internal memory. This calls for solutions that do not need a Web server (Apache Tomcat, JBoss, etc) but run as a virtual machine on operating systems without interruption.

A little spider in the network of applications a company uses which ensures that everything is and remains constantly connected. When a connection goes down still holds the data (no loss of information), continues to support the work of other applications, and waits for the line to become operational again to transmit the preserved data.

Integration Process Modeler = the modeling tool used to model business processes - supply chain processes from a high level (descriptive) to a low level (executable). With the modeling tool business processes are modeled using BPMN2 and DMN, data models and integrations with UML and screens with user interface diagrams. The services provided by the Servants are associated with the process elements during modeling.

Process Engine = a small server – memory footprint engine that runs the models defined using the modeling tool and makes the operational results of the process visible through a web-based monitor. This gives direct insight in the performance of each process step, the input and output parameters of each step and the bottlenecks – lead times of processes.

Servants = are building blocks for initializing the features available in the Library and make them available as services. During modeling the functions of different providers can be selected from the Libary. The initialization consists of activating the function of a provider and ensuring that the input and output parameters are delivered or processed from whithin the process flow.

Libray = the library of functions of different solution providers. A function is not a complete ERP system but just the functionality to create a sales order and the data model that belongs to a sales order. It is in principle possible for the creation of an order to use the function of provider X and for the delivery of the order the function of provider Y.

The number of process-driven and model-based integration solutions with a small server and memory footprint is limited. On request I can tell you more about it.

Side note: Banks in recent years have noticed that the guarantee of continuous availability with solutions that depend on Web servers or virtual machines is not easy. The performance of Web servers have to be monitored and updated continuously. These solutions impose heavy demands on the hardware, networks and software. A small footprint integration solution reduces this dependency.

Transport companies and also retailers need to interface with technical systems such as on-board computers and POS systems. The presented integration solutions not only handle the integration of business applications but can in principle provide integrations between all kinds of systems.

Tags: Process Modeling, BPMN, e-Business, e-Invoicing, e-Procurement, enterprise service bus

De online Cloud-gebaseerde verkoop-, inkoop- en ketenoplossingen raken steeds meer in zwang. Deze omgevingen fungeren vaak als oplossing om een bepaald domeingebied binnen bedrijven te ondersteunen zoals verkoop (CRM, Marketing), inkoop (contract management, catalog management, ) of distributie (transport management).

Met de opkomst van deze oplossingen is meer en meer behoefte ontstaan naar flexibele integratieoplossingen. Niet alleen is integratie met de backend systemen van bedrijven, klanten en leveranciers noodzakelijk voor een optimale aansluiting met de bedrijfsprocessen. Maar er ontstaat eveneens een ander vorm van integratie – de Cloud-2-Business-2-Cloud integratie.

Wanneer bedrijven hun CRM proces ondersteunen met een Cloud-gebaseerde oplossing zullen gegevens vanuit deze oplossing (klant-, product- en ordergegevens) naar het bedrijfseigen verkoop- en productiesysteem gesluisd worden.

Als het gaat om artikelen die door een bedrijf worden geproduceerd zullen vanuit productie behoeften ontstaan naar onderdelen die op hun beurt weer worden ingekocht via een Cloud-gebaseerd inkoopomgeving.

Als het gaat om artikelen die een bedrijf inkoopt bij derden zullen de orders vanuit de online CRM-oplossing doorgesluisd moeten worden naar de online inkoopomgeving.

De complexiteit van al de verbindingen waarmee bedrijven te maken krijgen neemt met de opkomst van meer en meer service-georiënteerde oplossingen – in een private of public cloud of on-premise alsmaar toe.

De basis om dit alles in de komende jaren draaiende te houden zijn proces-gedreven en modelgebaseerde integratieoplossingen met een small server en memory footprint . Oplossingen die geen snelle processor en veel intern geheugen nodig hebben. Dit vraagt om oplossingen die geen webserver (Apache Tomcat, JBoss, e.a.) nodig hebben maar als een virtuele machine draaien op operating systemen en continue zonder onderbrekingen operationeel zijn.

Een spinnetje in het netwerk van alle applicaties waar een bedrijf gebruik van maakt en ervoor zorgt dat alles met elkaar verbonden is en blijft. En als de verbinding met een applicatie verbreekt, de gegevens vasthoudt (geen verlies aan informatie), de werkzaamheden van de andere applicaties blijft ondersteunen, en wacht tot het lijntje weer operationeel is om de opgespaarde gegevens door te geven.

Integration Process Modeler = het modelleergereedschap waarmee bedrijfsprocessen - ketenprocessen gemodelleerd worden van een hoog niveau (beschrijvend) tot een laag niveau (uitvoerend - executable). Met het modelleergereedschap worden bedrijfsprocessen met BPMN2 en DMN gemodelleerd, gegevensmodellen en integraties met UML en schermen met gebruikersinterface diagrammen. De services geleverd door de Servants worden gekoppeld aan de proceselementen tijdens het modelleren.

Process Engine = een small server – memory footprint engine die de modellen gedefinieerd met het modelleergereedschap uitvoert. En de operationele resultaten van de procesvoortgang zichtbaar maakt via een web-gebaseerde monitor. Hiermee wordt direct inzicht verkregen in de performance van elke processtap, de input- en output parameters van elke stap en de bottlenecks – doorlooptijden van processen.

Servants = zijn bouwstenen waarmee de functies die beschikbaar zijn in de Library ingericht / gemodelleerd kunnen worden en als services beschikbaar gesteld worden. Tijdens het modelleren kunnen de functies van verschillende aanbieders uit de Libary geselecteerd en ingericht worden. De inrichting bestaat uit het activeren van de functie van een aanbieder en het zorgen dat vanuit de procesflow de input en output parameters worden aangeleverd of verwerkt.

Libray = de bibliotheek van functies van verschillende aanbieders van oplossingen. Bij een functie denken we niet aan een ERP systeem maar aan de functionaliteit voor het aanmaken van een verkooporder en het gegevensmodel dat bij een verkooporder hoort. Het is in principe mogelijk om voor de aanmaak van een order de functie van aanbieder X in te richten en voor het uitleveren van de order de functie van aanbieder Y.

Het aantal proces-gedreven en modelgebaseerde integratieoplossingen met een small server en memory footprint is beperkt. Op verzoek kan ik hier meer over vertellen.

Kanttekening: Banken hebben in de afgelopen jaren gemerkt dat het garanderen van continue beschikbaarheid met oplossingen die afhankelijk zijn van webservers of virtuele machines niet eenvoudig is. De performance van de webservers moet continue gevolgd en bijgesteld worden. Deze oplossingen stellen zware eisen aan de hardware, netwerken en software. Een small footprint integratieoplossing vermindert deze afhankelijkheid.

Transportondernemingen maar ook Retailbedrijven moeten interfacen met technische systemen zoals boordcomputers en kassasystemen. De geschetste integratieoplossingen gaan niet enkel over de integratie van bedrijfsapplicaties maar kunnen in principe integraties verzorgen tussen allerlei systemen.

Tags: Process Modeling, BPMN, e-Business, e-Invoicing, e-Procurement, enterprise service bus

In 2005 heb ik de implementatie van Elektronisch Bestellen en Factureren begeleid tussen twee bedrijven voor een leverancier van diensten. Het doel was om de verkoop- en inkoopprocessen van beide partijen te integreren gebruikmakende van elektronische gegevensuitwisseling op basis van internationale standaarden.

Het verzoek was uitgegaan van de klant omdat deze door elektronische verwerking van facturen aanzienlijke besparingen kon realiseren. De klant had de implementatie en het beheer volledig uitbesteed aan een intermediair, een aanbieder van Electronic Ordering en Invoice Presentment via het Web.

In mijn bloart Definitie Elektronisch Factureren schets ik de voornaamste uitvoeringsvormen van Elektronisch Factureren in Nederland. Het model dat door de klant werd geïmplementeerd was het Buyer Direct Model waarbij de web-gebaseerde oplossing en de integratie met de systemen (klant en leveranciers) door de intermediair werden geleverd.

Het was gedurende deze implementatie dat ik mij bewust werd van het interoperabiliteitsvraagstuk. Nog tijdens het project ben ik gaan nadenken over een andere benadering voor het realiseren van Business-to-Business (Elektronisch Zakendoen) tussen meerdere bedrijven. Conceptueel was het voor mij vrij snel duidelijk dat de bedrijfswereld het beste gebaat was bij een combinatie van Business-to-Business Integratie en Web Presentment waarbij gebruik gemaakt wordt van een gemeenschappelijk informatie model en open standaarden.

Waar gaat het naartoe met Business Integratie ?
Met de sterke opkomst van op diensten gerichte architecturen (Service Oriented Archtectures) leek het mij zinvol om een gedegen onderzoek uit te voeren naar de marktontwikkelingen en de visies van analisten. Heel veel presentaties, onderzoeksverslagen, scripties en thesissen zijn de revue gepasseerd. Interessant was de presentatie “Constructing Software for Service Oriented Architecture” van Jean-Jacques Dubray uit 2004. Ondertussen is een hernieuwde versie met de titel “An Introduction to SOA” beschikbaar op de website www.ebpml.org. In de presentatie wordt een overzicht gegeven van de ontwikkeling van Connectiviteit en Business Integratie over de afgelopen 30 jaar. Forrester en Gartner hebben de voorbije jaren deze grafiek verder aangevuld met hun visie op Business Integratie. Service Oriented Architectures spelen daarin eveneens een belangrijke rol maar beide analisten hebben een eigen kijk op de toekomst zoals ik hierna zal toelichten.

Forrester ziet de Business Service Hub (BSH) een belangrijke plaats innemen in het integratie landschap. Forrester gaat uit van een gelaagde integratiestrategie (layered integration strategy) bestaande uit vier integration layers:
- process (BPM)
- presentation (Portals)
- application (ESB, EAI)
- data (ETL)
De Business Service Hub is een intermediair die on-demand integratiediensten levert waaronder Messaging, Routing, Transformation, Partner Management en Business Acitivity Monitoring (BAM). De Business Service Hub richt zich vooral op bedrijfsoverschrijdende transacties.

Gartner pleit voor de Worldwide Grid en Enterprise Nervous Systems (ENS). De Grid is een wereldwijd computernetwerk samengesteld uit Enterprise Nervous Systems, sub-netwerken. Het is een semantische en procesgerichte infrastructuur waarbinnen interacties tussen bedrijven plaatsvinden. Elk bedrijf beschikt over een eigen Enterprise Nervous System.

Welke conceptuele benadering is ontstaan ?
Gaandeweg is een concept ontstaan met de werknaam “Inter Enterprise Buziness Hub (IEBH)”. De “Inter Enterprise Buziness Hub” is een conceptuele benadering voor het bereiken van Business Integratie. Het kan gezien worden als een partner- en standaarden onafhankelijke universele communicatiepoort met business partners, waaronder klanten, leveranciers, overheid, vervoerders en financiële instellingen. Het voornaamste doel is het koppelen van bedrijfsprocessen en informatiestromen over de grenzen van bedrijven heen door middel van een intermediair platform.

Het concept is vooral een antwoord op de traditionele point-to-point manier van elektronische gegevensuitwisseling. Het streven is om eveneens een antwoord te geven op het interoperabiliteitsvraagstuk.

Essentieel in het concept zijn:
- Verscheidenheid aan connectiemogelijkheden
- Gegevensuitwisseling gebaseerd op Internationale Open Standaarden
- Common Informatie Model (CIM)
- Centrale opslag van alle verwerkte gegevens
- Gegevens toegankelijk voor iedereen via het Web

Het uitgangspunt is dat het concept met verschillende softwaregereedschappen en leveranciers gerealiseerd kan worden.

Het concept kan het beste gerealiseerd worden binnen een Consolidator Model maar andere modellen zijn niet uitgesloten. Alleen zal de functionaliteit dan beperkt blijven tot een 1-op-n relatie. Bedrijven kunnen wel hun bestaande architectuur als basis nemen.

Met welke softwaregereedschappen en leveranciers kan het concept gerealiseerd worden ?
Teneinde het concept gerealiseerd te krijgen heb ik de verschillende softwaregereedschappen op de markt geïnventariseerd en onderzocht. Met enkele aanbieders hebben architectuursessies plaatsgevonden om te komen tot een betere definitie van de eisen gesteld aan de functionaliteit. Dat heeft geleid tot een lijst met vereisten t.a.v. functionaliteit die ondersteund moet worden:
- Business Process Management (BPM) & Orchestration
- Business Activity Monitoring (BAM)
- Trading Partner Management & Enablement (onboarding)
- Connectors voor het verzorgen van de connectiviteit tussen bron en bestemming
- Adapters voor het verzorgen van de connectiviteit met applicaties
- Service Oriented Architecture (SOA)

Een aantal leveranciers en softwaregereedschappen waarmee het concept gerealiseerd kan worden zijn:
Commerciële oplossingen:
- Sun Microsystems Java Composite Application Platform Suite (Java CAPS)
- Axway Synchrony Suite
- SAP
- Oracle

Open Source oplossingen
- JBoss & XAware
- OpenESB & XAware
- Apache ServiceMix & Chainbuilder

Hoe ziet het concept eruit ?
In volgende presentatie wordt het concept van de Inter Enterprise Buziness Hub uitgebreider toegelicht.

Welke uitdagingen zijn er nog ?
De grootste uitdaging ligt echter nog steeds in het transformatiedomein. De Inter Enterprise Buziness Hub zal geen implementatievereenvoudiging opleveren wanneer de ontwikkeling van transformatiedefinities volledig handmatig moet blijven gebeuren.

Een belangrijke vraag daarom dient nu en in de toekomst beantwoord te worden: Hoe kunnen standaarden getransformeerd worden gebruikmakende van een intelligente benadering.

Ik heb hier de laatste maanden heel veel onderzoek naar gedaan. Er zijn een aantal benaderingen mogelijk:
- de UN/CEFACT Core Components Technical Specification (CCTS)
- Universal Data Element Framework (UDEF)

Over bovenstaande benaderingen heb ik al geschreven in mijn bloarts Hoe lossen we het interoperabiliteitsvraagstuk op ? en Transformatiedefinities voor de Elektronische Factuur.

Een andere benadering waar vanuit Europees perspectief in tal van projecten aan gewerkt wordt is Semantic Based Transformation. Hierover zal ik binnenkort nog verder berichten.

Hoever staat het met commerciële toepassingen van deze concepten ? SAP, één van de grootste sponsors van de UN/CEFACT CCTS werkt aan een modelleer en transformatiegereedschap met de werknaam SAP CCTS Modeler Warp 10. SAP is vrij ver gevorderd in het beantwoorden van de door mij zojuist opgeworpen vraag.

De architectuur van Warp 10 is gebaseerd op SAP NetWeaver en biedt zowel integratie en uitbreiding van de SAP Global Data Types (GDT’s) als de transformatie naar ieder ander logisch data model ongeacht de gegevensbron. Meer hierover in mijn bloart SAP CCTS Modeler Warp 10, modelleer en transformatiegereedschap. Ik zal binnenkort meer in detail ingaan op SAP Warp 10. Meer informatie kunt u vinden op de Collaboration Workspace van SAP onder Business Data Interoperability.

De nabije toekomst zal uitwijzen hoe het integratielandschap in de komende jaren ingevuld gaat worden. Interoperabiliteit staat op de agenda van internationale gemeenschappen en overheden.

Business Integratie blijft een dynamisch domeingebied en wordt heel sterk beïnvloed door de technologische ontwikkelingen.

Tags: electronic data interchange, Enterprise Service Bus, UDEF, Interoperability-Frameworks, UBL

Last update: 3-12-2011

In september 2001 is op voorstel van een aantal leden van OASIS (Organization for the Advancement of Structured Information Standards) waaronder Sun Microsystems, Commerce One, SAP en Boeing de OASIS Universal Business Language Technical Committee (UBL TC) opgericht. Het voornaamste doel van de UBL TC, voorgezeten door Jon Bosak (Sun Microsystems), was / is het ontwikkelen van een gratis bibliotheek van gestandaardiseerde elektronische op XML gebaseerde bedrijfsdocumenten.

De ontwikkeling van UBL is gestart gedeeltelijk als reactie op de veelheid en verscheidenheid aan XML standaarden / bibliotheken voor elektronische handel maar eveneens om de toegankelijkheid van elektronische handel te vergroten. UBL moet elektronisch zakendoen voor kleine en middelgrote bedrijven mogelijk maken en de basis leggen voor de wereldwijde overgang van traditioneel zakendoen naar elektronische handel.

De OASIS Universal Business Language (UBL) is gebaseerd op de XML Common Business Language xCBL versie 3.0 van Commerce One. Commerce One nam in 1999 het bedrijf Veo Systems over en kwam zo in het bezit van de Common Business Language (CBL) technologie. Deze technologie is door Commerce One verder uitgebreid en omgedoopt tot xCBL om de relatie met XML te identificeren. De XML Common Business Language (xCBL) is een verzameling van XML bouwstenen en een raamwerk voor de ontwikkeling van herbruikbare XML berichten. xCBL richt zich op documenten en transacties ter ondersteuning van de internationale elektronische handel. Commerce One heeft de versie 3.0 van xCBL ingebracht in de OASIS UBL Technical Committee als startpunt voor de ontwikkeling van UBL.

Op70 version) vrijgegeven aan het publiek voor review waarna in november 2004 de eerste officiële versie van UBL, release 1.0, na drie jaar ontwikkeling werd uitgebracht. Twee jaar later, november 2006, werd UBL 2.0 uitgebracht en als formele standaard geaccepteerd door OASIS.

De Universal Business Language maakt gebruik van XML Schema’s voor het beschrijven van gestandaardiseerde bedrijfsdocumenten. Een XML Schema Definitie Document (XSD) beschrijft de structuur van een XML document. UBL 2.0 ondersteunt 31 bedrijfsdocumenten (document types) en voor elk document is een XSD Schema opgesteld.

Verschil tussen UBL 2.0 en UBL 1.0
Een belangrijk verschil tussen UBL 2.0 en de voorgaande releases is het gebruik van een getrapt (twee-fase) validatiemodel. Tijdens het verwerken van een UBL bericht moet de structuur en het juist gebruik van gestandaardiseerde codes worden gevalideerd. UBL maakt gebruik van internationaal gestandaardiseerde codelijsten, verzameling van toegestane waarden, die worden uitgegeven en onderhouden door standaardisatie instellingen, waaronder ISO (landencodes) en UN/CEFACT (valutacodes, eenheidsmaten, taalcodes). Codelijsten kunnen ook gebruikt worden voor het vastleggen van afgesproken waarden tussen twee of meer handelspartners.

In de voorgaande releases werden de verzameling toegestane waarden of codes rechtstreeks vastgelegd in de XML Schema’s van de bedrijfsdocumenten en kon validatie van structuur en codes gelijktijdig uitgevoerd worden. In UBL 2.0 worden de codelijsten vastgelegd in afzonderlijke configuratiebestanden en kan een getrapt validatieproces gevolgd worden. Hierdoor is het mogelijk om verschillende versies van een codelijst te hanteren per situatie. Zo kan per bedrijf waarmee zaken gedaan wordt een andere versie van een codelijst gehanteerd worden.

UBL 2.0 schema’s ondersteunen het gebruik van een getrapt validatie proces dat schematisch als volgt wordt weergegeven en bestaat uit twee stappen (fasen):

- Stap 1: Controle op structuur, data typing en vocabulary via UBL XSD bestanden en een generieke XSD validator
- Stap 2: Controle op het juist gebruik van waarden uit de codelijsten via UBL XSLT bestanden en een generieke XSLT processor. In deze stap vindt validatie van internationaal gestandaardiseerde codes plaats via de standaard UBL 2 .xsl bestanden en validatie van trading-partner specifieke codes via de customized .xsl bestanden.

Hoe staat het met het gebruik van UBL voor elektronisch zakendoen
Wereldwijd is UBL in gebruik als de elektronische berichtenstandaard voor elektronisch zakendoen tussen bedrijven en overheden. Binnen Europa lopen een aantal landen voorop in de ontwikkeling van een elektronische communicatiestandaard voor elektronisch zakendoen tussen bedrijven en overheden.

Denemarken (National IT and Telecom Agency)
Denemarken heeft de invoering van elektronisch factureren vrij rigoureus aangepakt. Vanaf 1 februari 2005 mogen overheidsinstellingen in Denemarken - dit werd zo vastgelegd in de wetgeving - alleen facturen van leveranciers accepteren in een elektronisch formaat, de OIOXML Electronic Invoice. De OIOXML (Open public Information Online XML) Electronic Invoice is de Deense XML-standaard voor de elektronisch factuur gebaseerd op de eerste versie van UBL release 0.7. Voor meer informatie: OIOXML Electronic Invoicing.

Bedrijven kunnen op een aantal manieren facturen aanleveren:
1) via het aanmaken en verzenden van een elektronische factuur vanuit het facturatie-systeem via de elektronische postbus van een Value Added Network (VAN).

2) via een Read-In Bureau die zorgdraagt voor het scannen en converteren van een papieren factuur naar het elektronische formaat en het verzenden van deze elektronische factuur naar de juiste overheidsinstelling via een Value Added Network.

3) via het handmatig invoeren van de factuur in een Internet Invoice Portal die zorgdraagt voor het aanmaken van de factuur in het elektronische formaat en het verzenden van deze elektronische factuur naar de juiste overheidsinstelling via een Value Added Network

Schematisch ziet dit er op hoofdlijnen als volgt uit:

De Deense overheid stelt volgende eisen aan de informatie in de factuur:
- het gebruik van de EAN locatiecode voor identificatie van de klant is verplicht en de klant moet de EAN code verstrekken tijdens het plaatsen van de order
- een referentie naar de inkooporder of bestelling is verplicht
- een referentie naar de persoon die de order heeft geplaatst is verplicht
- interne identificatiecode van de klant is verplicht als deze verstrekt werd tijdens het plaatsen van de order

Let op: Denemarken maakt vooralsnog geen gebruik van de OIOUBL Invoice. De OIOUBL standaard wordt wel aanbevolen voor het uitwisselen van elektronische catalogi en inkooporders. OIOUBL is gebaseerd op UBL release 2.0 (Voor informatie: Online OIOUBL Documentation)

Noord-Europa
Northern European Subset (NES) is een initiatief dat voortvloeit uit de samenwerking tussen enkele Noord-Europese landen op het gebied van e-commerce en e-procurement. Onder aanvoering van Denemarken hebben vertegenwoordigers van de Noord-Europese landen Denemarken, Zweden, Noorwegen, Ijsland, Finland en van het Verenigd Koninkrijk begin 2007 een werkgroep opgericht voor het ontwikkelen van een Noord-Europese Subset (Northern European Subset (NES)) van op UBL 2.0 gebaseerde documenten.

De NES organisatie heeft de Universal Business Language (UBL) geselecteerd als de Open berichtenstandaard - met op dit moment de meeste potentie - voor het realiseren van grootschalige e-commerce en e-procurement handelstransacties tussen overheden onderling en bedrijven, zowel grensoverschrijdend (cross-border) als nationaal (domestic).

Het NES project richt zich niet op het uitvoeren van implementaties maar heeft als voornaamste doel zorgdragen voor het tot stand komen van een gezamenlijk platform voor e-procurement.

De belangrijke resultaten van het NES project zijn:
- Profielen die bedrijfsprocessen en scenario’s beschrijven uitgaande van UBL voor handelstransacties
- Berichtdefinities gebaseerd op een gemeenschappelijke subset (deelverzameling) van UBL handelsdocumenten
- Handleidingen en codelijsten
- Validatiegereedschappen

De aangesloten landen zijn zelf verantwoordelijk voor de uitvoering en coördinatie van implementaties. De laatste versie van NES is op 11 juli 2007 vrijgegeven en kunt u terugvinden onder de rubriek Documents op de website van NES. Al het materiaal van NES is gepubliceerd onder de Creative Common license.

Zweden
In Zweden loopt het project Single Face To Industry (SFTI). Het is een alles-in-één e-procurement standaard waarmee het bestel- en facturatieproces tussen handelspartners wordt ondersteund. Voor het bestelproces is sinds juni 2010 de CEN/BII Basic Order de aanbevolen standaard voor de publieke sector

Duitsland
In Duitsland is deze maand de German Localization Subcommittee (DELSC) samengesteld. Deze gaat zich buigen over de realisatie van een Duitse UBL Data Dictionary.

Spanje
CODICE is het Spaanse overheidsinitiatief voor het ontwikkelen van een verzameling elektronisch documenten gebaseerd op UBL voor de ondersteuning van het aanbestedingsproces. Vereenvoudigd zijn er drie processtappen die worden ondersteund: aankondigen of bekendmaken, aanbieden en gunnen.

De specificaties van de CODICE standaard zijn terug te vinden op de website contrataciondelestado.es.

ABILITIES
Het Europees project “Application Bus for InteroperabiLITy In enlarged Europe SMEs”, kortweg ABILITIES, is gestart begin 2006 en heeft een looptijd van 2 jaar. Het voornaamste doel van het project is het onderzoeken en ontwikkelen van een architectuur gebaseerd op UBL voor de ondersteuning van e-commerce transacties tussen kleine en middelgrote bedrijven (SMEs) voornamelijk in de minder ontwikkelde landen.

ABILITIES voorziet in drie interfaces:
- een Web portaal
- een GUI voor mobiele toegang
- een interface voor legacy systemen gebaseerd op web services

U.S. Department of Transportation (USDOT) Electronic Freight Management (EFM) initiatief
Het Electronic Freight Management (EFM) initiatief richt zich op de promotie en evaluatie van innovatieve e-business concepten. Het is een Research & Development project dat gesponsord wordt door de U.S. Department of Transportation (USDOT). De Electronic Freight Management (EFM) is geïmplementeerd op basis van de Freight Information Highway (FIH) architectuur. De FIH is een innovatieve non-propriëtaire service-georiënteerde architectuur voor de ondersteuning van de coördinatie tussen bedrijfsprocessen en veilige real-time gegevensuitwisseling.

Het EFM maakt gebruik van gestandaardiseerde berichten gebaseerd op UBL waaronder Advance Ship Notice, Dispatch Advice, Receipt Advice en Transportation Status.

Meer projecten en initiatieven staan op stapel en hierover zal ik later berichten.

Tags: electronic data interchange, Enterprise Service Bus, EDIFACT, Government, UBL, UN/CEFACT, CEN/BII

Last update: 3-12-2011

Het bedrijf XAware, Inc. is opgericht door Bill Miller (CTO) en Kirstan Vandersluis (Chief Science Officer) in 1999 en gevestigd in Colorado Springs, USA en heeft een data integratie gereedschap ontwikkeld voor de realisatie en ondersteuning van een Service Oriented Architecture (SOA).

XAware ondersteunt enkele belangrijke industrie-standaarden waaronder ACCORD (Insurance Data Standards - ACORD XML & EDIFACT), HL7 (Healthcare) en zowel SWIFT als IFX (Interactive Financial eXchange - Finance).

Sinds November 2007 is de XAware Suite als Open Source Data Integratie Oplossing vrij beschikbaar onder de GPL v2 licentie. De XAware Suite bestaat uit een ontwikkelomgeving, de XAware Designer, en een run-time machine, de XAware Engine. Naast deze componenten kent XAware Adapters en Connectors die zorgdragen enerzijds voor de logische connectiviteit met de applicaties en anderzijds voor de logische en technische connectiviteit tussen de bron en bestemming.

De voornaamste componenten van de XAware Suite zijn in het plaatje hieronder weergegeven:

De XAware Designer is een Eclipse plug-in waarmee web services en data integratie oplossingen gebouwd, getest en in gebruik genomen kunnen worden. Het is een grafisch visueel ontwikkelgereedschap voor het ontwikkelen en deployen van op XML-gebaseerde diensten in de vorm van meta data bestanden zoals BizDocuments, BizComponents en BizDrivers.

De XAware Engine is een J2EE applicatie die deployed kan worden op applicatieservers waaronder Oracle, SUN, JBoss en WebSphere maar eveneens op webservers zoals Tomcat, Microsoft IIS en Apache. De XAware Engine beschikt over een modulaire architectuur die is gerealiseerd bovenop het Java/J2EE Spring Framework en in staat is om hoge transactievolumes te ondersteunen.

De XAware Connectoren en Adapters verzorgen de connectiviteit met applicaties of back-end systemen en leveren de interface-technologieën die applicaties gebruiken voor het verkrijgen van toegang tot op XML-gebaseerde diensten. Hierbij moet u ondermeer denken aan de connectiviteit met relationele databases, transformatie van gestructureerde en ongestructureerde bestanden van bron naar bestemming, de verbinding met messaging queues en mainframe of ERP integratie.

Download en installatie van de XAware Suite De totale XAware Suite, bestaande uit de Designer en de Engine, kunt u downloaden als een All-In-One pakket. Het All-In-One pakket bevat eveneens een JBoss applicatieserver, een Java run-time omgeving (JRE 1.5) die nodig is om XAware te kunnen draaien en een Apache Derby met voorbeelden van use cases en scenario’s.

Ga naar de website van XAware, xaware.org en klik op het menu Downloads. Download nu het XAware All-In-One pakket (+500MB) voor uw besturingssysteem. Wanneer u het installatiebestand met extensie EXE download dan hoeft u na de download enkel de excutable op te starten en de installatie instructies te volgen.

Na installatie is onder uw lijst met programma’s de XA-Suite 5.0 met de XA-Designer en XA-iServer aangemaakt.

Wanneer u de XA-Designer opstart zult u de eerste maal gevraagd worden de folder op te geven voor uw werkruimte. Accepteer de voorgestelde folder of maak een nieuwe folder aan voor uw werkruimte. Meer hierover in mijn bloart Aanmaken van een specifieke workspace in Eclipse.

Openen van het Eclipse XAware perspectief
Wanneer Eclipse is opgestart zorg er dan voor dat het XAware perspectief geopend is.

- Ga naar het menu Window en open de menuoptie Open Perspective

- Selecteer de menuoptie XAware perspective

Aan de linkerkant van het scherm ziet u het Project navigatiegedeelte en aan de rechterkant ziet u de Palette met alle beschikbare componenten. Het werkgebied in het midden van het scherm is de plek waar de BizView en XML bestanden worden geopend en getoond.

Onderaan links bevindt zich het scherm waarin het executieprofiel van een BizView bestand getoond wordt. Rechts daarvan wordt informatie getoond gerelateerd aan het geopende bestand of bestanden in het werkgebied. Hier ziet u verschillende tabbladen waaronder de Log View, de Execution Results View, de Properties View, de Component Catalog View en de Problems View.

Tags: eclipse, data mapping tool, enterprise service bus</>

Last update: 26-11-2011