December, 2023

now browsing by month

 

Posted by: | on December 18, 2023

Enterprise Architecture – goals and scope of analysis and modeling

Enter­prise Archi­tec­ture – goals and scope of ana­lyzes and mod­el­ing­Pur­pose and bene­fit­sThe primary goal of ana­lyz­ing and mod­el­ing the entire com­pany, at a pre­de­ter­mined level of detail (or rather the level of gen­er­al­ity), is to determ­ine the con­text for spe­cif­ic loc­al, domain-spe­cif­ic pro­jects. The whole mod­el con­tains inform­a­tion about the doc­u­ment flow and the IT sys­tems sup­port­ing it. The key bene­fit of hav­ing a doc­u­mented Enter­prise Archi­tec­ture is an even sev­er­al-fold reduc­tion in the costs of ongo­ing man­age­ment and devel­op­ment of the IT sys­tem, The key bene­fit of hav­ing a doc­u­mented Enter­prise Archi­tec­ture is even a sev­er­al-fold reduc­tion in the costs of cur­rent com­pany man­age­ment and the costs of IT sys­tem devel­op­ment. Giv­en mod­els we have:possibility to make organ­iz­a­tion­al decisions imme­di­ately and without risk: doc­u­mented inform­a­tion about mech­an­ism of the oper­a­tion of each busi­ness ser­vice (busi­ness pro­cesses), means the abil­ity to per­form imme­di­ate ana­lys­is the impact of each such decision on the rest of the com­panythe abil­ity to imme­di­ately make decisions about intro­du­cing neces­sary changes to the IT sys­tem, doc­u­mented inform­a­tion about the oper­a­tion mech­an­ism and archi­tec­ture of the IT sys­tem, allows for imme­di­ate imple­ment­a­tion of the specification​“to-be” of this sys­tem, and send it to sup­pli­ers as a require­ment (no need to do any pre-imple­ment­a­tion analyses),possibility of imple­ment­ing busi­ness con­tinu­ity management,possibility of imple­ment­ing a con­trolling and activ­ity-based cost man­age­ment sys­tem (ABC meth­od of cost man­age­ment). See also Tar­get oper­at­ing mod­el (TOM).

Source: Enter­prise Archi­tec­ture – goals and scope of ana­lyzes and mod­el­ing – Jarosław Żeliński IT-Consulting

Posted in Models and architecture | No Comments »

Posted by: | on December 9, 2023

What is the difference between the requirements of the solution and the needs of the user?

Sev­en years ago (2015), I ended an art­icle about require­ments and trace­ab­il­ity with the words: So the busi­ness require­ments may be dozens. The required sys­tem ser­vices (use cases) in a large pro­ject may also be dozens. But hun­dreds or thou­sands of ?require­ments? is an expres­sion of los­ing con­trol of the pro­ject scope? Here I would like to point out that a require­ment (a sys­tem ser­vice) could be, for example, a VAT invoice pro­duced in com­pli­ance with the reg­u­la­tions. The fea­tures of this invoice (list of fields) are not sep­ar­ate require­ments, they are fea­tures (para­met­ers, attrib­utes) of a single require­ment. No fea­ture of the VAT invoice has any value on its own so it can­not be a sep­ar­ate use case, just as our require­ment can be a car but its col­our or auto­mat­ic trans­mis­sion are fea­tures of the car, it makes no sense to require ?red col­our? without expect­ing a car (and how to jus­ti­fy that this col­our sup­ports the busi­ness object­ive). The use case for a car is the jour­ney and not the inser­tion of the key into the igni­tion, because this is just one ele­ment of the scen­ario of start­ing a car journey.Source: Why is require­ments tra­cing import­ant in a pro­ject? – Jarosław Żeliński IT-Con­sult­ingThere are pub­lic­a­tions about require­ments, their man­age­ment and imple­ment­a­tion. There are applic­a­tions avail­able on the mar­ket to col­lect them and man­age such a col­lec­tion. And we are con­stantly con­fron­ted with their – require­ments – ambi­gu­ity (Šen­kýř & Kroha, 2019). It turns out that their import­ance becomes cru­cial for pro­jects, also from a leg­al per­spect­ive (PZP and the concept of need defined in the recom­mend­a­tions of the Pub­lic Pro­cure­ment Office). This time I will focus on the con­cepts of «require­ment» and «need» in rela­tion to the solu­tion design.

Source: What is the dif­fer­ence between solu­tion require­ments and user needs? – Jarosław Żeliński IT-Con­sult­ing.

Posted in Models and architecture | No Comments »

Posted by: | on December 9, 2023

Work vs. design vs. intellectual property in engineering

Anoth­er dis­cus­sion I had on Linked­In recently showed that intel­lec­tu­al prop­erty law is very dif­fi­cult to assim­il­ate, mainly because – due to its «imma­ter­i­al­ity» – it escapes the intu­it­ive and mater­i­al man­ners of human per­cep­tion of the world. This is over­laid by the coder­’s con­vic­tion that, in prin­ciple, they are autonom­ous cre­at­ors, and unfor­tu­nately, many law­yers also think so. The thing is that the coder is always the cre­at­or, but not always the design­er. When the coder is not a design­er, their works (source code) are depend­ent works on primary works, which are tech­nic­al designs expressed, for example with the help of UML, math­em­at­ic­al for­mu­lae, algorithms. Then we expect coders, as developers, to do their craft brilliantly.Given that I often use pur­pose­ful and sys­tem­ic inter­pret­a­tion of con­tracts and law in the expert reports I write, I have decided to describe here an onto­lo­gic­al ana­lys­is of this area of engin­eer­ing. The aim is to determ­ine the mean­ing and range of defin­i­tions of terms com­monly used in the field of intel­lec­tu­al prop­erty. I also hope to help you with this to make bet­ter soft­ware sup­ply contracts.

Source: Cre­ation vs. design vs. intel­lec­tu­al prop­erty in engin­eer­ing – Jarosław Żeliński IT-Con­sult­ing.

Posted in Models and architecture | No Comments »