OK, very good.
So that was pattern recognition when you're finding patterns in the actual model you're building up
during the workshop or after we had documented it.
Now we're going to talk about conceptual patterns, and that's more generic patterns that you can have
in your --, in your tools.
And then you bring in to the workshops and utilize during the workshop or during the documentation phase.
And it's a very powerful tool and actually sometimes even too powerful.
I would talk to you.
Why that?
So patterns are used to document the solution or recurring design problems, and it is then contextualized
and used in a specific problem context.
So pattern is a general description here.
And once you know about the pattern, you know how it is described, then you can utilize that in a
concrete situation when you are building your specific model.
So design patterns was actually invented in the housebuilding domain by house building architect called
Christophe Alexander in 1979.
And it was actually then introduced in the software business development industry as late as in the
mid 90s.
But then it kind of took off very fast.
So it came I think the first pattern started to emerge around ninety five, 96, 97 maybe.
And then they became very, very popular around that time.
And everybody now if you're a software developer, you probably already know dozens of patterns like
proxy and strategy and so on.
Flyweight,
if you're only working with business modeling or actually not done any type of modeling before, then
you might not know exactly what it is.
So I will walk through here an example of a very typical pattern and I will show you how they usually
are described if you buy a book about patterns and so on.
And then in the coming lectures, I will also introduce some specific patterns I won't go through and
all the patterns in the world because there are so many.
And but my idea here is that you should learn how to use patterns and a little bit about what type patterns
there exist and not to fall into the traps, but also try to utilize its power.
And then you need to look at all the patterns you read about patterns yourself.
But so an example, and I've shown you this example maybe a couple of times already, and maybe this
is if you're working in a business to business modeling domain, this is probably the most common pattern
you will get in, you will bump into.
So the contract, so you have a contract and a contract is regular, you can use one of many products
and a contract is connected to a party class in two different ways, at least.
So we have one or many clients and one of many suppliers.
And each party could be involved in multiple contracts.
And you can be clients and some contracts and suppliers and other contracts.
So that's the most generic form of what it is to be a contract and how contract, party and product
are related.
And that could be implied in many, many situations.
So here's three examples.
Flight ticket is the type of contract right where you have it for a specific flight, which is the product
and you have a good party.
Who's in the role of a passenger?
I have other parties which are the airline companies.
OK, you have a credit agreement regarding the product of a leasing where the priority is disposal customer.
And you have the Lazaro's actually lending you the money and you have a license agreement regarding
health class license, which is the product with the parties, the facilities, buying the license.
And you have the concept developer who owns the the the license for the health class.
So Almaz are three identical structures.
You see, even if I use different terms on the concepts here and actually different terms of the rules,
the structure is identical and that's the structure of the contract pattern.
So usually when you are done modeling in a workshop and you are starting talking about something, then
you should have your council to set our patterns up in your mind.
And they you should try to start comparing what you're hearing with common patterns that arise, because
the patterns could help you ask questions.
And they could also be introduced and shown to the user to say this is something like this.
Isn't this kind of like a pattern and so on.
And if it is a pattern, what is the product really?
And so on.
So there could be very, very powerful and drive.
The whole work should forward.
However, as I should say, and I have already said it, there could be some that would be too powerful,
because if you are too inspired about all those patterns, it tend to be a overcomplicating model maybe
that you're creating or that you're introducing stuff that is not relevant in these concrete situations.
So you have to be a little bit careful.
And that's also something you have to learn by practicing this work to kind of learn to use them or
to stop using them.
But then how is the pattern described then, if you're picking up a pattern book, you start reading
about a pattern, what is to expect?
How are they usually described?
Yeah, first of all, they need to have a name.
And this example was the contract contractor here.
The name is Contract.
Right.
The the name should be short and catchy and easy to remember.
So there is a lot of good patterns, names out there, as I said, proxy strategy and so on.
They are typical patterns.
And if you know that name, then you kind of get and grasp the concept about a pattern.
Then you can have that as a shorthand saying is this like a strategy?
Should we do this as a strategy?
Then everybody that knows about the strategy pattern knows exactly what to do, or is this a typical
party pattern or is this a typical contract pattern or is this a typical thing, information pattern
where they can be like a metaphor for the real world, like, as I said, strategy or mediator and so
on.
And this example was a contract, simply put on the pattern description should also have an intent,
describing it in a little bit more general purpose way.
So, for example, contracts and agreements are a main building block in most business situations.
This pattern gives guidelines on how to model them.
OK, very good.
That's one way of describing what it is about.
They should also have an applicability applicability section.
What it describes actually, in which iteration is you generally apply this.
So use it in all situations when designing flexible business and design systems such as banks, insurance
companies, retailers, online services and many, many more.
So that's just to kind of point you in the right direction, where to start looking for a situation
where it could be applicable of using this pattern.
Then it comes to the structure.
So here you actually describes the structure of the actual solution.
Sometimes the structure is a little bit larger than you're using.
So if I'm having a contract related to products and here I actually have an association that contracts
could have subcontracts as well, and also saying they usually would like to have a contract tied maybe
as a power type to be able to reason about them before I actually have some contracts.
So maybe that's the complete structure.
But I'm not I doesn't I don't have to use the complete structure when I'm applying.
Then after that, the different participants in that structure needs to be described.
So I need to describe what a contract is.
So the main participant in the pattern is the contract that regulates the specific usage of the product.
In one unique usage of it, contracts could refer to other contracts such as subframe agreement and
drawn down deals.
Yeah, so that's the relation between contracts.
The party represents the involved legal entities in the contract, such as a person, government or
a company.
The partner plays a specific role in the context of a specific contract.
Right contract type.
There are many different types of contracts that behave in different ways, such as frame agreements
and higher purchase agreements.
And lastly, product is the item being agreed upon between the involved parties.
OK, very good.
So there are I've described the structure first and then I describe the involved participants in the
structure.
Then I need to describe the kind of pros and cons, well, the consequences of using this pattern,
because this is the way generically when it comes to all types of of the mechanisms that you're using
for building a model, they both have pros and cons.
There's no such way as a silver bullet where we can combine everything and everything just got better.
So describes how it solves the solution, but also the trade offs that you need to make here.
So by separating the parties and product with a contract concept, it makes it easier to handle general
product level terms and specific contract level terms, as well as changing terms or contracts.
However, introducing the pattern could lead to complicated structure, to a too complicated structure
were not needed.
So here we are saying that the pros are that we're getting flexibility and to be able to handle generic
terms separately for contract terms.
But we also introducing a concept that might not be something that they're using in the business at
this moment.
We're actually separating the product from the contract.
I don't think that that is a big problem just in this case.
But you see the point here that you have both pros and cons for using a pattern and then you need to
show some examples.
So already shown you three examples of the contracts are when you're describing a pattern, then you
probably also then show a couple of examples how it could be applied.
So here's the credit agreement with the leasing and the party.
Here's the ad service agreement regarding a service search network, ad service and the user and the
search engine and so on.
So those are kind of two different examples of how to apply the pattern, and then you also have to
show the pattern is usually contextualized in a larger set of other patterns.
So here we focused about the contract pattern.
But there is also a pattern that is actually called the party pattern, where we describe how you can
organize a party and structure parties generically without talking about the contextual context that
they could be part of.
And there's also actually another pattern called product, which is used to deal with product complexity.
And there could be another pattern called business event history, which handles events that happens
to a contract and so on.
So you need to put the pattern in the context of other patterns as well, because you're usually dealing
dealing with a system of patterns that relate to each other in one or another way.
And then lastly, and maybe and of course, very importantly, who actually found out about this pattern?
Who may who kind of discovered a pattern, described it the first time.
So the contract pattern is something described by someone called Monifa or Fowler is great software
architect, leading figure and software development.
And he's also writing books about business development.
That is very good.
And he wrote a book called Analysis Patterns a long time ago.
And the way he described the contract pattern, other presidents have also described the contract pattern
or tweaks to it as to other suites.
Actually, among the spanker enhanced Erick Erickson and their other great book called My Business Modeling
with UML.
And there are other books as well and sites out that are describing the contract pattern and different
various ways.
So that's usually the the different sections that you describe, patterning from the name to the source
and the credit, including the structure and the participants and the intent and consequences and so
on, to summarize them patterns.
So patterns are used to document the solution of a recurring design problem.
OK, and there are very, very valuable tool to have in your toolkit when you're doing conceptual modeling.
And actually the more patterns you know, the better it is.
I would say the more powerful you will be as a facilitator of the workshop and trying to resolve problems
that arise during the workshop.
And but sometimes they actually can be too valuable.
And at least I think this is a risk in the beginning when you start learning about patterns because
you will have these aha moments.
We think that this is so great.
I can model everything now.
The problem is that it's the business experts that needs to tell you you should only use and apply the
patterns if they make sense for them.
Right.
So it is very easy to start over, use patterns and making model overcomplicated when they're not needed,
which also maybe results in overcomplicated databases later on if you're trying to do this.
I do support system for this and so on and so on.
So keep it simple but powerful.
So some useful patterns to look up.
Maybe I'll just list them here and then you have to look at them yourself and you can probably find
out a lot of information on the net if you search on this.
So, for example, pancakes on the two suites and or business monolingualism book and they describe
active role, business definition, business event, result, history, contract corruption, Tatian
document employment, geographical location, organization and party product data management thing information,
the title item type object value.
And Martin Fowler in his book is describing accountability post account transactions, options, order,
money, product inventory, quantity and there's yeah.
Numbers of other people.
Then Silverstone is another one that is working more on database patterns, but they are often very
generic and logical, so you can use them on a business level as well.
He's also describing invoice, for example, and party as well.
So start reading and looking at patterns.
That's a very powerful tool to use.
Very good.
So the next couple of lectures is actually going to be some pattern examples.
I'm going to rush into some concrete patterns and how you can use them in different scenarios for using
them in in workshops.
And when you document good workshops, good.