Skip to main content

The Story of SAP and Lidl (or others, like Deutsche Post and co.) Or How Can You Throw 500 Millions EUR Out of Your Window...


The Story of SAP and Lidl (or others, like Deutsche Post and co.) Or How Can You Throw 500 Millions EUR Out of Your Window...

I wrote this article based on following information:
- http://bit.ly/2vtNHlv
- http://bit.ly/2LHnQBg
- http://bit.ly/2AAFmCg
- http://bit.ly/2MfmABu

It is hard to believe that after so many years someone still believes to be able to migrate long running and still working system with a naive project style. We have to rethink our way to product instead of project. Moving to #SAP or any other systems means building a product and its long term product team not a project with a clear start and end point.

Introducing SAP is just the same as introducing any other standard software product. Let's take a look at introducing simple #JIRA product in your software development division. You could customize JIRA workflow as complicated as you wish but you shouldn't because you cannot upgrade it later on. If you need to change or extend the process you could write a JIRA plugin. But for this purpose you will need higher budget. This all is clear for us. So the easiest thing is not to extend or to customize anything. Just map your process to the JIRA standard workflow. I know that some people will tell you "but in our software division we have other workflow than the standard JIRA workflow...". Be strong and tell them to stay with the standard workflow. Adding fields in JIRA item is another story, it is an easy customization and can be done easily and safely.
If you are using the #cloud version of JIRA you will be pushed to stick with the standard workflow, so this is definitely the advantage of using a cloud solution. In a cloud solution you cannot damage your product with customization.

If you really need to extend with completely new process use JIRA #plugin with #Microservice architecture. Put your extensions outside JIRA (with plugins), don't mess up your installation. Here is an article I wrote in 2015 about this process: http://bit.ly/2LRI1f3
All things I explained can be mapped to #SAP, #Oracle #E-Business, #Microsoft #Navision and other standard products.

So, #CIOs and #CTOs read and learn from others. #Migration of a huge system is always hard and expensive therefore you won't do this today anymore without any justified #reasons. If your old system is just the right system for your company because it supports #individual #processes and you are not ready to give them up by using standard processes just migrate them with individual software development step by step using #Microservices and #Strangler #Pattern: http://bit.ly/2LO21Al. In this way you will be able to #reuse your #individual #processes and gradually move to the new technologies to be able to support #AI, #BigData, #PWA or whatever you name it.

At the end you have three possibilities:

1. Introduce a standard product. In this case just use the standard processes. Customize within the standard process. Do not extend which can make your product damage by customization. Using a cloud solution can help since you have to play the nice within the cloud installation, no "kaputt customization".
2. Use Microservice and Strangler Pattern to migrate your individual system into a new one which opens the possibilities to embrace new techs like #AI, #BigData, #PWA.
3. #Hybrid: mostly you will need to combine both. Be sure not to kill your standard product by customization. If you need to extend use the number 2 style above.

Before you start make the decision with your product team and ask me 😁!

Labels:

Comments

Post a Comment

Popular posts from this blog

Why "Polyglot Programming" or "Do It Yourself Programming Languages" or "Language Oriented Programming" sucks?

Last year we saw the launch of a new Web programming language Dart - Structured Web Programming from Google. A very interesting approach to support web application development. Not so long after Go, Groovy, Ruby, Scala, << name your DSL here >> ; we see Dart. Is it a good thing to have at least one programming language to solve one problem? The answer is, like we already know, it depends. Some important backgrounds you should know about the multi programming language paradigm are following: 1. You can read Martin Fowler article about language oriented programming with language workbenches which enables you to write small programming languages easily. In this article I see everyone writing their small languages, everywhere. In this concept we see DSL (Domain Specific Language) as the future of our programming activities. Source: http://martinfowler.com/articles/languageWorkbench.html 2. Neal Ford talked about Polyglot Programming, combining multiple programming language...
32 comments
Read more

Software Development Macro and Micro Process

If you think that in year 2012 all companies which produce software and IT divisions in our world have already their optimized software development process, you are wrong. It seems that we - software architects, software developers or whatever your title is - still need to optimize the software development process in many software companies and IT divisions. So what do you do if you enter a software company or IT division and you see following things: 1. There is a perfect project management process to handle all those development of software but it is a pure project management without a context to software development. So basically you only take care of cost, time, budget and quality factors. In the software development you still use the old fashioned waterfall process. 2. From the tooling point of view: you have a project management planning and controlling tool but you are still in the beginning of Wiki (almost no collaboration tool) and you don't use issues tracking sy...
20 comments
Read more

Creating Spring Bean dynamically in the Runtime

In my training someone asked me whether it is possible to create an object (a Spring Bean) dynamically so you can choose which implementation you want to have  in the runtime . So at the compile time you don't know what object actually should be created yet. The application should decide what object to be created based on a property file . 1. We create an annotation so we can mark the method which should be able to create the object dynamically: ... package your.package; ... @Retention(RetentionPolicy.RUNTIME) public @interface InjectDynamicObject { } ... 2. Use the new created annotation in your method which should be able to create the object dynamically: ... @Named("customerBo") public class CustomerBoImpl implements CustomerBo { ...     @Override   @InjectDynamicObject   public Customer getDynamicCustomer() {         return this.dynamicCustomer; } ... 3. Write an aspect with Pointcut a...
10 comments
Read more