Custom built software and blts are not the same
•Download as PPTX, PDF•
0 likes•68 views
Equal Experts is a network of experienced software consultants specializing in agile delivery of custom-built software solutions for businesses. The document discusses principles for determining when to build versus buy software components, noting that organizations should build what differentiates them and buy what does not. Custom software allows realizing value sooner by only building what is truly valuable and limiting development only by imagination.
Recommended
More Related Content
What's hot
Similar to Custom built software and blts are not the same
Similar to Custom built software and blts are not the same (20)
More from Reda Hmeid MBCS
Recently uploaded
Recently uploaded (20)
Custom built software and blts are not the same
- 1. Making Software. Better. Simple solutions to big business problems. Equal Experts is a network of talented, experienced, software consultants, specialising in agile delivery.
- 2. Making Software. Better. Simple solutions to big business problems. Custom-built software It’s not like making a BLT from scratch
- 3. Who am I? My name is Reda Hmeid, I am a technical person and I have been with Equal Experts for 4.5 years. I started as a developer 20 years ago. https://www.linkedin.com/in/redahmeid/ https://twitter.com/redahmeid https://medium.com/@redahmeid
- 4. Make your own BLT Andy George of “How to Make Everything” spent $1,500 and 6 months making a single sandwich completely from scratch. https://fortune.com/2015/09/23/1500-sandwich- from-scratch/
- 5. It’s not the same thing We do not build our own database, queue or programming language
- 6. Now for my made up analogy Buying a COTSS is like going into a McDonald’s and asking for a cheese burger. If you want it as is, you can get it for £1.19 (I think) and be gone within a few seconds. But if you want to customise the burger, you’re going to have to wait a few minutes. But even then you’re still constrained with what is available.
- 7. Principles for build vs buy A. Build what differentiates you B. Buy what doesn’t C. If still unsure, build first and reassess D. Try first, buy later
- 8. Tips to determine a differentiator • Is it part of the organisations business strategy? • Is it something your customers would leave for a competitor over? • Will it be a direct revenue generator?
- 9. True TCO Don’t forget to include • Cost of customisations • Cost of upgrades after customisations • Opportunity cost • Ongoing costs after the initial license period • Cost of changing product • Cost of upfront contract negotiations
- 10. TVO - Custom software’s real superpower • From conception to reality is far shorter • Value is realised sooner • Only build what is valuable • Only limits are imagination
- 11. Final Thoughts
- 12. Thank You United Kingdom +44 203 603 7830 helloUK@equalexperts.com Equal Experts UK Ltd 30 Brock Street London NW1 3FG India +91 20 6607 7763 helloIndia@equalexperts.com Equal Experts India Private Ltd Office No. 4-C Cerebrum IT Park No. B3 Kumar City, Kalayni Nagar Pune, 411006 Canada +1 403 775 4861 helloCanada@equalexperts.com Equal Experts Devices Inc 205 -279 Midpark way S.E. T2X 1M2 Calgary, Alberta Portugal +351 211 378 414 helloPortugal@equalexperts.com Equal Experts Portugal Avenida Dom João II, Nº35 Edificio Infante 11ºA 1990-083 Parque das Nações Lisboa - Portugal USA +1 866-943-9737 helloUSA@equalexperts.com Equal Experts Inc 1460 Broadway New York NY 10036 Web www.equalexperts.com@EqualExperts TwitterLinkedIn linkedin.com/company/equal-experts
Editor's Notes
- A brief introduction of me. My name is Reda Hmeid for those who don’t know me. I struggle to find a role or title that I feel comfortable dressing myself in, so I’ll describe myself as a technologist. I started off as a developer 20 years ago and have stayed down the technical path. I’ll try to keep this talk short, as rather than have you listen to me talking for too long I’d like to invite discussion, feedback and questions for a longer period. This talk is meant to be a scene setter, a way of framing the discussion that takes place later. It’s my opinion based on my experiences, so I would really look forward to hearing from the experiences of others on this matter
- I consider myself to be very lucky at this stage of my career to work alongside professionals who challenge the dominant thinking of the industry but also who force me to think and consider the situation. Most of my talks and musings in blog posts or social media outbursts are usually inspired by conversations with those great colleagues that have led to some introspection of thought. And that is how it came about that I found enough commonality between a BLT and software to have written a blog post on it and now this talk. This came about from a conversation with a colleague. The age old debate of build vs buy has put people into tribes. The builders and the buyers. And just like conservative and labour, we may sit in one party leaning towards one side of the political spectrum, but we all vary how far along that spectrum we are. Nonetheless, it feels like we have these two tribes. And in this case, I am a builder and my colleague a buyer. We were discussing the relative merits of each side. This is when my colleague used the example of the guy who made a BLT from scratch. In case you haven’t heard of this, I’ll brief you on it. A guy made a documentary in America where he showed what it would take to make a single BLT building the ingredients from scratch. By that, I mean building a farm, growing the salad elements, breeding the pigs and chickens, making the flour for the bread, any fuel costs and paying himself minimum wage. According to him, this meant the cost of a single BLT sandwich came to around $1500. This is a little more than the price of your average BLT from Tesco, for example. Obviously, this was a frivolous analogy made to make a point about the cost of building your software as opposed to buying it in. It wasn’t meant as a guiding principle for architectural decisions. However, the point being made is that often the total cost of ownership of building software will be higher and therefore not worth it usually. I’ll come back to the idea of TCO later.
- But let me first put to bed the analogy and its false application to this debate. Making a BLT sandwich from scratch as described in documentary would be the equivalent of building your own database, programming language, queuing system, servers (and if you want to go further) building your own office. We wouldn’t that. If I wanted to make my own sandwich I would go down to Tesco or Waitrose or Lidl, buy the tomato, lettuce, cheese, chicken and bread of my choice, along with my favourite condiment, go home and use utensils and make the sandwich exactly as I like. No constraints, no limits. Unless you are a Facebook or Google, you are unlikely to build your own database or programming language. Even AWS simply repackages existing tech for easy management. I’m not aware of them build much from scratch themselves.
- If we wanted to push this analogy further, maybe too far, buying in products such as SAP or Salesforce is the equivalent of going to McDonald’s and buying a burger. You may be able to customise that burger but within certain constraints - you probably can’t ask for ranch sauce or Brie cheese or a fried egg on your burger - and rather than getting it within a few seconds (because you’ve taken it as is) you now have to wait a few minutes. The more often I use this analogy, the more I consider it so very apt. The key takeaway here, however, is building custom software is not about building everything. It is, however, about building software the way you want and need (based on the needs of your users) without constraints beyond time and money (these are constraints that always exist)
- There are 4 main principles when considering whether to build or buy 1. Build what differentiates you - that concept of what differentiation is a tough one to bottom out and there is always some debate around that. I’ll share some tips later on how I decide what the differentiators are. 2. Buy what doesn’t - this encompasses the who gamut of products. From databases and queuing systems to finance and HR systems. 3. If you are unsure, build at first and reassess - it is ok to do this. Don’t fear it. Build incrementally, define some key results, reassess and decide whether there is enough value in this to warrant building it yourself. This is fine and is the biggest point of building. It gives you the ability to change your mind 4. If you do decide to buy anything, validate it and test it and verify and assess it. Do not agree to buy first without trying ever. And by try I don’t mean get them to give you a demo. A free trial that gives you perspective of how easy it is to implement and use. If you plan on spending £25m over 5 years I’m pretty certain you can be given a 6 month free trial
- One of the first mistakes organisations make when going through decision making on build vs buy is Total Cost of Ownership. Not that it isn’t an important consideration. But because it is a bit of a hangover from the old days when IT systems were simply seen as the cost of doing business…..so cost was the main consideration back then. But the other problem with total cost of ownership when calculated up front is that it necessitates missing certain costs in that calculation that can’t be understood upfront and yet almost always has a major impact on TCO. The most prominent examples are…..
- However, as I’ve already alluded to, TCO shouldn’t even been your main concern, though all things being equal, it is still a concern. Consider what is sometimes referred as return on investment, but I prefer this term, Total Value of Ownership. Annoyingly, it’s a term that Gartner seems to have invented (or at least published) back in 2003. I prefer the term as ROI usually intimates are monetary return on investment, while value can mean anything of…..well, value. In the world we live in now, when software is a key component in a successful business, value becomes all important. A successful IT programme is not about the tech or the architecture or even the innovation, but whether it brought value to the company and it’s users. TVO is value generated minus the cost. This is where the real superpower of building your own software comes. From the moment an idea is conceived and then becomes a reality in production in much smaller than when you buy in a product. Even if we ignore the amount of time, effort and expensive consultancy it takes to implement a COTS product, there is also the up front effort before value is ever realised. RFIs, to RFPs, followed by demos, followed by long contract negotiations. From conception to value with COTS is regularly in the 2-3 year range, and often longer. Because what is often ignored is that before anything starts to be implemented you have that upfront effort, between conception and contract signings, that if done well is 6 months minimum, but it’s not unusual for it to be 18 months. Even when taking the lower of those two timeframes, if you had a culture of building software you will have got to the point of realising value long before those 6 months are up. Remember, those 2-3 years are wasted time as far as the bookkeeping is concerned. And why is building your software so much more valuable than buying in COTS…..because you only ever implement what will provide you value now and not implement something on the basis that it will provide value in some future state. I’m sure many of us have experienced large implementations of 3rd party products that were bought because of a particular feature……for example, the ability for personalised content on a CMS. Only for that feature to never be used. That would have been taken into account in the business case and the TCO. And yet the value is never realised. In a build software scenario, that money would never have been spent and so there is only true value.
- Closing argument From the beginning of tonight I have framed the debate as Build vs Buy. A battle between diametrically opposing views. I have been unequivocal in my support for the side of build. And that an organisation that wishes thrive must build its own software. I have been a tiny bit disingenuous. I’ve raised the banner of build over buy to emphasise the need of organisations to release itself from the shackles of big enterprise software to become a better version of itself as they see themselves and not how big enterprise software companies believe they should be. But the debate was mis-framed. It’s not about Build vs Buy. There is no battleground here. We must build AND buy. The build vs buy debate is a false dichotomy that many, including me, fall into the trap of. We have to pick sides, right? You’re either a build proponent or a buy proponent. No quality software in the enterprise whose business is not tech should ever be 100% build or buy. It is a balance between the two. That’s not a compromise. That is not being pragmatic. That is a statement of fact if you wish to be competitive. But here’s the point of this talk. This is what we should be talking about. Here’s the emphasis that I am making tonight. Organisations have to shift their focus from buying products that drive their business in a particular direction, and force their hand on future tech strategy. SAP is not your tech strategy. Salesforce is not your tech strategy. It is moving away from having big behemoth 3rd party products as core and foundational, to making your custom built software core and foundational. 3rd party products augment your solution. Commercial off the shelf software, with no customisation. Nicole Forsgren, lead author of the annual State of DevOps report and the book Accelerate said in a recent interview: “every time you customize a COTSS system and you have to upgrade that COTSS system, you have to un-customize COTSS in order to upgrade. And then you have to re-customize. That is epic amounts of resource that you are spending.” They provide the commodity that doesn’t differentiate. They integrate and play nicely out of the box with your software. And if a better product comes onto the market, you move over. You use it. You are not beholden or held back or having to fund a major transformation programme just to use a better product. Even when we think in terms of build and buy, even when we think 3rd party products formulate part of the answer, even when we believe the enterprise COTS product such as SAP are part of the answer remember this: they are never the answer. In fact only a part of SAP is a part of the answer. And that is the issue of TVO. You pay for the whole product, using a small part of it with minimal value. As compelling an argument as this may seem, there is one critical problem. No exec, no architect, no individual with responsibility for buying has ever been sacked for buying SAP....or Salesforce...or Microsoft.....or Adobe. But nor have those people ever been applauded as innovators, disrupters or saviours of a company. The message tonight is that It’s not brave to ditch the SAPs of this world. It is not a risk, or a leap into the unknown. It’s a vital instrument in developing a technology strategy that will achieve business goals and not constrain them.