Re:
"It is a very big deal that procurement folk and their paymasters are issuing requirements without understanding the technologies so they really aren't doing a very good job vetting the proposals or the vendors."
Or, is it the case that, in the case of software systems, a tendering process is actually incapable of making a good decision about what proposal or vendor to select? It seems to me to be stuck back in the days of Waterfall type 'software via production line' thinking. A competition like for an architectural prize now seems a better model to me, as a proof of both technical competency and creativity in design.
In the subject of Sharepoint, this is a sore point for me, as its basically the only game in town where I live, and still I cannot bring myself to pay $3000 for SP certification in order to get myself a job! I am too devoted to FOSS and being able to get the benefit of lists like this one.
So, many thanks
On Wed, Nov 27, 2013 at 8:37 AM,
<cbullard@hiwaay.net> wrote:
Simon sez: "Whatever the underlying story, I suspect we'll be dealing with the reverberations from this for a while."
This and a lot of other minor earthquakes. If one has worked in a shop or shops that rely heavily on SharePoint, one notes a loathing of XML. Why?
1. In MicrosoftLand, XML is a programming language, meaning, if someone clicks on a link, it will try to open Visual Studio as it's editor.
2. SharePoint has evolved into a drag and drop system where much like the ACA web site, the illustrator/graphic designers who fancy themselves to be UX designers have come to dominate. They don't like non-WYSIWYG environments much and usually don't understand non-HTML XML applications. They, as they tell you, don't do "backend" work. The problem is with SharePoint, no one else is doing that either.
This is fine until they are in an environment where XML is mandated for good reasons. Then they tend to set up the workflows to avoid the XML by pushing them to the other side of some imaginary process wall. All of the authoring and verifying (say quality checking) gets done in say MS Word. If XML is a requirement, it gets done at the end by being tossed over the wall to taggers the same way our parents tossed yellow pad manuscripts to the typing pool.
It works ok until a loop back to the authoring occurs. Now the SharePoint introduces a twisty tangle of revision/issue version control problems. Worse, it is possible that customer-mandated processes such as validation/verification are never applied to the deliverable. They are applied to the Word files. Everyone thinks they've done the quality steps, but they haven't. They don't understand what goes on when XML documents and say CGM graphics are assembled or the opportunities for missteps.
If you're doing something like an S1000D project where lots and lots of pieces of documents (say data modules) are being assembled into a master document with the potential namespace issues (not XML namespaces, the garden variety kind), this can be very expensive and can outright fail.
And this doesn't get into the process design problems where the SharePoint designer designed the workflow too tightly too early (same early binding of late known project requirements).
Caveat vendor.
It is a very big deal that procurement folk and their paymasters are issuing requirements without understanding the technologies so they really aren't doing a very good job vetting the proposals or the vendors.
Caveat emptor.
