Posted 13 Jan 2011
Link to this post
The indicated resource is useful in case a customer is interested in a specific version.
However, the problem I was trying to describe, even though it can be fixed by a technical solution, is not technical.
It is in fact a typical enterprise cross-domain technical and management problem.
To be brief, the situation is this:
Our CIO office provides the publishing systems platforms and server farms for various domains (intra, extranet, publishing).
We provide Telerik components as part of the package.
However, for sanity reasons we provide a standardized singular version.
As upgrading Telerik components requires the management approval of business stakeholders for all our sites, as well as the technical content creation personnel approval, and our press office approval, we upgrade telerik as little as possible, even though we have for 3 years now full purchased support contracts. Typically we upgrade once per year.
The problem, which I in fact would need to solve, is:
1. When upgrading across multiple versions of telerik (skipping a generation or several), the CIO office needs to provide per affected telerik component being used, the effectual changes.
2. These changes, need to be approved by the content management folks, so they can then endorse the upgrade to the business stakeholders.
So I need, at various intervals, a list of all upgrades, changes, and bugfixes, to a certain set of telerik products, from say version X - version Y.
Currently, the only way for me to do this, is to manually gather all the change/release notes, and then compile a list from them. This is quite time-consuming, and I would imagine other customers who use the products in a sense of business more than technical, would have the same needs.
From a management perspective, I would expect the software ALM folks / architects at Telerik to also be interested in change deltas over parts of the product suite over time. This is usually seen as a good way of measuring expected work versus architecture changes versus selected software development approach, against actual implemented work amounts, against actual results. Or if you're doing RUP then seeing the golden point.
Anyway, I do realize that many customers do not look to technical solutions for solving cross-domain, partially non-technical problems, but personally I see this as an actually quite unusually easy way of solving a very difficult and expensive (timewise) problem that actually gives a Telerik customer company's business folks a really good way of pushing upgrades internally, for what I would expect to be low cost for Telerik.
So from a business analysis or gap analysis point of view, there actually is currently no easy way to see what buying say version Q1 2011 would give you over say having an old non-contractually-supported Q1 2010 for instance. So it's also a sales tool, both for telerik and the customer's internal organization.
I hope this clarifies the need, and also I hope this clarifies why I would want a technically perhaps illogical / odd solution, which is to say that it would be a solution to a non-technical problem.