Avoid the disaster Building new Software solutions some tips Marco Molteni - @marcomolteni

Where my experience comes from 18 Years in IT consulting Working with the latest technologies in new projects I worked with … CSS Health Insurance, no 1 in CH ZKB, bank no 1 in ZH SBB, biggest transport company in CH HPE, Appian (USA), Raiffeisen (RO), SJP (UK), CIB (HU), Banca Intesa (IT), Norkom - BAE (BE), IBM (IT), Accenture (SK), Crédit Agricole (FR), LCL (FR), Natixis (FR), ... Many roles but a big passion for building SW Marco Molteni - @marcomolteni

Recommendations ● Define the business vision ● Define the business requirements ● Split the business requirements in small products units ● Give a business value/priority to these units ● Choose / build a tech solution according to the business value of the units ● Don’t let your IT to define your business (processes / priorities etc.) ● Reduce the complexity and of the risks Build the technology around your business / clients requirements, don’t build the business around you IT solution Marco Molteni - @marcomolteni

• SW costs a lot to build, usually much more than initially estimated. • Maintaining the SW can cost even MORE • Every component added multiplies the complexity, increase the issues and … the costs • Pre-build frameworks and platforms are hardly configurables / updatables and there is a vendor lock-in • The interaction between different modules / services / providers increase the errors -> time -> costs • In 3-5 year your technology will be obsolete and will require to be renewed Better to Know Marco Molteni - @marcomolteni

Maybe it’s already there • Before your money finish in the project check if a similar solution exists … anywhere • Any existing similar SW in the world will be in competition with your solution. Double check that nobody is cheaper / faster / better than you. Marco Molteni - @marcomolteni

Building a new software means ... Better to Know - 2 Marco Molteni - @marcomolteni

Expect to be disappointed! Every participant understands the goal differently. Better to Know - 3

Big Vision … small steps Marco Molteni - @marcomolteni

Have a minimum product from Month 1 … improve IT every 2 weeks ● Deliver an improved product every 2 weeks. ● Verify with the stakeholders that the product is following the requirements ● Stop it if the direction is wrong Marco Molteni - @marcomolteni

Choose a Product Owner Marco Molteni - @marcomolteni

A Product Owner ● Defines the product goals ● Translates the needs of the clients in requirements ● Decides what’s coming in the next product increment ● Gives the priorities ● Interacts with the stakeholders ● Defines the business added value of each feature ● He has expertise in the business, not required in IT Marco Molteni - @marcomolteni

Example of Product Increment The IT estimates the cost of each feature. The Product Owner decides what to include in the next 2 week product increment according to the business value and the cost of the feature. Marco Molteni - @marcomolteni

… if the idea is wrong with small steps Fail as soon as possible Marco Molteni - @marcomolteni

Avoid the Last Tech Fashion if not clear ● No expertise in the market ● No users ● High costs ● It changes very quickly Marco Molteni - @marcomolteni

Avoid the Vendor Lock-IN ● Every part of your infrastructure can be moved to a different provider ● Your data can be easily migrated to a different system Marco Molteni - @marcomolteni

Common Vendor Lock-IN and practices ● Drug dealer style : first version of the SW is cheap (promo), the migration to the new version cost much more. ● The provider is not interested / cannot develop for you a requirement, it multiples 10x the price to avoid it. Official reasons: complexity, or you didn’t communicate it at the beginning. ● Without the code source, every change must be done by the same company. ● For the first phase (contract 1) everything is ok. From the 2nd phase everything become more complicated and expensive. ● Your data is at a service provider, every access as to be paid because it requires effort from the provider and you didn’t declared explicitly in the contract. ● The new features / sw are paid by you, ‘because only you want it’. The feature is re-sold to other clients for a discounted price or maybe you paid something that was already developed for other clients. Stories based on real cases (more details on request). Marco Molteni - @marcomolteni

Other Examples of Vendor Lock-IN ● Every software has problems. You have to pay to solve it because: you didn’t required that particular feature or combination of features, you are not able to use the software correctly. ● A new technology come on the market (mobile, virtual etc.). ‘Sorry 3 years ago you didn’t ask for it the integration is very expensive’. ● The license is not expensive, every change / new feature (Professional Service) is paid at very high market rates because done by specialists (usually junior consultants at the company) ● Special features of Cloud providers: ○ Serverless functions ○ ‘Cheap’ DB and data storage in AWS ● Every non standard feature in common software like databases (Oracle etc.) ● Every Blockchain (Immutable database) is a lock-in by definition Marco Molteni - @marcomolteni

Remember ● Technologies change very frequently ● People change ● Companies change ● Relationships change - Adidas and Puma come from a conflicting brothers ● SW is very complicated, risks and complexities are exponential. Limit the risks and monitor the process! ● If you don’t understand it, probably you don’t need it but possibly you will be billed for. Marco Molteni - @marcomolteni

How To reduce the Lock-In Risk ● Use standards as much as possible ● Be sure that more providers / companies can improve your original infrastructure ● Be sure that your software can be improved at least on a 6 month basis - banks have 2 major releases / year, FAANG have daily / weekly releases ● Challenge the offer of the providers ○ Costs, new features, integration of xyz ● Be sure that your critical data can be exported and read with Notepad on your PC Marco Molteni - @marcomolteni

Special Thanks / Credits Disclaimer: The images come from the web, I don’t have information about their copyright. If you own the copyrights and you want the image removed from the presentations, contact me Thanks to the victims of failed IT project that created experience and knowledge from their errors. Marco Molteni - @marcomolteni