THE MDRIVEN VIDEO EXPERIENCE

Image by Vectonauta on Freepik

The MDriven video tutorials give you a front-row seat to the MDriven World. Each video seeks to explain the ins and outs of the MDriven tools and how best to use them.

With the MDriven Video Experience, MDriven aspires to:

1. Give you a starting point for your MDriven journey
2. Clarify the learning process
3. Guide you to business solutions resulting from the application of MDriven products.

We strive to improve the Wiki to help you overcome your business hurdles and realize progressive solutions.

Visit our Youtube channel here.

MDRIVEN LEARN

Purpose and Outcome
MDriven Learn is the MDriven Education program expanded and simplified to grow your experience with MDriven’s tools. As you study MDriven, the learning program will broaden your insight into why MDriven chooses to support a no-code approach to developing and building applications.

Simplified Structure
MDriven Learn is divided into specific sections. Documentation contains all pages detailing MDriven content in textual form. Training takes you on a journey to learn and explore the MDriven tools. Q & A provides a chance to talk directly with us about your experience. Model Examples have ready-made model packages you can download and start building immediately. Best Practices suggests unique ways to utilize the MDriven knowledge you have acquired.

Dual Learning
MDriven Learn is composed of both technical documentation and video learning. This dual approach gives you a well-rounded understanding, making it easy to use the MDriven tools. We are always accessible at support@MDriven.net for any queries or concerns you may have along the way.

OFFERING YOU BETTER SUPPORT

Image by pch.vector on Freepik

Restructured Team:
To offer you the best support experience, we have reorganized our team. We now have an internal MDriven Team to foresee and cater to your needs. This core team meets regularly to discuss and improve MDriven Support to enhance your experience.

Stack Overflow:
Feel free to post your questions or concerns on our Stack. Our Stack is open to all. We will process your inquiries and send you a reply within a short time.

Well-rounded Support:
Are you struggling with upgrading your IT systems? Do you have a concept and require guidance on how to implement it? MDriven specializes in both short and long-term assistance to enable you to pace yourself as you make changes. Reach out to support@MDriven.net for a customized MDriven experience that suits your particular needs. Our team will discuss and work with you on possible solutions.

AN UPDATED & IMPROVED WIKI

New Interface: Experience a fresh and vibrant look with our updated Wiki interface. We’ve organized items into a more structured format, featuring a bolder and brighter theme. The visually stimulating design aims to make your learning experience not only insightful but also relaxing and refreshing.

Left-menu Feature: Introducing a foldable left-menu to the Wiki! This handy feature allows you to seamlessly navigate and discover pages or concepts related to the content you’re currently exploring.

Easier Navigation: Say goodbye to struggles! Our revamped Wiki opens like a book, making it a breeze to find and switch between pages and topics. Enjoy a smoother and more efficient navigation experience.

Better Search Options: Finding what you need has never been easier. Our improved search functionality picks up on every letter you type, suggesting relevant destinations and ensuring a seamless exploration of our Wiki.

Revised Documentation: We’ve gone the extra mile to review and update all pages under Documentation. Combined with the new look, the MDriven Documentation now provides a solid foundation for your modeling endeavors.

We hope these enhancements make your time on our Wiki even more enjoyable and productive. Happy exploring!

MDriven hashtag on Twitter

Hans is at twitter under the handle @AtMDriven. Hashtag #MDriven and #Nocode we will communicate MDriven’s perspective on modern implementation strategies as they are communicated by the industry’s giants like Grady Booch and  Martin Fowler.

Are there others Hans should follow on twitter? Let him know at @AtMDriven.

Examples of what is said:

image

image

image

image

Please join us on Twitter!

Digitalization for CEO’s

Everyone knows that there are gains to be had by going digital. Exactly what gains and were to start is however not obvious. Advice are plenty but often risky — involving high bets on specific schemes that often enrich the company that gave you the advice in the first place. You know that you will need to do something soon — but you are not prepared to jump high and far when you know from experience that any lasting progress always comes from getting a bit better every day — and by continuing that process. Progress is never acquired — it is always gained by work.

“If you find a perfect COTS-product then you are probably not as unique as you need to be to win”

Most CEO’s has this fear of doing too little and at the same time the fear of choosing the wrong path. To manage the fear you may hire a CIO. Once the CIO is in place the fear moves to the CIO — but it does not remove the fear from the company and the core issues are not handled.

In order to understand the challenges you will be helped by dividing the company’s processes into two areas.

The first area — core business — here you need your company to compete with rivals. In this area you hire personnel that is smart, creative, solves all problems and you do not care that much about prior experience, instead you focus on ability to learn. It makes a lot of sense to ignore exact matched experience if you think that you are unique — where would they have acquired this experience from? You focus on the ability to learn and adapt — since being best is not static — it needs constant sharpening.

It is unlikely that you will find a perfect off-the-shelf information system to license for this area. I say unlikely because if you find a perfect COTS-product then you are probably not as unique as you need to be to win. And even if it is perfect today — will it evolve in the same direction as you need to in order to win tomorrow?

The second area of your business processes are the areas that you must have due to regulations or common business hygiene. The personnel you hire to operate these functions are often hired based on prior experience. Ideally there should be nothing unique in this area — your company should follow the rules and laws — but not over doing it — and never miss on a requirement. In this areas you will benefit from finding COTS products — riding on the knowledge of others on how relevant processes are upheld and streamlined.

What are typical “hygiene” areas? It varies from business to business — but it is not uncommon for manufacturing companies to see human relations, salary, travel expenses and IT-support as NOT core business functions.

Examples of core business functions for a manufacturing company can be supply, demand, goods procurement and research and development.

The core business functions may find highly specialized commercial business support systems per function to solve specific tasks. But with digitalization we aim higher — we want all the departments to share information — and we want to support new or improved ways of working with digital tools so that the talent we employ is not weighed down with mundane administration.

“A self-digitalizing company where employees make themselves more efficient as part of the daily routine”

Today this is often solved with department-owned excel spreadsheets. Spreadsheets are copied and moved around between departments and even if this constitutes information sharing it has several caveats.

  • It is a risk that one part of the organization base decision on outdated excel data.
  • It is common that departments only see part of the information and that they are less able to understand the whole picture.
  • It is not uncommon that queues build up to centrally placed spreadsheets if there are many that needs to write to it.
  • It is not uncommon that yet another copy of the spreadsheet is created to solve a need found in one part of the organization but not understood or communicated to the other parts.
  • It opens up for protectionism between departments — misplaced protection of company assets that makes work harder for your employees and thus more expensive.
  • Spreadsheets cannot have granular access rights so that you can expose from who we buy but not the price — instead we create two spreadsheets and risk that they get out of sync.
  • Every employee can create their own flavor of spreadsheet and that level of freedom does not help the company compete.
  • Spreadsheet break — and we waste time piecing them back together.

You probably can think of even more issues that arise when you rely on excel for critical business data — but the up side is that it is very flexible and the spreadsheets are owned by the business and not by the IT-department.

The fact that the business becomes independent in providing a business support system is important. If they rely on the IT department to find the best solution it would take a lot of energy and fighting spirit to actually get things usable. And since we know that our needs change — chances are that the needs change faster than the delivery speed of the IT department.

People working in IT often need to be convinced that the business need for change is real and not something we made up just to make life harder for IT — and these discussions are both time consuming, exhausting and does not create any business value.

To get a working system in place is also hard to do in one go — in excel you tweak and tweak until you do not need to tweak any more — but the IT-department often requires a complete specification and they will hold you to it; even if it is wrong in some aspect and you find this out before delivery you will still get what you asked for in the first place.

The common critique regarding Excel from information architects is that it is too brittle and does not help to build a Meta understanding of the information the business use. Excel does not require you to name data — and since there is no naming the words used to describe it is often different for everyone that comes in contact with the data.

This is not optimal — you will not know how much efficiency you lose by not having a high level Meta data understanding of your business needs until you get one so that you can compare. But I will argue that it is really important to get this understanding in place in order to see the bigger picture of information use — and once you do you will probably find many synergies and information reuse possibilities that you have not yet taken advantage of in your organization.

It is when you start to see all the data you use and start to understand the dynamics of your information — in what order data is refined and used — it is then you can say that you are on a good path to digitalization of your core processes. And once on this path — you must continue to walk it.

Walking the path of digitalization will put information technology into use a bit more each day in your business. As more and more information support is provided you lessen the burden on your employees. You will notice this as increased productivity. As you get the right digitalization up and running you will notice more consistent results and higher quality of the artifacts used by and delivered from the business.

If you do this right your most talented employees will look further and will see more possibilities. When your departments get together and own the process of getting better information management support each day — you know that you can relax a bit. If you get here you have created a self-digitalizing company where employees make themselves more efficient as part of the daily routine. That is how you want to digitalize your company. No struggle trying to force systems in from above — instead let them grow from below. This way you get acceptance from the employees and you use the very best of their talents to build systems that will help you win.

Establishing this environment is what MDriven.net does.

How can MDriven be so much more efficient than other system development tools?

It all comes down to the environment you act in and what you can expect from it. In MDriven you completely control the environment by creating the model. This means that you fully control the rules of the game. If you are fully in control you do not need to safeguard and hedge everything as much as you must if the rules are very loose, changing or unclear.

Walking into a restaurant — asking for a table you expect to be shown a table and eventually served a meal. You expect this because you assume you know the rules the place aim to follow.

System developers not using MDriven can rarely assume that they know all the rules — or that the known rules will be followed. The main reason is that developers are not trying to get just one meal — they are trying to solve all meal-buying-experiences-that-can-possibly-happen-even-if-the-very-unlikely-case-of-“put in your arbitrary real case deviation here”. What is a typical real-case-deviation you may ask? My point is that the possible real-case-deviations can never be fully known unless you fully define the rules of the world you are acting in. Is the kitchen offline? Is there enough cucumbers? Is this really a restaurant?

This is potentially why many companies find system development expensive. They mix up knowledge about what-should-be-allowed-to-happen– i.e. knowledge about the world they are acting in — with on-the-spot-problem-fixing.

As the idea of “on-the-spot-problem-fixing” is brought into system development and coding — the number of ifs-and-buts-checks in your code explodes — and yet it will only be able to handle the small subset of things we can imagine today. Since code is not documentation, at best it is obfuscated documentation, “on-the-spot-problem-fixing” actually hides important knowledge of the world your system is acting in.

The imperative mistake

This is what we define as the “imperative mistake” — believing that we should salvage things in code that are not fully defined in the rules. MDriven use a declarative approach, it does not micro manage acting — instead you define rules of what is possible and opportune.

A mental picture to compare imperative to declarative: Imagine two piles of sand — one with white and one with black sand. The piles need to be moved to another location.

One imperative description of the solution is “get the wheelbarrow from the storage (check that it has enough air in the tire), and the shovel (make sure it is clean and dry), move the white sand first — if you do the black sand first it will leave traces in the white sand you move later on — if you do it the other way around make sure you clean the wheelbarrow — and make sure it is dry. If the door is locked you can request access by asking… If you cannot get access — leave it and try later”.

The same declarative solution is “move the black and white sand — do not mix”.

Reading the example above your reaction may be that I over-simplify or cheat — describing the declarative approach as everything is a done deal. I do not cheat. It is a done deal — that is the whole point of the declarative approach. Skip all the detailed steps — just like walking into a restaurant and requesting a table. What enables you to do this is that the world rules are fully known.

The declarative solution only states intent and assumes that this will be enough — exactly as you would instruct a skilled and intelligent person in a world where all the possible outcomes are known.

The imperative approach resembles how you will instruct person without skills and with no knowledge or experience in the field, in a world where almost anything can happen. You will always be in fear that you have not explained the possible deviations thoroughly enough. Combine this with a team member with Asperger tendencies and you will see your costs skyrocket.

The imperative example has implemented domain knowledge of the fact that black grains are visible in white sand in code (instructions) — not in the documentation of the world it is acting in (the rules).

The declarative example assumes that the world rule-set knows about preferable order or cleaning procedures to move sand. Hence it does not need to hedge or safeguard. It assumes it is dealing with an absolute specialist in the field in an absolute known environment.

One common objection to this explanation is this: “you said: It assumes it is dealing with an absolute specialist in the field. But what if it is not a specialist?”

I love that objection because this goes to the heart of the matter. Let us assume that the declarative world turns out to be really bad at doing the job we ask of it; it mixes the sand. Great find! We have found an issue with the known-world that needs fixing — we solve this problem by evolving the rules of the world — i.e. increasing the knowledge about the world we act in. We amend the rules until the simple instruction of “move the sand” works. This may involve the collecting of additional information into our world — information that must be maintained somehow — maybe by a user — the complexity of our world may increase — but so does the knowledge and hence the instructions within that world can be held simple.

The imperative approach hides important knowledge in code (instructions) — it limits your ability to understand the world you act it.

MDriven — embrace the standards and create real value

MDriven make use of the standard UML to define static information rules (classes, attributes, associations) and dynamic information rules (state-machines). MDriven also use the OCL standard to further define constraints beyond what is defined with associations and types.

As MDriven use the functional OCL language code volume (instructions) shrink dramatically — it promotes declarative thinking — it moves important insight into model (world rules) instead of code — it removes all the non-world-defined-degrees-of-freedom and makes developers much more focused on the documented rules that in turn bring real business insights to your attention.

With MDriven you do not only have a tool to solve your immediate information needs — but a tool to learn, understand, streamline, develop, innovate and grow your business.

That is how MDriven is so much more efficient than other system development tools.

Describing your world declaratively also makes it timeless — not interwoven with aging modernity of today. But that is another story.