August 23, 2010 at 8:37 pm
Comments posted to this topic are about the item When To Touch
August 24, 2010 at 2:03 am
Well, as a BI developer, I am used to using 3rd party products as a data source.
But generally we'll munge the data into a more useful form via ssis and then do what we like with it 🙂
DWH FTW \o/
August 24, 2010 at 3:38 am
Steve,
I work for a company that produces software managing the Offer-To-Invoice phase Bid and Tender management, with some very large multinational companies managing hundreds of millions of dollars of offers using our systems. We also have a blanket "Do not touch the database" rule with our clients.
I think there are two issues that are involved in this idea.
The first is that even though the EULA usually specifically denies suitability, a supplier often has a non written contract with their client that the software meets the customers needs and is reliable. In a case like ours, the only way to keep a customer is to ensure their business is safe in our hands and a blanket "hands off" is the only way to protect oneself from blame when customers damage the database.
The second is that while testing may prove that a modification is compatible with the application in its current version, the supplier's complete control over the database structure ensures that future development will not produce incompatibilities. What if an client created index clashes with a new index in a future release? Should the upgrade scripts test for every possible variation that may have occured, or can it presume the structure is standard?
Often application upgrades are not performed by the DBA, the log files are not read : when asked who would be responsible for maintenance, checking logs etc. I had a multinational US company IT say "we don't do that kind of thing, we expect the application to work". If it doesn't work the first thing they do is call us. How much of our time will be spent debugging why in a particular installation everything has gone horribly wrong but works everywhere else. Will changes be remembered and checked against the upgrade contents, or will the database be returned to its vanilla state before upgrades are performed?
My experience is that clients are usually unwilling to accept that a problem is their end, and any modifications made are usually forgotten or invisible to the supplier, and it is then the supplier who has to investigate and demonstrate that issues are not their fault. I have seen cases where an invasive DBA has denied to the hilt touching anything to avoid blame for losses caused by the system being down. I don't think it would be workable to say "Change anything you want and we will still guarantee the application works."
That does not mean, however, that we refuse suggestions in ways in which we can improve our database's configuration *. We have in the past worked with DBAs from our larger clients when they have reported performance issues and had suggestions on how alleviate the problem. In fact these suggestions have led to modifications made available to all customers, of benefit to all.
If the software supplier is not willing to discuss improvements to the application with their clients then perhaps this is a sign of their individual commitment. In a competitive marketplace a customer is maintained by commitment.
Nick
* If I can hijack your thread I would ask another question: Do you think that a software supplier should budget for an experienced DBA to manage the database structure? From my 15 years experience in software development in small companies the most successful projects have had a proficient DBA instead of a systems technician manage the database. So why is this so often overlooked - because they do not provide invoicable hours, sellable features or tangible benefits?
August 24, 2010 at 5:56 am
All too often it comes down to the simple fact that many of these applications were specified and built by coders, not database developers. As a result, two facts apply:
- data access is through SELECT * FROM FOO
and
- ACID is enforced *only* in the app code
In such a circumstance, the schema/catalog is really not much more than a collection of files. If one has a source code license for the application and a thorough understanding of both the business and the application architecture, then gross errors can likely be avoided.
Adding modifying functionality will not only be dangerous, but also tick off the vendor; you're stealing from their rice bowl (or so they feel). Even if you pull it off, the relationship will be strained from then on.
August 24, 2010 at 6:40 am
Once I had to generate a whole bunch of test data for our customer database which had no physical impact on the server. However, this was an audited database which I had forgotten about and silly me, I created the table in the audited database rather than in tempdb. Things seemed fine, until we received pages that the audit server repository had become full because of such large influx of unexpected data.
This product is good when it works, but I had to trim data from five different tables based on when I think I made the changes (foreign key constraints, etc.) and it's no fun deciphering the metadata. I'm sure I accidentally purged some valid data as well, but that couldn't be helped. 🙁
Gaby________________________________________________________________"In theory, theory and practice are the same. In practice, they are not." - Albert Einstein
August 24, 2010 at 7:05 am
Some questions come to mind:
1.) If the purchased application is poorly designed or inadequately indexed, who made the decision to buy that software? The decision making process should be revisited and the decision maker(s) should be trained.
The options for software remain unchanged: you can write your own, purchase and customize if the vendor permits that, or
purchase and live with the design and support that you pay for.
The usual way to touch a purchased application is via enhancement requests.
2.) What terms are specified in the license agreement? Everyone looks for wiggle room, but those agreements tend to eliminate that fairly thoroughly.
3.) What is Microsoft's stance on "touching" code?
No additional notes needed here. We all know the answer to this question.
Nelson Petersen
August 24, 2010 at 7:08 am
Modifying 3rd party databases is a bad idea. Managing upgrades is difficult and you may lose support. If the database is truly horrible, you can create a shadow database you control and copy data to it.
August 24, 2010 at 7:10 am
From the editorial: "There are times that you might be tempted to change things in a database built a software company, or add objects to that database. In many cases this can be seen as action that voids any support contract with the vendor,..."
As soon as you touch it, it's no longer theirs, it's yours. As a software company, why would you want to provide support for someone else's random database? Just my $0.02
August 24, 2010 at 7:11 am
Nelson Petersen (8/24/2010)
Some questions come to mind:1.) If the purchased application is poorly designed or inadequately indexed, who made the decision to buy that software? The decision making process should be revisited and the decision maker(s) should be trained.
>> Ah, but that would reflect poorly on management, and we all know management makes no mistakes.
Nelson Petersen
August 24, 2010 at 7:26 am
Nelson Petersen (8/24/2010)
Some questions come to mind:1.) If the purchased application is poorly designed or inadequately indexed, who made the decision to buy that software? The decision making process should be revisited and the decision maker(s) should be trained.
"Indexing" and "software design" are not usually high on an end users requirements list, functionality is. It might be preferable to an end user to have a poorly indexed software that covers their needs than a super-fast generic product that does not - depending on what governs their decisions. Better to have something badly indexed, or nothing at all?
August 24, 2010 at 7:36 am
I regularly set up routine index maintenance and backups on 3rd party databases.
I often add a new database containing my preferred basic tools into the SQL Server instance (a smallint tally table, an int tally table, some functions, some stored procedures, etc).
It's not uncommon for me to pull data from a 3rd party database into another database or database-like product or flat text file or tab-separated-value-file or whatnot.
It's not uncommon for me to set up reporting off of 3rd party databases (SELECT statements, #temp tables, etc.)
It's very rare for me to actually change anything inside a 3rd party database's own databases; even then, it's generally limited to "Fine, you refuse to add an index; I've watched SQL Profiler, I know this index will be used, I know it will speed up what the users need speeded up, so I'm adding the index."
August 24, 2010 at 8:04 am
Thanks for highlighting this dilemma, Steve.
Others have (and I'm sure will) add more and better detail on other aspects of this question. But I just wanted to point out one quandary that I bet a lot of organizations face.
Specifically, it sometimes happens that the changes one organization wants are not wanted by other organizations. Especially if this is a product with several big customers. Whether it is that the others don't care about the feature, or want to spend more money if the added feature increases the price of the software, or want to go through the upgrade process, etc., the net result is a kind of lobbying effort regarding third-party software. So a lot of times, software vendors will push back or want to wait until there is a critical mass of support for a particular feature, which in a lot of cases never materializes. Some individual organizations decide whether or not to risk making the changes on their own, but it isn't always an easy decision either way.
I'm thinking mostly of functional features in this case, but perhaps there is a better argument for light "touches" in the specific case of performance or database changes. From what others have posted already, in some cases these don't sound like changes that need to be put to a referendum - they seem to be performance bugs or other problems in need of correction (SELECT * FROM FOO) that were overlooked in the development of the product due to lack of adherence to database design principles. It would be great if software licenses had room for this kind of retroactive debugging, because in a way it is a service provided from the customer back to the vendor, probably worthy of a rebate or discount.
Just my two cents.
- webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
August 24, 2010 at 8:19 am
webrunner (8/24/2010)
Thanks for highlighting this dilemma, Steve.Specifically, it sometimes happens that the changes one organization wants are not wanted by other organizations. Especially if this is a product with several big customers. Whether it is that the others don't care about the feature, or want to spend more money if the added feature increases the price of the software, or want to go through the upgrade process, etc., the net result is a kind of lobbying effort regarding third-party software. So a lot of times, software vendors will push back or want to wait until there is a critical mass of support for a particular feature, which in a lot of cases never materializes. Some individual organizations decide whether or not to risk making the changes on their own, but it isn't always an easy decision either way.
- webrunner
Some years ago I worked with a VAR application, written in Progress so it had a more limited exposure than SQL Server, and the vendor took a very practical tack, which I've not run across since. As many VAR's through the 1990's, they sold a "complete solution", meaning machine, OS, database, and application. They had at least one of each machine they supported, and a database and codebase for each release and each customer's mods. I don't believe they "allowed" updating mods by customers, but this scheme allowed customers to follow their own path through updates and upgrades. They had a larger staff then VARs these days, I suppose.
August 24, 2010 at 8:24 am
Nelson Petersen (8/24/2010)
Some questions come to mind:1.) If the purchased application is poorly designed or inadequately indexed, who made the decision to buy that software? The decision making process should be revisited and the decision maker(s) should be trained.
The options for software remain unchanged: you can write your own, purchase and customize if the vendor permits that, or
purchase and live with the design and support that you pay for.
The usual way to touch a purchased application is via enhancement requests.
How realistic is it that you'll be given the option to review the source and data model for a third party solution before buying it? Even if you found cendors who would let you, are you going to bring in your development team to break down in detail each competing tool you are looking at? If you're gonna spend that time, build over buy becomes a much easier decision.
Its not always a matter of poor design, but rather of extra requirements or different use cases. The indexing could be great for what the tool is designed for, but such that the type of custom reporting you end up asked to do cannot perform well.
Also, from the article:
In many cases this can be seen as action that voids any support contract with the vendor, and more often than not they won't want to give permission to make changes.
I can understand that, as it can substantially increase the support costs for a software company. However I also think that a blanket policy prohibiting changes is a bad idea.
This is part of the equation, to be sure. But also bear in mind that most software vendors have professional services groups specifically for customization. Not only do they not want to support your hacks, but they want you paying them to build in any customization you need.
Also, voided warranties aren't the only weapon they wield against customization. From what Ive seen of third party sql server tools, not only is there often little data model documentation, but base tables and their fields are often not named as clearly as you would if you were developing in house. Often they make views and SDKs very simple to understand and use and well named, but make zero effort (or arguably put effort against) to make the underlying data model easy to follow. I mean, its SQL server, and you can figure/map it all out if you want to, but they quite intentionally don't make it easy.
Anyway, I agree with the general sentiment here. It is good and often necessary to "build around" an existing tool, but one needs to be very careful about any changes that can directly affect implementation.
August 24, 2010 at 8:27 am
Nelson Petersen (8/24/2010)
Some questions come to mind:1.) If the purchased application is poorly designed or inadequately indexed, who made the decision to buy that software? The decision making process should be revisited and the decision maker(s) should be trained.
The options for software remain unchanged: you can write your own, purchase and customize if the vendor permits that, or
purchase and live with the design and support that you pay for.
Quite a few purchasing decisions are made by features and budget. The accounting group needs xxx, and of their software choices, a couple fit. When they arrive, you may realize that performance is not great, or there are issues. What do you do? Return the software? It's a large investment in time, and once the decision is made, often on incomplete information, it's not going to be returned.
Viewing 15 posts - 1 through 15 (of 28 total)
You must be logged in to reply to this topic. Login to reply