Üzletirendszer-fejlesztés

Üzletirendszer-fejlesztési fogalomtár

Tizennyolc gyakorlati meghatározás, amely összekapcsolja az architektúra, az adatok, az integráció, az MI és az automatizálás nyelvét az üzleti döntésekkel és működési következményekkel.

01

Üzleti rendszer

Az egymással összekapcsolódó emberek, döntések, folyamatok, adatok, alkalmazások, szabályok és kontrollok együttese, amely üzleti eredményt hoz létre.

Miért fontos ez az üzletnek?

Megakadályozza, hogy egy technológiai összetevőt úgy kezeljenek, mintha az egész működési probléma lenne.

Példa

A megrendelés teljesítése magában foglalja a döntéseket, a készletadatok jelentését, a partneri adatcseréket, a kivételeket és a bizonyítékokat — nem csupán a rendelési alkalmazást.

Más néven: · társadalmi-technikai rendszer · működési rendszerkörnyezet

02

Vállalati architektúra

A szervezeti változások irányítására használt képességek, információk, alkalmazások, technológia, döntések és átmenetek koherens áttekintése.

Miért fontos ez az üzletnek?

Összekapcsolja a beruházásokat és a megvalósítási döntéseket az általuk érintett képességekkel és korlátokkal.

Példa

A célarchitektúra nemcsak a jövőbeli komponenseket, hanem a felelősségeket, az átmeneti állapotokat és a döntési alapelveket is megmutatja.

Más néven: · EA · üzleti és technológiai architektúra

03

Integráció

Adatok, események vagy műveletek megtervezett cseréje és összehangolása rendszerhatárokon át.

Miért fontos ez az üzletnek?

A megbízható integráció megőrzi a jelentést és az állapotot azokon a pontokon, ahol egyetlen komponens sem irányítja a teljes eredményt.

Példa

A partneri rendeléscsere az üzenettovábbítás mellett az identitást, az ellenőrzést, a választ, az újrapróbálást és a helyreállítást is meghatározza.

Más néven: · rendszerintegráció · alkalmazásintegráció

04

Interoperabilitás

A független rendszerek és szervezetek arra való képessége, hogy információt cseréljenek és azt közös, operatív értelemben vett értelmezéssel használják fel.

Miért fontos ez az üzletnek?

Egy beérkezett, de félreértett üzenet műszakilag összekapcsolt rendszereket jelez, a gyakorlatban azonban nem jelent interoperabilitást.

Példa

Mindkét fél következetesen értelmezi az elfogadott, elutasított és függőben lévő állapotokat, és tudja, kinek kell cselekednie.

Más néven: · szemantikai interoperabilitás · keresztrendszer-kompatibilitás

05

Adatirányítás

Azok a döntések, felelősségek, szabályzatok és kontrollok, amelyek számonkérhetővé teszik az adatok jelentését és felhasználását.

Miért fontos ez az üzletnek?

Az adatminőségi és hozzáférési munkát lényeges üzleti döntésekhez köti, nem önálló megfelelőségi gyakorlattá teszi.

Példa

Az adatgazda meghatározhat egy kritikus fogalmat, jóváhagyhatja a felhasználást, és a rögzített döntési kockázat alapján megoldhat egy minőségi problémát.

Más néven: · adatfelelősség · információirányítás

06

Adatok eredetlánca

Nyomon követhető tudás arról, honnan származik az adat, hogyan változott, és hol használták fel.

Miért fontos ez az üzletnek?

Az eredetlánc segíti a magyarázatot, a hatáselemzést, a kontrollt és a megkérdőjelezést, amikor egy döntés átalakított adatoktól függ.

Példa

Egy jelentett érték a forrástól az ellenőrzésen és összesítésen át a döntéstámogató irányítópultig követhető.

Más néven: · adateredet · az adatok nyomon követhetősége

07

Adatszerződés

Egyértelmű, verziózott megállapodás a rendszerhatáron átadott adatok szerkezetéről, jelentéséről, minőségéről, felelősségéről és viselkedéséről.

Miért fontos ez az üzletnek?

Tesztelhetővé teszi a változással és hibákkal kapcsolatos elvárásokat ahelyett, hogy a fogyasztókra bízná azok kikövetkeztetését.

Példa

A szerződés rögzíti a kötelező mezőket, a szemantikai meghatározásokat, a verziópolitikát, az elutasítási viselkedést és a felelős adatgazdát.

Más néven: · interfész-adatmegállapodás · sémaszerződés

08

Eseményvezérelt architektúra

Olyan architektúra, amelyben a jelentős állapotváltozásokat események fejezik ki, az érdekelt komponensek pedig aszinkron módon dolgozzák fel őket.

Miért fontos ez az üzletnek?

Szétválaszthatja az időzítést és a felelősséget, de csak akkor, ha az esemény jelentését, identitását, sorrendjét és helyreállítását is megtervezték.

Példa

A rendelés jóváhagyását jelző esemény egy homályos frissítési értesítés helyett az üzleti tényt és a stabil identitást rögzíti.

Más néven: · EDA · eseményalapú architektúra

09

Idempotencia

Olyan feldolgozási tulajdonság, amely lehetővé teszi ugyanazon kérés vagy esemény többszöri alkalmazását nem szándékolt további üzleti hatás nélkül.

Miért fontos ez az üzletnek?

Ez lehetővé teszi a biztonságos ismétlést, ha a feladó nem tudja, hogy az első kísérlet befejeződött-e.

Példa

Egy fizetési állapot frissítésének ismétlése a már rögzített eredményt adja vissza ahelyett, hogy második fizetést hozna létre.

Más néven: · biztonságos újrapróbálás · duplikációvédelem

10

Célarchitektúra

A meghatározott üzleti képességet és irányítást támogató tervezett jövőbeli struktúra, felelősségi körök és elvek.

Miért fontos ez az üzletnek?

Koherens célt ad a döntéseknek anélkül, hogy egyetlen visszafordíthatatlan megvalósítási útvonalat feltételezne.

Példa

A cél meghatározza a megbízható partnerbekapcsoláshoz szükséges szakterületi felelősséget, interfészeket és kontrollhatárokat.

Más néven: · jövőbeli állapot architektúrája · tervezett architektúra

11

Átmeneti architektúra

Szándékosan működtetett közbenső állapot a jelenlegi és a célarchitektúrák között.

Miért fontos ez az üzletnek?

Az együttélést, az ideiglenes kontrollokat, a kockázatokat és a kilépési feltételeket a terv részévé teszi, nem a megvalósítás véletlen maradványaivá.

Példa

A régi és az új rendelési szolgáltatás együtt működik, egyértelmű egyeztetési, döntési jogköri és kivezetési feltételekkel.

Más néven: · köztes architektúra · migrációs állapot

12

MI-felkészültség

Annak mértéke, hogy egy konkrét MI-felhasználás rendelkezik-e megfelelő értékkel, adatokkal, munkafolyamattal, architektúrával, felügyelettel, értékeléssel és üzemeltetési felelősséggel.

Miért fontos ez az üzletnek?

Megakadályozza, hogy a modell műszaki megvalósíthatóságát összetévesszék az üzemi képességgel.

Példa

Egy felhasználás csak akkor áll készen, ha a döntés felelőse, az adatok alkalmassága, az emberi felülvizsgálat, a felügyelet és a tartalék működés egyértelmű.

Más néven: · MI üzemi felkészültség · szervezeti MI-felkészültség

13

Emberi felügyelet

Az automatizált vagy MI-vel támogatott művelet köré tudatosan tervezett emberi felelősségek, információk, döntési jogkörök és beavatkozási pontok összessége.

Miért fontos ez az üzletnek?

Az emberi részvétel csak akkor érdemi, ha az illető időben megértheti, megkérdőjelezheti és módosíthatja az eredményt.

Példa

A felülvizsgáló megkapja a szükséges kontextust, elutasíthat egy ajánlást, és tudja, mikor kell felfüggeszteni az automatizált végrehajtást.

Más néven: · ember a döntési körben · emberi kontroll

14

Folyamatautomatizálás

Ismételhető folyamatlépések, szabályok vagy adatcserék megtervezett végrehajtása, egyértelmű kivételkezelési és kontrollviselkedéssel.

Miért fontos ez az üzletnek?

Az elkerülhető munkát úgy csökkenti, hogy közben nem rejti el a felelősséget és nem gyorsít fel egy hibás folyamatot.

Példa

A munkafolyamat automatikusan továbbítja a szabványos eseteket, miközben a meghatározott kivételeknél megőrzi az emberi döntési jogkört.

Más néven: · munkafolyamat-automatizálás · üzleti folyamatok automatizálása

15

Üzemeltetési modell

Azok a felelősségek, döntési jogok, folyamatok, képességek és mérőszámok, amelyek révén egy rendszert működtetnek és továbbfejlesztenek.

Miért fontos ez az üzletnek?

Üzemeltetési modell nélkül egy műszaki képességnek nincs tartós felelőse, sem kialakult válasza a változásra és a hibákra.

Példa

Egy adatterületi modell meghatározza, ki dönt a jelentésről, ki felügyeli a kontrollokat, és ki finanszírozza a hibák kijavítását.

Más néven: · működési modell · szolgáltatási üzemeltetési modell

16

Műszaki adósság

Korábbi műszaki döntésekből eredő jelenlegi korlát, amely növeli egy hasznos változtatás költségét, kockázatát vagy átfutási idejét.

Miért fontos ez az üzletnek?

Az adósság akkor válik működőképessé, ha az üzleti döntéshez vagy a változtatási pályához kapcsolódik, és nem csak rossz kódként szerepel.

Példa

Egy közös adatbázis megakadályozza két képesség egymástól független kiadását, és növeli a migráció kockázatát.

Más néven: · architekturális adósság · mérnöki adósság

17

Rendszerkontextus

A rendszert vagy döntést körülvevő, lényeges szereplők, határok, függőségek, információk, korlátok és környezet összessége.

Miért fontos ez az üzletnek?

A kontextus határozza meg, hogy egy helyi tervezési minta érvényes marad-e a valós szervezetbe illesztve.

Példa

Egy automatizálási terv tartalmazza a csapatokat, a jóváhagyási jogkört, a forrásrendszereket és a munkafolyamat kivételkezelési útvonalait.

Más néven: · kontextustérkép · rendszerhatár

18

Döntési feljegyzés

Rövid, tartós feljegyzés egy jelentős döntésről, annak kontextusáról, lehetőségeiről, indoklásáról, következményeiről és felülvizsgálati feltételéről.

Miért fontos ez az üzletnek?

Megőrzi, miért született az adott választás, így a későbbi változtatás a megfelelő feltételezéseket vizsgálhatja felül a teljes feltárás megismétlése helyett.

Példa

A feljegyzés megmagyarázza, miért választottak aszinkron adatcserét, és milyen mennyiségi, késleltetési vagy kontrollváltozás teszi szükségessé a felülvizsgálatot.

Más néven: · ADR · architektúradöntési feljegyzés

MTera · Kapcsolat az MTera-val

Rendszerkihívás megbeszélése

Építse meg a következőt úgy, hogy közben megőrzi mindazt, aminek igaznak kell maradnia.

Rendszerkihívás megbeszélése
MTera · Keresés

Keresés az MTera tudásbázisában

Keressen szolgáltatásokat, kihívásokat, módszereket, elemzéseket és fogalmakat.