OK, so in this lecture, I'm going to talk what I call the generic specific sweet spot, and it's also
a little bit related to what I just talked about, process models and conceptional and how they are
related and that they show different, very different things, but they are interlinked.
So the thing here is that when you're doing your model, are you creating this generic model that can
work in all possible situations, or are you trying creating a very specific tool that is describing
a very specific use of language?
And sometimes you have a hard time finding that sweet, sweet spot because it could be good to make
the model a little bit more generic so it could, like, be flexible for the future.
But if it becomes too flexible, then it will be so general.
So it doesn't actually say a bit about you, but about your business situation or other situation.
And this is generally what is thought about as modify your ability of a system.
So that is the term you're using within software development, but also generically system development.
When you talk about a quality that a system could had all the time to say how resilient it is for change,
how easy it is to actually modify it, to actually include other aspects as well, and generally thought
of that a system should have.
It's good for a system to have quite a good modify ability, but it could also be too generic.
So modifying built is defined in a standard and we define the modified ability of a software system
as the ease with which it can be modified to changes in the environment requirements or functional specification.
A little bit technical here, but I think you see the point.
So how easy is it in the future to add new stuff to this model without changing the whole structure
of it?
So the less changes needed in the model to accomplish as many external changes as possible, the more
modifiable the model is or the system is.
That sounds great, right?
So then I would like to have the most modifiable system, a model or the most modifiable model in the
world.
OK, very good.
Our concept model should never have to change, but that will look something like this.
They will be up on the most abstract level, which is more like the philosophical level.
So you're saying that a concept have attributes and or properties even, and a concept could have relationship
between different concepts and a concept could be instantiated in objects and objects, could have links
between each other, which are instances of the relationships?
Fine here.
And we have our concept model here.
We can describe everything OK?
True.
However, you doesn't say a bit.
It doesn't say a bit about your concrete specific situation or your concrete product or business.
So that is not maybe what you like to have either.
So if no one will gain any knowledge from it, then it's not a good model.
But let's take a concrete example again.
So I'd like to work with examples.
You might have noticed that already.
So let's say that we have an example of a process.
Moldova's start developed for a business situation and we are asked to start in conjunction with that,
create a key concept model that is also used in this work.
And to understand it more so let's say that we have a customer, a salesperson and a delivery manager
here, and the customer sends an inquiry, the salesperson gives an offer as an answer to that inquiry,
and then the customer decides what to do and might place an order.
And the she and then the salesperson activates the accomplishment of the service, which is sent over
to delivery man and delivery manager that does the rest of the work.
Maybe, however, the customer can also give a counter bid and that will then go back to the salesperson
who's giving a counteroffer maybe.
And then they could go on in that loop and either they are closing it down or not doing a deal or they
eventually decide to to go on and place an order.
So let's say this is a very common starting of a business process, a very common pattern process patent.
But from a key concept perspective here, I would like to know who is the customer?
What's what is the customer?
What is the salesperson?
What is the delivery manager?
What is an offer?
What is an inquiry?
What is a counter bid?
What is an order?
What is an accomplishment?
What is it to give send, please, and activate what is offered?
By whom, accomplishment of what?
And so on and so on.
So first interpretation of this could be that we are saying that we have a customer who gives an inquiry.
This is the first interpretation of the concept model.
So we have a customer in place, an inquiry to a salesperson who gives it to a delivery manager to and
activates the accomplishment.
The customer gives an order.
We have an offer that is sent from a salesperson to a customer and we might have a counter bid.
OK, very good.
We have captured the key things here, but it's becoming a little bit like a spider web, so to speak.
So maybe if you start doing this and have that very simple conceptual structure from that process model,
you will have eventually a conceptual model that looks like a complete spider web is almost impossible
to change or have any flexibility in it.
So there are a lot of pros maybe with this because it's simple and it's quite easy to understand, but
there are also a lot of consequences for it.
So second interpretation would instead be to say that we have an agreement actually that we're trying
to agree upon here and we have an order or offer and counter bid, which all our statements on that
final agreement, an agreement about a service that we would like to be delivered.
And we have different roles towards that agreement.
We have the producer, which is a party, and we have a customer, which is the party, and they the
service they need to be accomplished by a party.
We have an inquiry that is sent in from a role that we call the customer as well.
And we could have a salesperson is responsible for the agreement, and that's an officer and an officer
is another role.
Sorry.
An accomplishment is also done by officer and then they're called on the delivery manager.
So here we see that we have another way of doing the same conceptual apparatus at the same conceptual
domain could be expressed in another way without actually affecting the process model that stays intact.
And we can actually add on just another third interpretation when we start also adding on more things
that we see underneath that we implicitly hear in that process model so that we also say that a service
is actually realized in the delivery process.
Probably we need to understand that and the accomplishment is actually an instance of such a delivery
process.
There's a lot of business events going on here between the parties and the agreements and the statements
and so on.
And for example, the accept or reactivate or receive an inquiry offering something, receiving counter
bids and so on.
Those are important events that we would like to have information about, maybe.
So here we have added yet another set of concepts that we also maybe implicitly hear when we are seeing
that process model, but they aren't shown in the process model.
So these are three very different conceptual models which could be used in conjunction with the same
process model.
And that's an important thing to understand.
So you can interpret the same story in almost infinite ways.
And you remember these Gwangi problem that we had.
And every interpretation has its pros and cons.
So they could be both making it more complex, but also make it more flexible or being too simple and
may be very hard to to grow into a larger model that is very hard to maintain and understand when it
becomes larger.
So that's a very kind of generic that's a very important sweet spot that you need to find.
So Generalisations General leads to higher modify ability by generalization could also blur out the
details.
And there's no true answers here.
Actually, you need to find your sweet spot of your model in your concrete situation.
Very good.
That was that lecture about finding your sweet spot in your model, seeing your next lecture, which
is a full scale example, action, where you're going to model yourself.