December, 2023
now browsing by month
Enterprise Architecture – goals and scope of analysis and modeling
Enterprise Architecture – goals and scope of analyzes and modelingPurpose and benefitsThe primary goal of analyzing and modeling the entire company, at a predetermined level of detail (or rather the level of generality), is to determine the context for specific local, domain-specific projects. The whole model contains information about the document flow and the IT systems supporting it. The key benefit of having a documented Enterprise Architecture is an even several-fold reduction in the costs of ongoing management and development of the IT system, The key benefit of having a documented Enterprise Architecture is even a several-fold reduction in the costs of current company management and the costs of IT system development. Given models we have:possibility to make organizational decisions immediately and without risk: documented information about mechanism of the operation of each business service (business processes), means the ability to perform immediate analysis the impact of each such decision on the rest of the companythe ability to immediately make decisions about introducing necessary changes to the IT system, documented information about the operation mechanism and architecture of the IT system, allows for immediate implementation of the specification“to-be” of this system, and send it to suppliers as a requirement (no need to do any pre-implementation analyses),possibility of implementing business continuity management,possibility of implementing a controlling and activity-based cost management system (ABC method of cost management). See also Target operating model (TOM).
Source: Enterprise Architecture – goals and scope of analyzes and modeling – Jarosław Żeliński IT-Consulting
What is the difference between the requirements of the solution and the needs of the user?
Seven years ago (2015), I ended an article about requirements and traceability with the words: So the business requirements may be dozens. The required system services (use cases) in a large project may also be dozens. But hundreds or thousands of ?requirements? is an expression of losing control of the project scope? Here I would like to point out that a requirement (a system service) could be, for example, a VAT invoice produced in compliance with the regulations. The features of this invoice (list of fields) are not separate requirements, they are features (parameters, attributes) of a single requirement. No feature of the VAT invoice has any value on its own so it cannot be a separate use case, just as our requirement can be a car but its colour or automatic transmission are features of the car, it makes no sense to require ?red colour? without expecting a car (and how to justify that this colour supports the business objective). The use case for a car is the journey and not the insertion of the key into the ignition, because this is just one element of the scenario of starting a car journey.Source: Why is requirements tracing important in a project? – Jarosław Żeliński IT-ConsultingThere are publications about requirements, their management and implementation. There are applications available on the market to collect them and manage such a collection. And we are constantly confronted with their – requirements – ambiguity (Šenkýř & Kroha, 2019). It turns out that their importance becomes crucial for projects, also from a legal perspective (PZP and the concept of need defined in the recommendations of the Public Procurement Office). This time I will focus on the concepts of ‘requirement’ and ‘need’ in relation to the solution design.
Work vs. design vs. intellectual property in engineering
Another discussion I had on LinkedIn recently showed that intellectual property law is very difficult to assimilate, mainly because – due to its ‘immateriality’ – it escapes the intuitive and material manners of human perception of the world. This is overlaid by the coder’s conviction that, in principle, they are autonomous creators, and unfortunately, many lawyers also think so. The thing is that the coder is always the creator, but not always the designer. When the coder is not a designer, their works (source code) are dependent works on primary works, which are technical designs expressed, for example with the help of UML, mathematical formulae, algorithms. Then we expect coders, as developers, to do their craft brilliantly.Given that I often use purposeful and systemic interpretation of contracts and law in the expert reports I write, I have decided to describe here an ontological analysis of this area of engineering. The aim is to determine the meaning and range of definitions of terms commonly used in the field of intellectual property. I also hope to help you with this to make better software supply contracts.
Source: Creation vs. design vs. intellectual property in engineering – Jarosław Żeliński IT-Consulting.