SQLServerCentral / Editorials / SQLServerCentral.com / The Build Buy Debate / Latest Posts

RE: The Build Buy Debate

Paul G-468777 — Fri, 12 Oct 2012 13:31:19 GMT

Miles - your comment interested me but I would like to expand to see if what I am thinking is aligned to your comment (I want to be sure I am taking your statement correctly). In the five or so years since I first touched this thread, I have been blessed with the opportunity to see the inside and help out several companies. Over that time I have become more and more convinced that it is not "buy or build" but "buy and build".The current company I am at (I have moved from contractor to 'corner office') has been going through a lot of pain as they bought a whole ERP solution customized some within the parameters of its capabilities and even extended it somewhat but issues like maintenance and advancement were becoming more and more impossible. Further, if they had followed the tenants of this ('ERP') system it would have cost them dearly as the inflexibility of the system would have cost them greatly in sales and more than a few customers. (It is a ETO manufacturing enterprise). They followed good process when selecting the system (in 1998) but time and technology had eroded the value to the "should we just shut it off" point a couple of years ago.Instead of doing that I took one highly talented developer and we focused on the middle ground (I believe this is now refered as EES?). We took the functions that didn't work and created an interface to the portion of the information source that was reliable, connected it to other systems and essentially packaged them as 'servers'. This lead to the creation of a dashboard-ish user interface that is now able to react to changes of use and environment without an interruption of service. This approach was validated when we upgraded the payroll and HR packages and completely replaced a section of the ERP application with a new system. There was practically zero loss in business or productivity time and we implemented the roll over in the middle of the work day. We are continuing to follow these guides with increasing success.By focusing on building a fabric that lies between the major systems and creating what custom pseudo-APIs we are able to keep upgrades to major systems very 'vanilla' and avoid down time and [b][i]most importantly[/i][/b] we have helped to improve productivity and throughput.Sorry for the overly long response but as someone who lived on the "Buy" side of the fence I now see more of the ways and how I was wrong.

RE: The Build Buy Debate

Miles Neale — Thu, 04 Oct 2012 09:45:51 GMT

Custom software is for custom work process and product. General business requirements are not custom. Buy to solve the common but do not buy more than needed. You do not need to purchase Oracle Financials just to pay your electricity bill. Build to solve the unique, but do not make it unique just to do it yourself.

RE: The Build Buy Debate

Shaun McGuile — Thu, 04 Oct 2012 09:23:19 GMT

Darn been 5 years! :w00t:Hmm so Steve reopened this...

RE: The Build Buy Debate

tabinsc — Thu, 04 Oct 2012 07:52:41 GMT

Steve, I agree that you should develop in-house when you can gain a competitive advantage. But if it is something that everyone does the same way, like taxes and accounting, then buy a package and take that burden off your shoulders.

RE: The Build Buy Debate

timwell — Thu, 04 Oct 2012 07:44:20 GMT

So is this still the forum software you bought back in 2007? How has it gone since then regarding the issues presented here?

RE: The Build Buy Debate

Michael Lysons — Thu, 04 Oct 2012 07:02:37 GMT

I should add that in my role we often build software in-house. As the team is actually a data warehouse team that can also build software, we are acutely aware of the need to get data out. We design good data structures that facilitate this.Without fail, the solutions we build in-house are always the easiest to report on.It makes me wonder how much software is built without the user in mind beyond the actual software's UI.

RE: The Build Buy Debate

Michael Lysons — Thu, 04 Oct 2012 06:58:56 GMT

[quote][b]Dalkeith (10/4/2012)[/b]When I do have to buy in systems. It would be nice to get full access to the code and certainly I'd want full access to back end so we can do our own analysis of data as we see fit.[/quote]It is still amazing to me, with every new system we get in the NHS, how hard it can be to get data out. Sometimes we'll even get charged for, of all things, [i]having access to our own data[/i]. Mental. It really is. Some of the companies are just a joke in this regard.

RE: The Build Buy Debate

Michael Lysons — Thu, 04 Oct 2012 06:56:23 GMT

[quote][b]David.Poole (10/4/2012)[/b]2. How well does system 'X' play with system 'Y'?If both are absolutely brilliant but won't play together then what is the point. All the time and effort saved by buying best of breed will be lost by building the mother of all integration points.[/quote]An excellent point. Especially relevant to my role in the NHS, where interoperability and best of breed are hot topics.

RE: The Build Buy Debate

Dalkeith — Thu, 04 Oct 2012 02:50:54 GMT

I like designing my own systems and generally prefer using them to other peoples systems.When I do have to buy in systems. It would be nice to get full access to the code and certainly I'd want full access to back end so we can do our own analysis of data as we see fit.But yes wouldn't attempt - email systems / flexi systems / accounting systems.Too many perfectly good solutions out there.

RE: The Build Buy Debate

David.Poole — Thu, 04 Oct 2012 01:37:07 GMT

Its funny looking back at a debate 5 years ago and seeing what has changed (very little). If you saw this first time around chances are your company has gone through a cycle either starting up at build not buy moving to buy not build then back again, or the other way around.There are a few pointer here.1. How good are your business users in producing a comprehensive and clear set of requirements?If the answer is not very good then neither your inbuilt software or a bought in product is going to fulfill their expectations. There are no magic wands here.2. How well does system 'X' play with system 'Y'?If both are absolutely brilliant but won't play together then what is the point. All the time and effort saved by buying best of breed will be lost by building the mother of all integration points.3. What are the technology trends?Are there emerging players in the market that produce the software you need (obviously subject to points 1 & 2)?4. What is the total cost of ownership?Buying stuff, or acquiring the open source stuff is really easy.On going licencing, support and maintenance can be very expensive. I've seen open source being touted as a massive money saver only to see the savings blown away in "professional services".5. How well does IT know the business?The people who built the UK Inland Revenue systems were the people who had operated its manual predecessor so had an intimate knowledge of what was being built. In many cases they were tax officers who moved into IT.Today many of those people have either died, retired or left so IT is totally divorced from the service they are trying to deliver.I'd bet that an IT department in a small to medium sized company is actually making business decisions and building code for what I call the NSRs (non stated requirements) simply because they know how the business works. If you know the way in which the business works then the apps that are built can be built quickly, cheaply and close to what the business wants.

RE: The Build Buy Debate

steve block — Wed, 24 Oct 2007 14:28:34 GMT

In a small shop (1-2 developer / dba / system support) we have had occasion to contract out software to our specs when it is too much to do on top of everything else. This is especially useful when going to a new paradigm (starting to use Visual Basic instead of the old Informix-4gl). We also contracted to have the source code as part of the deliverables. One product we got was unusable the day we got it but was able to fix it to the point that it is an integral part of work. It took less time than if I developed from scratch and also learned new programming techniques that I probably would have not stumbled onto on my own.Steve

RE: The Build Buy Debate

Malcolm Daughtree — Tue, 23 Oct 2007 17:14:59 GMT

The great software houses have forced the "User Experience" on us, and Open Source is only "Open" to a select few and "In-House" development can be an incestuous relationship between the two. There is not real right or wrong answer, [b]just a level of risk[/b]. Either change existing management systems to allow for a ROI in the "bought in" solution, or endure the agony of customising it to suit the current business practices. BTW (Quality implemtenation and assoc process documents are horrendously expensive in their own right !) Thank God I don't have to make that call !! Personally, I enjoy the challenge of designing solutions, thats why I work, it's fun ! If your solutions outlast your current tenure then more kudos to you.Just point to reflect "Have you been SAP'ed lately......"CodeOn:P

RE: The Build Buy Debate

rudy - Doctor "X" — Tue, 23 Oct 2007 15:55:10 GMT

Well it is time to resort to the DBAs #1 answer on the list if the 'Top 10 Things' you do not want to hear from your DBA ... "it depends" ...

RE: The Build Buy Debate

Steve Jones - SSC Editor — Tue, 23 Oct 2007 13:37:07 GMT

Great points and a nice reply from Jessica. Buying can work, especially when you need to save time. I'm not completely opposed to buying, it's just that I see core pieces of your company better served by building. If you can afford the time.

RE: The Build Buy Debate

jessicadisney — Tue, 23 Oct 2007 12:37:07 GMT

As with any purchase what you are going to gain should drive the decision. If two to three years of development is acceptable and will put you ahead or at the same place as something you can purchase and you have the resources to devote to this, then building might make sense. In our case we spent two years defining what we needed, researching available software before deciding to buy (we went from a home grown fox/dbase based program too). It would have taken us 3 - 5 years and probably 3-4 developers to get to the same spot as our purchase. We made a major leap, now have external support (which can be a blessing or a curse) and an amazing user group of folks doing a lot of the same stuff we do. That in and of itself was more valuable than the software. How do you process X number of orders a day, how did you automate month end, what controls did you put in place for this, etc. Do we customize - of course but we knew we would going in. I've yet to see a situation where customization didn't happen on any major software project. Our company is in a much better situation than before too because we can actually hire someone with experience on our software who can come up to speed relatively quickly on our customizations. Always pros and cons. Did we have to change some of our work flows, yes. But honestly a lot of the changes forced us to formalize our processes and put better controls in place. Pain in the rear but long term very worthwhile.

RE: The Build Buy Debate

Paul G-468777 — Tue, 23 Oct 2007 12:25:40 GMT

Sounds like a painful rendition of That Ol' job Security" (Sung to the tune of That Old Black Magic)" That old Job Security has got me Stuck Again They haven't updated since - I don't know when This thing is held together with tape and twine And it comes apart when your upgrade touches mine. There is no documentation that I can find I should get out before I lose my mind It is round and round I go, meetings just one more I'm glad my office is on the ground floor."So I mucked up the meter a little. What do you do in a Minnesota winter snowed in at work - rewrite torch songs for the technology era.

RE: The Build Buy Debate

Bob Hoffman-209065 — Tue, 23 Oct 2007 12:04:31 GMT

I started to write a reply but when the pop up ad with a picture of Hillary came up on my screen, it made me ill and I had to stop to clean my keyboard... :sick:Sorry, off topic. But you should have warned me about pornography on this website. We had our current ERP product customized by 3rd party. One day, that group went away and was eventually purchased by the ERP manufacturer themselves.Due to our customizations, we could no longer get the updates/upgrades as they came out because of the unknown effect of the customizations. Our 3rd party vendor would first test those and then send us the update and any modifications needed. Worked well as updates only came out once or twice a year. Some of those same customizations that we developed later became incorporated in newer versions. Since we could not get the required support, we dropped paying the annual maintenance and have been trapped in a now older version with no upgrade path available.So in this case, both the build and buy options were used and both came out bad in the long run. It did work very well in the beginning and was a cost effective solution. Building from scratch was not in the budget.The problem is now resolving itself due to a buyout of our business and we are being forced to use their existing software, which is 10 years old, text based and runs on a Unix system. No more SQL.Down the road, the larger parent is now developing a new CRM product which will be Oracle based.Here we go again.

RE: The Build Buy Debate

Sue Stengel — Tue, 23 Oct 2007 10:21:13 GMT

Great topic and good responses. I love reading these forums. (Steve you're awesome) From a DBA perspective I am mostly concerned with the database when dealing with off the shelf solutions. Often times there isn't much a DBA can do to optimize or troubleshoot database issues with these apps. It can be very frustrating. Also, in some cases the data is locked in a proprietary system. Very sad indeed!Whenever possible I'd rather build than buy - I like the flexibility of an in-house app. The ROI may take longer but in the long run, in many cases, I think it is the best approach.

RE: The Build Buy Debate

Paul G-468777 — Tue, 23 Oct 2007 09:46:29 GMT

Julie,I agree with the importance of all the things you mention. Some of them I like to put in the basket of company strategic plan. Maintaining an IT department that is development capable is a part of the total company plan and in some ways is larger than a build vs buy decision. Two companies I am working with have made the deliberate decision [i]not[/i] to maintain an IT department. Good for me as this equals billable hours. Out of curiosity I discussed IT positioning with knowledgable people in both companies. While one wasn't "sure what we want to do in the future" so they do nothing - IT is not included in corporate planning - which seems flawed to me but it is is what they want. The other has made the decision to "trust the market" and hire people to modify the custom components as they are needed. They make a long term plan and when there are enough modifications required, contract the best talent they can and execute the plan. SInce they are big on documentation they have been able to maintain this for a couple of decades and have figures to back up their cost savings. I found it to ba a fascinating approach to this challenge made even more interesting due to their success.

RE: The Build Buy Debate

Julie Breutzmann — Tue, 23 Oct 2007 09:24:26 GMT

There are several factors that came into play for us in this debate. Can we obtain and keep the developers needed to create and maintain this software? Are and will there be sufficient people who are knowledgeable about the tools used? Would this application give a significant advantage? Will there be asignificant advantage to tapping into the knowledge of the larger user base of the boughten software? Reviewing and modifying processes whichever the decision can have a significant impact, too.

RE: The Build Buy Debate

James Horsley — Tue, 23 Oct 2007 08:43:16 GMT

I do of course agree with you that you can't generalise - but many (most?) businesses do actually generalise by deciding they can't possibly share any changes they have made regardless.As for SAP customisations - I am sure you will find these should in general be considered to be "content" rather than code - as I am quite sure you won't get you hands on SAP's source to make mods - customisations are generally rule-sets and are not really changing SAP per se.

RE: The Build Buy Debate

Paul G-468777 — Tue, 23 Oct 2007 08:42:26 GMT

Two things to respond to:[u]Workflow[/u] I feel that the build vs buy decision (size and urgency plays a part as well) is really told in the process modelling. This is also something that is tragically missing from most vendors software documentation. The most difficult thing to do is not write software but change people habits. The cost of that should be added to the formula (intelligently - thumb suck guesses don't count) to make the BvsB decision. Every piece of business software has interaction and process assumptions built into it. If you can find software that matches your process (or desired processes) the buy decision is easy. I am currently assisting a company that is doing a large scale ERP upgrade. I was invited in after the crash was obvious to avert it (accomplished that) and one senior employ quit because she "couldn't go through this again." The chief pain point is none of this process work was done. The lesson here is that even when upgrading a current system B vs B uis a reasonable question. I had a sign on my office wall for a number of years that said "If you can't write it down, I can't build it." That includes processes. To paraphrase Joe Walsh "You can't know where you going if your don't know where you are"[u]Buying for Bells and Whistles[/u] - I must confess, I am not a pretty UI kind of guy. From years of working with marketing people, I find if someone is trying to impress me with features my instinctive response is to wonder what they are trying to cover up. Time always limits the final product. So if the vendor has invested in this what did they choose to leave behind. There are those vendors who, like street hucksters, like to do feature slight-of-hand. Thankfully I think they are few. However, a list of what it doesn't do is as important as a list of what it does when considering features.

RE: The Build Buy Debate

JacekO — Tue, 23 Oct 2007 08:28:20 GMT

There is another twist to this buy/build debate. I know of businesses that built there own software because they could not buy the software that would fit into their business model. Now they are in the software business. They realised the software they built was much more valuable as a product then the original business itself.

RE: The Build Buy Debate

Steve Jones - SSC Editor — Tue, 23 Oct 2007 07:37:01 GMT

James,I'd agree with you on something like the forums, but that's a very generic item. What about SugarCRM? I could easily add customizations, like phone/VOIP integration, automation to some customer process, links to something like Dynamics, etc. that would give me a competitive advantage. It would be up to me to decide to what extent that I'm helping competitors with that.what about GIMP? Or some editing/rendering process. It might be that I gain some advantage I don't want to share.I don't necessarily disagree that releasing back code is a bad idea. And lots of companies do release back stuff. But many are afraid and they're not sure they want to.I can buy commerical software, like SAP, and customize it as well. That's more along the lines of what I was originally writing about. The forums might not have been a great example. They're somewhat open source. You can buy a license to get the code, but you can't freely release it.

RE: The Build Buy Debate

James Horsley — Tue, 23 Oct 2007 07:07:53 GMT

[quote][b]Steve Jones - Editor (10/23/2007)[/b]The problem with giving back to open source, in many cases, is that the competitive advantage you might gain from adding your own cool customization or bug fixes, is gone because you've now released that stuff to others. That ruins some of the advantage of going your own way.[/quote]I accept this is the perception many businesses have - but it is generally fallacious. Taking your example of the forum software - do you really think it is the bells and whistles of the forums that draws people? I doubt it - I am sure you will find it is the content - so a competitor who ended up with any enhancements to an O/S forum solution would still need to get the content right to benefit. And most of the other users of the forum software would not be in competition anyway. Now there will be exceptions - I know of some examples of software that is truly unique to a business so would never be released as open source - but this sort of software is almost inevitably not bought in from outside anyway and so the open source solution would never be on the table.The original topic was comparing the pros/cons of bought in versus self built solutions. If bought in was ever an option then you could not have been relying on customisation for competitive advantage anyway as the bought in software would be available to all you competitors.

RE: The Build Buy Debate

Steve Jones - SSC Editor — Tue, 23 Oct 2007 06:53:12 GMT

The problem with giving back to open source, in many cases, is that the competitive advantage you might gain from adding your own cool customization or bug fixes, is gone because you've now released that stuff to others. That ruins some of the advantage of going your own way.And if you don't give code back, you've created a fork.Personally I don't have a problem with someone using Open Source code or the MS platform, or anything else. Just pay for what you use, the base software. Give $50k to the open source project that you used as a license fee or so they can continue to develop more of the same type of software you used.

RE: The Build Buy Debate

Shaun McGuile — Tue, 23 Oct 2007 06:48:14 GMT

I can see this developing into a change the software to suit they way you work vs change how you work to suit the software debate, it is this that is the real issue not build vs buyIn 'build' you are still buying the resource to build, in 'buy' someone else has done the building.How we work, and adapting to change in the business environment are the real issues.

RE: The Build Buy Debate

Sarah Dutkiewicz — Tue, 23 Oct 2007 06:39:27 GMT

[quote][b]Jurriaan Themmen (10/23/2007)[/b][hr]Funny this one.I remember my former employer buying a multi-million $$ ERP system and giving up on a self-built Cobol-system. Not just because of the development overhead (12 staff!!), but more because Cobol programmers were becoming extinct and we were up for a huge brain drain (10 out of the 12 were to go in pension over the next 3 years). The ERP seemed like the sensible thing to do.When we were starting the implementation, we were warned by people who had been there and seen it all to adapt our procedures to the ERP, not the other way around. Some responsibilities go to other departments, some come over from other departments, that's what's usually happening in an ERP implemantation. Needless to say things went just the other way because we were unable to convince people that they had to organize their way of working differently. But no: everything was to remain the same.[/quote]Ah yes - the unwillingness to adapt to change and rather than change their ways, just change the software. I'm glad I jumped ship from where I was - an overly customized ERP system running on older technology. Looking at the ERP system's newer model, it would've worked great for their needs but they've gone overboard in their customizations and are so set in their ways that upgrading isn't an option.Even though I'm a developer and should support the build option, there are times where I know the ROI in buying would be better than the ROI of having me build a certain application. And I tend to mention that there's a package out there that does it for x amount - why have me reinvent the wheel when it'd be better to use a package already out there? And sometimes, that's just the way to go. I don't take it personally as a dev - I see it as the cost of business.

RE: The Build Buy Debate

Paul. — Tue, 23 Oct 2007 04:51:15 GMT

Most of my development experience is creating in-house solutions, but have had my fair share of "buy-ins" on both sides.My instincts say that for any internal processes or business-specific requirements, write your own.For any "common" functions, try to buy something in that best meets your needs. If you can't find any, make your own.Of course, when buying anything, it's much easier to justify it if you're getting the source-code as well. I was able to sell an internal component I wrote to another company, almost single-handedly though a friend, and that was pretty straightforward as my company was willing to pass on the source code as well, (not sure if without the sale would've happened anyway, but it's a possibility).Paul

RE: The Build Buy Debate

James Horsley — Tue, 23 Oct 2007 03:35:30 GMT

Yes - that is a real problem - they are happy to "snatch" the free code from the open source projects but don't give anything back - ironically they are happy to pay big money to to large software corporations that give them no "business advantage" at all - they need to recognise that content is the business advantage more than the tool - just like using Word doesn't help you but the documents you write in it might. My specialism is workflow - and though there are good, bad and mediocre systems out there the real thing that makes or breaks systems is the quality of the rules that are implemented.

RE: The Build Buy Debate

Shaun McGuile — Tue, 23 Oct 2007 03:21:04 GMT

Although I agree wholeheartedly with you James I do not see many typical corporate types agreeing to publish 'their business advantage' back to the community/competition. Open source does not agree with the insular capitalist mind set.

RE: The Build Buy Debate

James Horsley — Tue, 23 Oct 2007 03:13:37 GMT

[quote][b]Jeroen van der Wal (10/23/2007)[/b][hr]We are also in a build/buy debate but now considering the option where we take an Open Source ERP framework (Ofbiz) and customize it to our needs. One of the biggest advantages is that we can start with the basic functionality and only develop what's missing.Jeroen van der Wal[/quote]You have almost (but not quite) hit the answer to the "Build/Buy" debate. Open source is a great answer in many occasions but the "only develop what's missing" is the bit that should be "join the project and add what's missing" - that way you contribute back for the savings you have made in not having to develop the other bits and you also remove the problems of "re-merging" your enhancements whenever the core project updates.Of course open source is not always the solution - but there is more and more quality open source software out there - what is often missing is the ability to contribute

RE: The Build Buy Debate

Shaun McGuile — Tue, 23 Oct 2007 01:47:49 GMT

I worked for 7 years for a company where business support applications were custom built in-house.Employing 1 then 2 full time software developers.We had a sister company which bought in all of their software and employed no software professionals, custom spreadsheets in excel and a poor database application, built in access were used.Our business turned over double the money for half the cost and all staff knew that the data in the database was correct and a true picture of operations could be got out of the systems in under 10 minutes.our sister company was clueless and couldn't find its backside with both hands in daylight as far as the data was concerned.The companies were eventually merged and in house development was dropped in favor of buy in.The developers and other IT staff were all made redundant save for the network manager.No doubt you can guess which set of Management now runs the merged business. Doh!

RE: The Build Buy Debate

Jurriaan Themmen — Tue, 23 Oct 2007 01:20:29 GMT

Funny this one.I remember my former employer buying a multi-million $$ ERP system and giving up on a self-built Cobol-system. Not just because of the development overhead (12 staff!!), but more because Cobol programmers were becoming extinct and we were up for a huge brain drain (10 out of the 12 were to go in pension over the next 3 years). The ERP seemed like the sensible thing to do.When we were starting the implementation, we were warned by people who had been there and seen it all to adapt our procedures to the ERP, not the other way around. Some responsibilities go to other departments, some come over from other departments, that's what's usually happening in an ERP implemantation. Needless to say things went just the other way because we were unable to convince people that they had to organize their way of working differently. But no: everything was to remain the same.Five years later, the company's core processes were mostly run by self-built applications, based on VB and SQL server. The ERP being used as little more than a bookkeeping system and as a repository for the core data. All the intelligence residing in the VB applications. Now is that a bad thing ?I guess I'm going to have to go with Steve here. It's the people that make the business. If one application doesn't get them to work together, get another one that will. Main thing is boxes are being shoved and bills are being sent, any which way but lose:)

RE: The Build Buy Debate

Jeroen van der Wal-416856 — Tue, 23 Oct 2007 01:17:38 GMT

We are also in a build/buy debate but now considering the option where we take an Open Source ERP framework (Ofbiz) and customize it to our needs. One of the biggest advantages is that we can start with the basic functionality and only develop what's missing.Jeroen van der Wal

The Build Buy Debate

Steve Jones - SSC Editor — Mon, 22 Oct 2007 19:34:55 GMT

Comments posted to this topic are about the item [B]The Build Buy Debate[/B]