(Created page with "As I have been working as a software developer and software architect in Sweden for the last 20 years I have seen a lot. I am not going to bore you with my historic reflection...") |
(Replacing message template with parser tag) |
||
| (10 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
<message>Write the content here to display this box</message> | |||
The printed book can be purchased on Amazon: https://www.amazon.com/MDriven-effective-business-control-information/dp/1729341098 | |||
As I have worked as a software developer and architect in Sweden for the last 20 years, I have seen a lot. I am not going to bore you with my historic reflections at all. | |||
What is the stable core? The need to store and retrieve the information we are dealing with. The need to somehow display it for users and handle users need to update it according to the rules we want to enforce. This is the technology of any application or system and is what every system developer needs to deliver – using technology | That was my first attempt at an introduction to this book. Then, I realized that most of the things we have done with MDriven are very much anchored in the historic reflections of things we have experienced previously. So I guess what I need to say is more like this: <blockquote>''Having worked many years as a software architect, I have seen a lot of things that change – but also very much that stays the same over time – a stable core.''</blockquote>'''What is the stable core?''' The need to store and retrieve the information we are dealing with. The need to somehow display it for users and handle the users' need to update it according to the rules we want to enforce. This is the technology of any application or system and is what every system developer needs to deliver – using modern technology at the time of implementation. I will refer to this as <u>'''system modernity'''</u>. | ||
Furthermore we | Furthermore, we need to understand the business information in the system and how the rules that govern the information’s evolution and consistency protection work. This part I will refer to as the <u>'''system gist'''</u>. | ||
On the other hand we all know that | On the other hand, we all know that to make our software sell – to an external market or in-house users - it must be perceived as modern and cool - but in the software business, modern and cool change every year or so, at least on the surface. | ||
Thus, mixing the system gist down into a currently modern format that will be obsolete in a couple of years seems to be something one should avoid. | |||
It would be better if the system gist somehow | It would be better if the system gist could somehow be separated from the current modern implementation strategy – which we know will be less modern as time goes by. | ||
This book | This book contains my suggestions for how we deal with system gist and system modernity. | ||
<span class="col-orange">The MDriven Book</span> - '''Next Chapter:''' [[Praise to UML]] | |||
[[Category:The MDriven Book]] | |||
Latest revision as of 08:02, 17 June 2024
The printed book can be purchased on Amazon: https://www.amazon.com/MDriven-effective-business-control-information/dp/1729341098
As I have worked as a software developer and architect in Sweden for the last 20 years, I have seen a lot. I am not going to bore you with my historic reflections at all.
That was my first attempt at an introduction to this book. Then, I realized that most of the things we have done with MDriven are very much anchored in the historic reflections of things we have experienced previously. So I guess what I need to say is more like this:
Having worked many years as a software architect, I have seen a lot of things that change – but also very much that stays the same over time – a stable core.
What is the stable core? The need to store and retrieve the information we are dealing with. The need to somehow display it for users and handle the users' need to update it according to the rules we want to enforce. This is the technology of any application or system and is what every system developer needs to deliver – using modern technology at the time of implementation. I will refer to this as system modernity.
Furthermore, we need to understand the business information in the system and how the rules that govern the information’s evolution and consistency protection work. This part I will refer to as the system gist.
On the other hand, we all know that to make our software sell – to an external market or in-house users - it must be perceived as modern and cool - but in the software business, modern and cool change every year or so, at least on the surface.
Thus, mixing the system gist down into a currently modern format that will be obsolete in a couple of years seems to be something one should avoid.
It would be better if the system gist could somehow be separated from the current modern implementation strategy – which we know will be less modern as time goes by.
This book contains my suggestions for how we deal with system gist and system modernity.
The MDriven Book - Next Chapter: Praise to UML