Business Rules Come First

äskettäin keskustelimme kollegoiden kanssa erään suuren asiakasorganisaation pääohjelmiston kehittäjän kanssa siitä, miten siellä on edistytty merkittävässä uudelleensuunnittelussa. Olimme huolissamme siitä, pystyisivätkö projektiryhmän jäsenet täyttämään noin yhdeksän kuukauden määräajan suuren mittakaavan prototyypin toimittamiselle. Olimme juuri käyttäneet useita intensiivisiä kuukausia kattavan liiketoimintamallin kehittämiseen,ja heillä oli vielä useita kuukausia järjestelmän suunnittelua jäljellä.

tämä pääkehittäjä on hyvin terävä—ei sellainen, joka sitoutuisi mihinkään vastaukseen kevyesti. Pisimpään hän ei sanonut mitään, ajatuksissaan. Lopuksi, silmäillen yksityiskohtaisia liiketoimintakaaviot rapattu seinillä ympäri, hän sanoi, ” Jos olisimme jo alkaneet koodaus, sanoisin, että meillä ei ollut mitään mahdollisuuksia. Mutta koska emme ole vielä aloittaneet koodaamista, sanoisin, että mahdollisuudet ovat melko hyvät.”

jouduin juoksemaan sen monta kertaa mielessäni ennen kuin tajusin hänen merkityksensä. “Jos olisimme jo aloittaneet koodaamisen, sanoisin, ettei meillä ollut mitään mahdollisuuksia.”

tiesin hänen ajattelevan, että itse sovelluksen koodaaminen tulee olemaan aika rankkaa. Se vaatisi sääntömoottorin, maailmanlaajuisen jakeluverkon, graafisten käyttöliittymien ja joidenkin merkittävien väliohjelmistojen käyttöä.

hän sanoi, että jos heidän pitäisi ratkaista kaikki bisnesasiat koodauksen aikana, he eivät koskaan onnistuisi siinä ajoissa—tai luultavasti koskaan. Kuitenkin, koska projektitiimi oli käsitellä vaikeita liiketoiminnan kysymyksiä etukäteen (mukaan lukien tarkentamalla liiketoiminnan säännöt), hän ajatteli heillä oli melko hyvät mahdollisuudet täydentää koodi tavoitepäivämäärään mennessä.

suuressa mitassa liikesääntö on yksinkertaisesti oikeiden kysymysten esittämistä oikeilta ihmisiltä. On vain yksi tapa rehellisesti täyttää määräaika-ja se on ratkaista liiketoiminnan ongelma ensin.

Yritysvetoinen IT

liike-elämän järjestelmien rakentamisen alkuaikoina bisnespuoli saattoi lähinnä istua ja vain antaa niiden tapahtua. Automatisoinnin edut olivat niin vakuuttavia, ettei siinä voinut tehdä käytännössä mitään väärää. Liike-elämä ja se toimivat nyt erottamattomasti kaikissa käytännön tarkoituksissa. Hankkeiden toteuttamisessa looginen askel olisi koota saumattomat business / IT-projektitiimit ja saada ne noudattamaan liiketoimintalähtöistä lähestymistapaa vaatimusten kehittämiseen. Silti monet yritykset eivät ole lähelläkään sitä tänä päivänä.

aivan liian usein bisnespuoli tuottaa edelleen sumeita, huonosti keskittyneitä “vaatimuksia”, ja IT-puoli jatkaa” vaatimusten ” tekemistä vain pykälän tai kaksi ohjelmointia ylempänä. Miten tämä ero liike-elämän ja IT-alan ammattilaisten välillä vaatimusten kehittämisessä voidaan poistaa?

vastaus on suhteellisen suoraviivainen. Liiketoiminta tarvitsee organisoidun lähestymistavan, jonka avulla liiketoiminnan ammattilaiset voivat ajaa vaatimusten kehittämistä. Tämän lähestymistavan on tarjottava tiekartta, joka osoittaa, miten oikeanlaisia kysymyksiä oikeista asioista voidaan esittää oikeina aikoina. Tarvitaan yrityslähtöistä otetta.

perinteisissä kehitysmenetelmissä upfront-vaatimusten kääntämisessä varsinaiseen juoksujärjestelmään yleensä menetetään paljon. Mutta selkeiden liiketoimintasääntöjen kirjoittaminen parantaa viestintää liiketoimintapuolen ja IT: n välillä ja luo sillan liiketoiminta-analyysin ja järjestelmäsuunnittelun välille. Business rule-lähestymistapa auttaa kaventamaan liiketoimintapuolen ja IT-puolen välistä vaatimuskuilua.

joten mikä on liikesääntö? Liiketoiminnan näkökulmasta se on direktiivi, jonka tarkoituksena on vaikuttaa tai ohjata käyttäytymistä. Liiketoimintasäännöt ovat kirjaimellisesti koodattua tietoa liiketoimintakäytännöistäsi. IT: n näkökulmasta bisnessääntö on ydinpala uudelleenkäytettävää bisneslogiikkaa.

tavallaan jokainen tietää, mitä liiketoiminnan säännöt ovat-ne ohjaavat yritystäsi päivittäisessä toiminnassaan. Ilman bisnessääntöjä päätökset pitäisi aina tehdä lennossa ja valita vaihtoehtojen välillä tapauskohtaisesti. Se olisi hyvin hidasta.

säännöt ovat tuttuja meille kaikille tosielämässä. Pelaamme sääntöjen mukaan, elämme sääntöihin perustuvan oikeusjärjestelmän alaisuudessa ja asetamme sääntöjä lapsillemme. Silti ajatus liikejärjestelmien säännöistä on ironisesti vieras useimmille IT-ammattilaisille. Sano “säännöt” ja monet IT-ammattilaiset ajattelevat epämääräisesti asiantuntijajärjestelmiä tai tekoälyä. On vain vähän tunnustusta siitä, miten keskeiset säännöt oikeastaan ovat liiketoiminnan perustoiminnalle.

ei ole sattumaa, että monet liike-elämän työntekijät ja johtajat ovat niin hyvin indoktrinoituneet vaatimusten kehittämistä koskeviin menettelyllisiin näkemyksiin, että sääntöihin perustuva ajattelu saattaa tuntua vieraalta tai abstraktilta. Käytännössä kaikki menetelmät ovat syyllisiä tässä suhteessa, oli kyse sitten liiketoimintaprosessien uudelleensuunnittelusta, järjestelmäkehityksestä tai ohjelmistosuunnittelusta.

tämä on valitettavaa kahdesta syystä:

1. Kaikenlaisen organisoidun toiminnan miettiminen sääntöjen kannalta on itse asiassa hyvin luonnollista. Kuvittele esimerkiksi yrittäväsi selittää peliä, kuten shakkia, tammea, baseballia tai jalkapalloa, selittämättä sääntöjä.

2. Yrityspuolen työntekijöillä ja johtajilla on osaamista, jota tarvitaan hyvien sääntöjen luomiseen.

Otantasäännöt

Tutustu noudatettaviin otantasääntöihin ja huomaa, miten liiketoimintajärjestelmän operatiiviseen valvontaan liittyviä näkökohtia voidaan käsitellä säännöillä:

• rajoitukset: asiakas ei saa veloittaa luottotililtään enempää kuin kolme pikatilausta.

* heuristiikka: Asiakkaan, jolla on ensisijainen asema, tulee täyttää tilauksensa välittömästi.

* laskelmat: asiakkaan vuotuinen tilausmäärä on laskettava kokonaismyyntinä, joka on päättynyt yhtiön tilikauden aikana.

* päättely: asiakasta on pidettävä parempana, jos asiakas sijoittaa yli viisi tilausta yli 1 000 dollarin.

* ajoitus: asiakas on arkistoitava, jos hän ei tee tilauksia 36 peräkkäiseen kuukauteen.

säännöt perustuvat suoraan ehtoihin ja faktoihin. Termeillä-kuten asiakkaalla, lähetyksellä ja laskulla—pitäisi olla liiketoiminnassa tarkka, yksiselitteinen määritelmä. Asiakas voidaan määritellä esimerkiksi seuraavasti: “organisaatio tai yksittäinen henkilö, joka on tehnyt vähintään yhden maksullisen tilauksen kahden edellisen vuoden aikana.”

faktat annetaan yksinkertaisilla, deklaratiivisilla lauseilla, jotka yhdistävät termit verbin tai verbin lauseeseen, kuten ” Asiakas tilaa.”

“faktamalli” on joukko faktalausuntoja, jotka kuvaavat yritystoiminnan tuloksia. Faktamallin pitäisi toimia tietomallin alkuperäisenä pohjapiirustuksena, mutta sen ensisijainen tarkoitus on kaapata tietoa liiketoiminnasta jäsennellyssä muodossa, joka on tislattu yrityspuolen työntekijöistä ja johtajista, jotka omistavat sen.

säännöt lisäävät lähinnä sanojen “täytyy tai ei saa” merkityksen ehtoihin ja faktoihin, kuten ” tilauksia yli 1000 dollarin luotolla ei saa hyväksyä ilman luottotarkastusta.”

säännöt tulee ilmaista selkeällä, yksiselitteisellä, hyvin jäsennellyllä bisnesenglannilla alkaen eksplisiittisestä aiheesta. Säännöissä ei pitäisi olla pöyhkeitä eikä puuttuvia faktoja. Sääntöjä voidaan pätevöittää, kuten ” lähetys on vakuutettava, jos lähetyksen arvo on suurempi kuin 500 dollaria.”Ja säännöt voivat sisältää ajoituskriteerit, kuten” opiskelijan on oltava kirjoilla vähintään kahdella kurssilla rekisteröitymisen päättymiseen mennessä.”

Sääntömääräinen itsenäisyys

liike on hyvin paljon kuin ihmiskeho. Tieto (termi ja tosiasia) rakenne on kuin luuranko; prosessit ovat voimakkaita lihaksia; ja säännöt ovat hermosto, joka ohjaa kahta muuta. Kaikki kolme ovat olennaisia ja liittyvät toisiinsa. Mutta liiketoiminnan sääntöjen pitäisi olla erillään kahdesta muusta. Tämän lähestymistavan perusperiaate on, että säännöt ovat riippumattomia prosesseista ja menettelyistä. Tämän “sääntöomavaraisuuden” luontoisetu on valtava yksinkertaistus prosesseissa.

tuloksena on “ohut prosessi”, monien IT-ammattilaisten pitkäaikainen tavoite. Ottamalla säännöt pois prosesseista voit tuottaa prosesseja, jotka ovat suhteellisen yksinkertaisia ja joita voidaan muuttaa tarpeen mukaan.

jos pelintekijä ei toimi joukkueelle, se poistuu pelikirjastaan parissa ottelussa. Näytelmät ovat pohjimmiltaan heittäytymisiä. Samoin yritysten on pidettävä omia menettelyjään heittoistuimina-niin halpoina, että ne voidaan hävittää ja korvata helposti, kun menettelyt eivät enää toimi hyvin.

Kertakäyttöiset menettelyt ovat välttämättömiä, jotta yritys voi olla mukautuva ja kilpailukykyinen. Tämä petollisen yksinkertainen ajatus-jonka liiketoimintasääntöjen lähestymistapa mahdollistaa-voi mullistaa työn tekemisen ja järjestelmien suunnittelun.

uusintapainos Ronald G. Rossin luvalla Principles of the Business Rule Approach (Addison-Wesley, 2003). Ross on Business Rule Solutions LLC: n perustaja ja rehtori sekä verkkosivuston vastaava päätoimittaja BRCommunity.com.

kirjaston Faktamalli
tämä kaavio näyttää graafisen faktamallin kirjastolle. Säännön sanamuoto perustuu suoraan faktamalliin, joka on kaavio liiketoiminnan peruskäsitteistä – tietorakenteesta. Faktamalli voi ja sen pitäisi tarjota ensimmäinen leikkaus suunnitelma siitä, miten tiedot lopulta järjestetään tietokantaan. SÄÄNTÖ: Kirjastokortilla voi tarkistaa kirjan vain, jos kirja on sellaisen kirjaston omistuksessa, johon kortilla on lupa.