Indien uw applicatielandschap aan veel veranderingen onderhavig is of als er meerdere front-end applicaties contact maken met meerdere back-end systemen, heeft u in principe een complex applicatie landschap.
Hoe kan de beheerorganisatie hier nu het beste mee om gaan? Wat voor applicatie landschap moet u naar streven?

De beste remedies hiertegen zijn natuurlijk een constante aandacht voor versimpeling van het applicatie landschap (bijvoorbeeld van integratie van functionaliteiten in 1 pakket) en standaardisatie van informatiestromen.
 

Standaardisatie kan echter op meerdere niveau's van de architectuur:

• Standaardisatie van informatie.
  Dit is tegelijk de lastigste om te beheren. Bij de keuze van de standaard informatie elementen en informatie groeperingen moet tegelijk een afweging gemaakt worden van toepassingsmogelijkheden versus over/under delivery van informatie.
  De basis hiervoor kan gelegd worden in de inrichting van uw organisatie en administratieve processen en de toepassing van een LEAN aanpak.
• Standaardisatie van bronnen.
  Ook dit is een direct gevolg van de inrichting van organisatie processen, communicatievormen en verantwoordelijkheden. Uitgangspunt in een Lean organisatie is 1 bron per informatie-element.
• Standaardisatie van de communicatievorm
  Denk hierbij aan een universele manier van communicatie, bijvoorbeeld in xml via gestandaardiseerde api's.
• Vermindering en groepering van communicatie(punten).
  2 geregeld voorgestelde concepten hiervoor zijn:
  • Het gebruik van een Enterprise service bus als middelware laag.
    Hierbij praat elke applicatie uitsluitend met de Enterprise service bus. In principe weet een applicatie dus niet met welke applicatie contact wordt gelegd voor levering en ontvangst van informatie.
    In de Enterprise service bus zit de intelligentie / architectuur hiervoor. Ze bewaart in principe geen informatie, maar is alleen een “communicatie snelweg” met gestandaardiseerde connecties. Zij regelt pull van informatie en reageert op push van informatie. Zij weet de bron en toepassing van informatie. De applicaties weten dit echter niet.
    De ESB streeft hierbij standaardisatie van informatie na en anonimiseert de informatie.

Voordelen hiervan zijn:

• Applicaties zijn echt vervangbaar zonder invloed te hebben op de vorm en inhoud van de connecties met andere applicaties. Alleen connecties met de enterprise service bus moeten opnieuw opgezet worden bij vervanging.
• Hierdoor is het dus met name geschikt voor functionaliteit die in ontwikkeling is of “vluchtig” is.
• Het is met name geschikt bij connectie tussen vele kleine applicaties, zonder veel zwaargewichten.

Nadelen zijn:

• De complexiteit is groot in het ontwerp van de ESB.
• Niet alleen definities van informatieflows, maar ook van de frequentie, reactie mechanismen en fall-back bij uitval van commnicatie moet worden geregeld. Dit is complex.
• Per data element is er een bron waarmee richting alle andere gebruikers gecommuniceerd moet worden.
• Voor data analyse is er geen central bron van informatie. Wel een centrale aanspreekpartner die het kan verzamelen. (met alle onzekerheden van dien)
• De meerwaarde ligt alleen in de communicatie, niet in functionaliteit voor gebruikers. Vanuit een LEAN optiek moet de meerwaarde dus hoog zijn om te voorkomen dat deze applicatie er tussenuit gesneden gaat worden.

• Het gebruik van een zware functionele applicatie als middelware/communicatie middel met centrale data opslag.
  Laat zo veel mogelijk essentiële informatie naar die centrale applicatie lopen (vaak het ERP systeem). Overige applicaties hebben in principe geen onderling contact, tenzij ze gezamenlijk 1 functionaliteit bieden.
  Een bronapplicatie update bij een mutatie alleen deze centrale applicatie database. Van daaruit worden andere applicaties gevoed.

Een aantal voordelen:

• 1 centraal punt bevat altijd de “waarheid” aan informatie.
  Als een bron uitvalt, zullen alle overige applicaties nog steeds gevoed kunnen worden met eenzelfde gesynchroniseerde “waarheid” (al is die op dat moment achterhaald)
• Het centrale systeem biedt ook de mogelijkheid van data-analyse op de centrale data.
• Er is 1 applicatie minder te beheren die geen intelligentie hoeft te hebben ter voorkoming van communicatieproblemen.
• De communicatie loopt niet via, maar naar dit centrale punt. Hierdoor heb je een (logistiek) informatie ontkoppelpunt geintroduceerd met lagere gevoeligheid voor communicatie problemen.
• Automatisch een drang om nieuwe functionaliteit te integreren in de centrale (ERP) applicatie, waardoor het systeemlandschap simpeler blijft. (De ERP applicatie zelf natuurlijk niet.)

Nadelen:

• Vervanging van de centrale applicatie gaat moeilijker. Het moet dus een stabiele applicatie zijn en voor een lange termijn inzetbaar.
• Ook hier moet niet vergeten worden (synchronisatie) informatie standaarden af te spreken.