2018/11/27

(Dutch) Integreer ERP en productie zonder hoofdpijn met ISA95



1.1      Introductie

Veel bedrijven hebben moeite om de business systemen aan te sluiten op de productie vloer systemen. Dit zijn bedrijven die producten maken en waarbij productie locaties de daadwerkelijke producten maken. Bij de kantoren worden sales orders ontvangen die worden doorgestuurd naar de planningsafdeling en waarbij er uiteindelijk productie orders worden verstuurd naar de productievloer. Deze supply chain bestaat dan uit plan-source-make-deliver.

Figuur 1 ISA95 context

Veel bedrijven hebben vaak te maken met de volgende uitdagingen:
  •         De business (sales, managers, planners) praten vaak een andere vaktaal dan de medewerkers op de productievloer
  •          Bedrijven groeien gestaag door en er worden vaak nieuwe productielocaties bijgebouwd en/of overgenomen. Dit leidt dan weer tot integratie uitdagingen.
  •          Nieuwe producten die worden geïntroduceerd moeten nog volledig worden opgenomen in het productieproces. Het kost veel tijd om dit goed te integreren met de processen op de productievloer

·         IT systemen die gebruikt worden in de verschillende lagen hebben vaak andere eisen (denk aan beschikbaarheid en performance)

Klinkt dit herkenbaar en ervaar je dit ook als frustrerend? Wellicht is de ISA95 standaard een oplossing voor je!
Dit artikel gaat in op de mogelijkheden van ISA95 en hoe deze standaard kan helpen bij bovengenoemde uitdagingen. Laten we beginnen om kort uit te leggen wat ISA95 is.

1.2      Wat is ISA95?


ISA95 is een internationale standaard en bestaat uit modellen en terminologie die nauwkeurig in kaart brengen welke informatie moet worden uitgewisseld tussen systemen gericht op verkoop, financiën en logistieke systemen gericht op productie, onderhoud en kwaliteit. Het geeft handvaten voor applicatie rationalisatie en het scheppen van overzicht welke informatie moet worden uitgewisseld tussen de kantoorsystemen en de productieautomatiseringssystemen.
Figuur 2  ISA95 scope

De standaard richt zich niet op de productievloer zelf. Hier kunnen ISA88 en ISA106 helpen, maar dat is niet de scope van dit artikel.

Welke modellen heb je dan allemaal tot je beschikking?

1.3      De modellen van ISA95

ISA95 kent verschillende modellen voor de rationalisatie van het integratie landschap in beeld te brengen.

Figuur 3  ISA95 modellen

· Domain Definities
Het begint met het aanbrengen van de scheiding tussen het zogenoemde Enterprise Domain en Control Domain. Dit is de scheiding tussen respectievelijk de business en de productie functies.
· Functies
Daarna worden de functies verdeeld over deze domeinen. ISA95 heeft een overzicht van generieke functies die in elk bedrijf een rol spelen.
· Relevante functies
Relevante functies worden in de “functions of interest” benoemd. In dit model wordt ook aangegeven welke systeem applicaties verantwoordelijk zijn voor welke functies.
· Informatieflow
Met de “information flows of interest” wordt aangegeven welke informatie er tussen de systemen wordt uitgewisseld tussen de verschillende lagen.
· Categorieën
De informatie wordt verder opgedeeld in categorieën en hier verder uitgewerkt. Het gaat hierbij om productie-, kwaliteit-, performance- en/of inventory informatie.
· Informatie definities
Alle data definities van de benodigde data entiteiten worden vastgelegd in detail.



Figuur 4  Informatie definities

ISA95 gaat niet verder dan de logische data definities en de implementatie wordt overgelaten aan de bedrijven. Hiervoor kan het interessant zijn om ook naar B2MML te kijken.

1.4      B2MML

B2MML is een verzameling van XML schema’s voor de representatie van de ISA95 data entiteiten. Deze kunnen gebruikt worden in het berichtenverkeer tussen de verschillende systemen.

1.5      Conclusie

ISA95 heeft een standaard begrippenmodel dat de verschillen in vaktaal tussen de business en productievloer kan weghalen.
ISA95 standaardisatie van interfaces maakt integratie eenvoudiger en kan de migratie met nieuwe locaties versnellen.
Aangezien ISA95 een scheiding maakt tussen de business- en de productie processen worden de processen flexibeler en kunnen de systemen in de verschillende lagen afgestemd worden op de behoeftes in die specifieke laag (zoals bijvoorbeeld beschikbaarheid en performance).

ISA95 en B2MML standaarden helpen om de integratie tussen business- en productievloer systemen te definiëren en te implementeren. Het helpt om de bedrijfsprocessen te scheiden van de productie processen en hiermee flexibiliteit te creëren.

Wil je meer weten dan neem contact met me op, want ik heb een implementatie gedaan bij een klant en kan je wellicht helpen.

2018/11/26

Architecture is sexy or a paradox?




Op 15 november 2018 hebben we met SynTouch het Landelijk Architectuur Congres bezocht in
de Brabanthallen in Den Bosch. Dit jaar was het thema “Paradoxen in Architectuur”.
En dit jaar konden we een feestje vieren, want het LAC bestaat 20 jaar !


Normaal gesproken is het beeld van een architect saai, oubollig en werken vanuit een ivoren toren.
Kijken of hier langzaam verandering in gaat komen en zelfs sexy gaat worden.
Of blijkt dit toch nog steeds een paradox?

Een kijkje in de wereld van architectuur





De dag begon met twee keynotes. De eerste keynote ging over het feit dat we aan de vooravond
staan van een nieuwe digitale revolutie. Een betoog over het feit dat steeds meer wordt
geautomatiseerd en dat we als mens worden ingehaald door de techniek. Het zal spannend worden.
De tweede keynote ging over de reisorganisatie Tui, die bezig zijn met een nieuw business model
te implementeren om met de concurrenten de strijd aan te kunnen gaan.
Denk hierbij bijvoorbeeld aan de Uber, Airbnb en Bookings van deze wereld. Deze bedrijven zijn
exponentieel gegroeid, waarbij ze zelf niets in bezit hebben. Ze bieden een platform aan waarin
ze partijen bij elkaar brengen. Tui wil het voorportaal zijn waar klanten hun reisbeleving beginnen en
waarbij de beste opties worden voorgesteld. Hierbij speelt data, artificial intelligence, analytics en
integratie een belangrijke rol.
Twee enerverende keynotes, die tot inspiratie leidde.




Toen was het de beurt aan de trackleaders om hun jaarlijkse elevator pitch te houden.
Dit is een traditie waarbij een track “verkocht” wordt aan het publiek. Dit jaar waren er 7 verschillende
tracks:
  • Renaissance van Architectuur
  • Viable System Model
  • Ethiek en Architectuur
  • Join forces of researchers and practioners
  • Blockchain
  • Solution Architecture
  • The 4th industrial revolution



  • Solution Architectuur
Dit was de track die ik persoonlijk heb gevolgd (met een laatste uitstap naar het VSM model).
De onderwerpen van deze track gingen over distributed systemen, event driven architecture in een
Microservices- en analytics omgeving, cloud agnostisch bouwen op PaaS diensten en business
agility met architectuur.
Helaas geen nieuwe inzichten verkregen tijdens deze sessies. Wel een goed verhaal over business
agility en architectuur met een meer uitvoerende rol van de architect in de teams.




Viable System Model

Dit was de track waarbij de energie er vanaf droop. Een heerlijke ADHDer voor de groep en een
inspirerend verhaal over deze (voor mij nieuwe) methode.


Mocht je meer willen weten over deze (wetenschappelijk bewezen) methode dan werd er aangeraden
de volgende boeken eens te lezen: “Brain of the firm” van Stafford Beer en “Waarom gaan dingen nou
nooit eens een beetje vanzelf ?“ van Ed van der Winden. Het laatste boek geschreven door de
entertainer himself en een stuk leesbaarder dan het eerste.


In feite is alles een systeem dat beïnvloed wordt door zijn omgeving en waarbij er een balans wordt
gezocht tussen het heden en de toekomst. Een beetje een vaag verhaal maar het heeft mij getriggerd
om eens wat meer te gaan lezen hierover.

Conclusie



Het congres was weer een leuke dag om wat contacten op te doen en ervaringen uit te wisselen.
Verder weinig verrassende nieuwe inzichten verworven.
Ik moet helaas concluderen dat het stoffige imago nog steeds wel een beetje hangt aan de architect
en weinig seksie. Maar goed het is ook een ambacht waarbij je toch wel wat meters gemaakt moet
hebben om dit goed uit te kunnen voeren. Ervaring, veel je neus stoten, proberen, opstaan en weer
mee met de volgende hype. Het blijft in ieder geval een mooie gelegenheid om ervaringen uit te
wisselen en elkaar te inspireren. Laten we vooral doorgaan met dit mooie beroep.

Fijne avond LAC en tot de volgende keer !

2018/08/29

Event Driven Architecture with Oracle EDN



"The flying Dutchman" (see also photo page)



Key Takeaways
  • Event Driven Architecture helps with decoupling applications

  • Think about the names used for events
  • Let Publisher publish and filter within subscribers
  • Use meta data within event headers
  • Use standardization on entities within Event, so that the Event is a first citizen data object

Introduction

There is a lot of hype around Microservices and the use of events for implementing the choreography pattern. However this is nice for companies like Netflix and Twitter, but there are a lot of organisations still struggling with files and ESB like products. Also my current client uses an ESB namely the Oracle SOA Suite 12c for integrations. We cannot just throw away this ESB, but we can make use of the event mechanism built in. This blog describes the way we use the EDN (Event Delivery Network) component, that is used within SOA composites to throw events and to subscribe on events.

EDN

Oracle has a component that you can use to publish events and to subscribe on events within a SOA composite. Just use the invoke activity with the eventname and the content of the event. Within a composite you can subscribe on events and set filters. You can also configure “oneAndOnlyone” consistency property and indicate if you want a durable or non-durable subscriber. The EDN hides the underlying JMS provider, which can be changed (weblogic jms or OracleAQ). Separate Topics can be defined for each event or just use 1 topic for all events.
Notes:
  • Applications must always be abstracted by a corresponding SOA Composite. Applications should not use JMS directly 
  • EDN cannot be used directly from within Oracle OSB

Event

We use the following definition for an event. The event is based on business entities and the operations executed on those entities. We use the following definition:

BusinessObject    The name of the business entity, i.e. Invoice, Customer
Operation         Created, Updated, Deleted
TrackingId        Tracking ID so that flows can be followed
SourceSystem      The system that published the event
TargetSystem      The target system to which the event must be sent explicitly. This is
an optional field
Identifiers       This is used to add meta data, i.e. invoice number, location, order number
Message           The message. This contains the content of the business entity

Master data entities
This works fine for master data entities, because you want to use events to indicate that entities are created, updated or deleted. We use this to decouple the MDM solution from the interested applications. New applications are easily added by making a SOA composite subscriber for that application.

Transactional data
In this case the solution falls short, because the context is missing. For example when an Invoice is received from a customer, you want to send the event InvoiceReceivedFromCustomer. In our case we use the Created operation on Invoice but this does not say much. Within the meta data we had to add more context information.


Lessons learned
  • Think about the names you use for Events, i.e. Invoice_Create is too vague and will need more metadata to filter on the correct event
  • Think about the data you put in the message
  • Master data entities can be especially good candidates to publish

Data will change

The content of entities will change, i.e. fields are added. After this change you want to synchronize the interested applications with this new information. This is especially needed for master data. So you are decoupled on the publishing- and subscribing applications, but still strongly coupled to the data. You need to synchronize the new dataset to the applications (batch). There are several options:

·         Use ETL to synchronize the data

This can be a good option in case it is lots of data. Extra tooling and data transformation is needed, which you tried to avoid. The source and target systems are again coupled.


·         Publish all data and make use of the Pub-Sub implementation
This works fine in case there are less entities. You don’t need extra ETL tooling but re-use the publish-subscribe mechanism. We use this and also use the targetSystem field within the event, when we know it is only relevant to a particular application(s).


Lessons learned
  • Think about data reconciliation in case data fields are changed
  • Try to avoid ETL because this couples the source and target systems again


Filters

What I see often in integration projects, is that each interested application a new integration is built particularly for that application. For example a new supplier wants to retrieve Invoice messages from the company. However it wants to retrieve the invoice in its own format (for example csv) and based on its own protocol (for example sftp). The application, that generates the invoices, just exports yet another file. What I propose is to let the publishing application generate Invoice events. It should have no knowledge about the interesting applications. It just has to do the jobs. Then for each supplier make a Subscribe composite that filters the Invoices targeted for that supplier and map the Invoice to the suppliers format and protocol. This is where the Subscriber composite filters come in.


With the filter you can define which events you want to receive. Note that you can also indicate if you want to have a Durable subscriber. In that case you receive events in case the composite was stopped.


Lessons learned
  • Let Publishers publish all data and let Subscriber filter the correct data
  • Filter on the meta data part of the event and not on the event message content

Error handling

Functional- and technical errors are unavoidable. This also is the case with events, but with the extra complexity that the publisher is decoupled from the subscriber(s). This means that in case the event is published from the source, the work is done. But still errors can occur within the subscriber both functionally as technically. you have to think of the following scenario's:
  • Do i want to be able to re-publish the same event?
    The consequence is that target systems must implement idempotency
  • Does the sending application need to know that all targets have successfully handled the event?
    I my opinion you should try to solve the problem at the target, because otherwise you introduce strong coupling again. This also depends on the business requirements of course.

Conclusion

There are more topics that can be discussed, i.e. event versioning, data security. Maybe another time.
As always, feedback and questions are very welcome !


Conclusion
Event driven architectures can be a good solution to decouple applications! We are now able to connect new applications faster than before, because of the Pub-Sub pattern and the standardization of the event data.
Think about the events you publish, because otherwise you still need much of filter logic within the subscribers. Also think about the way you want so solve data synchronization/reconciliation in case the data is changed.


2018/06/01

Microservices mindmap

"The tree" - See also  my photo page

When you are fairly new within the Microservices land, there are a lot of terms fired at you. So also for my own understanding i have made a mindmap. I think it has a good status now, so that i can share it with you. As always feedback is very welcome !


You can download the mindmap here.

2018/05/18

Cloud to Cloud Application Integration






A lot of applications have integration possibilities, so do cloud applications. The question I got from a customer is whether to have a point-to-point integration with Cloud applications or to go through their ESB solution. This blog describes some considerations.





Context
The customer has a HRM application in which job vacancies are managed. Furthermore that system also handles the full applicant process flow. They also have another cloud application that handles the job vacancies. This application posts the jobs to social sites and other channels to promote the vacancies. Furthermore this application has some intelligence for job seekers to advice some new vacancies based on previous visits or profiles. The job vacancies need to be sent to the Vacancies application and applicant information needs to be sent to the HRM application, when a job seeker actually applies for a job. Furthermore status information about the job application is also sent back. This flow of information is depicted in the next figure.

Integration options
Several options are discussed to integrate these cloud applications.
Point-to-point
The two applications have an out-of-the-box integration possibility, so integrating this way is easy.

However also consider:
  •          Dependent on the cloud suppliers to integrate on infra level
  •          Monitoring is not conform the guidelines of your company. Maybe there is no monitoring at all.
  •          Exception handling is not conform the guidelines of your company, so what happens when something goes wrong on integration level
  •          What happens when one cloud application is migrating to another version? Maybe the other application must migrate as well, and maybe this is not what you want.
  •          Security: what are the security possibilities of the applications and the integrations? Is this conform company standards? Is this conform regulation requirements?

This option is viable if it is seen as one application function, in which you can see it as 2 modules within the same application. Furthermore integration is taken care of by the two cloud suppliers.
Enterprise Service Bus
In case more control is needed for the integration and job vacancies are also interesting for other applications to integrate (job boards), the ESB solution can also be an option. A lot of companies are still using ESB i.s.o. Microservices architecture. They still have a lot of old applications which need adapters to decouple the systems.


Advantages of this solution:
  •          Use of common business entity on the ESB to decouple applications
  •          Monitoring conforming company guidelines
  •          Exception handling conforming company guidelines
  •          Reuse of services possible
  •          Reuse of events for other interested applications
  •          Company can decide which parts of the application APIs are used

Note that the ESB can be cloud and on-premise.
Disadvantages:
  •          Extra layer
  •          Company must setup the infrastructure connections themselves


Conclusion
Depending on your requirements, guidelines and timing constraints, there are always several options for integrating cloud applications. Considerations:
  •            Flexibility information delivery (decoupling)
  •            Own connection infrastructure control
  •            Monitoring requirements
  •            Exception handling requirements
  •            Security and compliance requirements
  •            Upgrading cycles of cloud applications

Feedback is always welcome!