- Published on
The ambiguity of application
- Authors
- Name
- Damian Płaza
- @raimeyuu
A pile
Imagine that we got asked to help in the company that provides training services in the woodworking industry.
Most of their processes are still paper based and our job is going to be to help them to digitize their processes.
We got paired with a guy named Tommy, who is responsible for processing enrollment requests.
When we enter the room, we see a pile of papers on his desk.
Then we engage in the discussion.
Enrollment, participant lists, customer loyality
Well, that was a nice discussion, wasn't it?
Turns out that Tommy is a very experienced guy. He posseses a lot of knowledge about the company's rules and policies on various topics, when it comes to the process of enrollment.
We could say he would be our subject expert, as he knows a lot about this business.
Btw. would you like to see his office?
Nothing fancy, one might say. But it's not about the office, it's about the knowledge that is kept in Tommy's head.
(btw. the office itself might work as a nice metaphor too - if you're interested, please check "Microoffices" vs "Officeolith")
As he stated, he applies all the knowledge - rules, policies and so on - to build participant lists.
Let's imagine we asked him to explain at least some rules he applies.
It sounded a little bit easier than that, isn't it?
The more we interviewed Tommy, the more we realized that the process of enrollment is not that simple.
Interestingly, he also mentioned that we should have a chat with Jim.
Jim is building the portfolio of courses but does not much about organizing trainers and course faciliators.
This comes from Kathy, who's responsible for organizing woodworking experts.
Our job is to build a system, an application or applications, that will help them to manage their processes.
But let's start from the beginning.
What does it all mean?
You might wonder, dear Reader, what the hell we just went through.
Ok, absolute basics.
You might already know dear Reader that I like start with the definitions, just to see the roots of things.
As our main goal is to create an application for our fellow training company, let's see what the word "application" means.
an act of applying; an act of putting something to use
All those words...
Definitions (by their definition) are created to serve as generic, context-free explanations.
And we all know that the context is so the king, right?
Even though in the domain of IT, the word "application" is used to describe a software system, it's still a bit ambiguous.
As we interviewed Tommy, we realized that the word "application" might mean something different.
If one listened carefully, one might notice that Tommy applied his knowledge to build participant lists.
Day by day, he used all his experience and put it to use to manage the enrollment process, create those lists and collaborate with other experts.
Let's move for more "active" perspective of "an application", as a word.
To apply or not to apply?
Our next step is to get a verb - "to apply" and see what it means.
to put into operation or effect; to put to use especially for some practical purpose
It adds up too - the knowledge Tommy has is put into operation and is used in a practical sense.
As he is an enrollment process expert, he applies his know-how all the time.
We are engineers, architects - how would we apply this knowledge? (pun intended).
We could take the process of enrollment and analyze it from more "abstract" perspective.
There are two interacting parties - a customer and an enrollment expert.
Each of them collaborate using documents: an enrollment request and a participant list.
But wait - does Tommy keep all the details of the requesting customer? What about details of the courses? Past enrollments?
Tommy knows a lot, that's for sure. His knowledge is applied to build participant lists - he knows how to apply discounts, how to move customers to other trainings, how to comply with the law, etc.
Application of Tommy's knowledge also includes interaction with other experts and includes using appliances, tools, and other existing documents.
Obvious thing - he is the enrollment process expert!
The ambiguity of application
So, what's the point of all this?
I hear you, dear Reader: "Damian, people exchanging documents and talking to each other, applying knowledge - what's the big deal?".
Being a non-native English speaker can be a point of insightful moments.
It blew my mind when I became aware that "an application", as a noun, comes from "to apply something" - and I asked myself - what is this "something"?
Isn't it that we are applying the representation (curated, useful models) of the knowledge (concepts/ideas, living in the given area of human/business activities) to provide a solution to a particular "use case"?!
Or in other words: aren't we trying to represent the knowledge by using various models and apply them in certain context?
As we already discussed that in The ambiguity of code, "the code" is just a vessel to express the knowledge.
Maybe I am bending and twisting the English language too much, but I think might give an interesting perspective on how we understand what we are doing in our day to day work.
Let's go further with our journey and let's make an application a central part of our considerations.
The inside and the outside
We saw before that Tommy and his knowledge application were in the center of the entire enrollment process.
His experience and knowledge make the process.
It seems very similar to Ports and Adapters architecture where application is the core of the system, isn't it?
"The outside" is there "just" to provide all required pieces for the application to provide its own capabilities and provide solutions to certain use cases.
Using models
Let's change the representation of what we explored in "to apply or not to apply?" part and let us turn all participants into boxes.
Finally, some boundaries!
There's visible "inside" - knowing when a specific provider needs to be interacted with, etc.
In the real "application" there might not be all Jims, Henrys and Tommys - we'll encounter some abstract ideas representing those roles, isn't it?
Possibly, one could bring Enrollment as a central concept, representing a process that we talk about for so long, during this tiny tale.
What about ParticipantsList? Should it be a central entity? (please note dear Reader, I try to be provocative here!)
One might get a feeling that is all about "nouns" that "live" in this area of human activities - as we listed some important concepts already.
Don't get fooled, dear Reader - an application of the knowledge representation, in the form of the model, that is centered around rules, policies, decisions, steps and so on - is the most interesting part.
Details, information - one could name it all as "data" - is important, but is it the most important? (if you are interested in this topic, please check Concepts, Entities, Data)
It wouldn't be a decent blog post if I didn't use a cliche statement: "all models are wrong, but some are useful".
I used it so now it is a decent blog post.
What's next?
"What are you, a damn philosopher?" - you might ask, dear Reader.
Well, I can't really say, but yes.
It's nice to chat about those things and explore metaphors but how can we use this possible insights in our next task or project?
Isn't that when we say "web application", we apply knowledge from "the web engineering domain" and "the representation of the business logic knowledge" to serve certain use cases?
Even though is might sound a bit impractical, changing the way we think about certain "obvious" things is crucial for personal growth - and that's actually really practical (in my mind, at least).
Next time, dear Reader, when doing a simple assignment from your backlog, or creating an architecture, ask yourself:
What knowledge do I need to apply here? How should it be represented? What are the rules that need to be modeled?