|
|
Unread male.
-
Responding to an RFI? Here''s some simple advice
I've been on both sides of the fence here. For many years, I worked as
a consultant to a product or services vendor. often involved in
presales work. Time after time, RFIs would land on my desk, with a
woefully short amount of time provided to complete a credible
response. I did as best I could with the technical part of the
responses, and was always given praise for the quality of the input
that I gave. However, in a recent exercise, assisting in the
assessment of technical responses to an RFI for an integration hub for
one of our clients, I have had the opportunity to see things from the
customer perspective. Here are some observations that I believe will
help anyone responding to an RFI or RFP. Believe me, it makes a
difference:
- Remember, yours is not the only response your prospective
client is reading. Chances are yours is just one of a number of
responses they must wade through (and usually in addition to their day
job!).
- No matter how much you may like to (or how much it
suits you to) believe it, it is rarely the case that the author of the
RFI is an idiot. They may be less technical than you; you may not see
eye-to-eye, but it is likely they know far more about their particular
problem, requirements and needs than you do.
- The
questions you are being asked have been sweated over, reviewed,
modified, checked, and checked again. They are frequently designed to
address multiple issues and often the key point is buried amongst more
obvious statements.
- Most organisations will use some sort
of grading process which is designed to at least show they are taking
an objective viewpoint on all the vendors chosen. This will invariably
reduce into a spreadsheet within which each vendor will be graded, and
some sort of (un)scientific weighting applied.
- Most
of the individuals inside these organisations will not be objective;
they will have prejudices, personal agendas, misconceptions and
previous experiences that will colour their judgement.
From these observations flow the following recommendations
- Answer ALL the questions. Don't be big-headed; yours is
not the only response your prospective client is reading. As stated in
4. above, you'll probably be scored against a grid, and if you don't
answer a question, there will be two probable consequences: (i) you'll
piss them off because you're making life harder than it needs to be,
& (ii) you'll get a 0 rating. The zero rating may have caveats
around it, but at some later stage there'll be no time to read them,
and an overall score will be taken.
- Answer all questions
appropriately. If you spend two hours answering a question about
scalability and then find that the 'same thing' is being asked in the
section on performance, then you may be right: the author may be a
muppet, who doesn't know the difference. Alternatively, you may have
misunderstood what the questioner is really asking. If in doubt, at
least answer the subsequent question as if you hadn't answered the
first. the fresh words and reorientation of your brain may yield new
insight. Common mistakes: (i) Simply referring to the previous answer
- which is tantamount to stating that the client is stupid and has
asked two questions when one would have done; (ii) Cutting and pasting
the previous answer - this isn't kindergarten and clients generally
spot that kind of thing.
- Keep it concise. Believe me:
your potential client will skim anything that extends beyond that which
they can see on one screen. You must be able to provide the key
information that proves you are the answer to their needs within that
space. Any further information will be gratefully received, and
forgotten/ignored, in appendices and supporting documentation.
- Conversely, never
refer to supporting documentation instead of stating the answer in the
direct response. If it's explained elegantly and clearly in the
supporting document, then that's great: include the document with the
rest of your response and mention that the reader might like to refer
to it for more detailed information, but do your client the service of
at least summarising the salient points in the main, customer-tailored,
response.
- Provide concrete, factual answers wherever
possible. Don't replace facts with woolly nonsense if you aren't
sure. Anything contentious will be taken up and thrashed out at a
shortlisting stage should you get there, so don't hold back on
information you believe to be true, but can't quite substantiate.
- Don't
bother with lots of supporting information that isn't specifically
requested. Given the rest of what I've said in this post, I expect you
understand why, but I will labour the point by providing another
perspective: I have never read a response that has been exemplary;
there is always a bunch of stuff that has been missed out, or not
explained properly, or no proof-read, etc. etc. etc. If you then go on
to write a load of stuff because you think the reader should know it,
even though you haven't bothered to do the bits they have asked for
properly, then, well, it pisses them off. Concentrate on the stuff
you've been asked to provide. Trust me: you won't have enough time to
do that justice, let alone put the frills on.
I would urge all suppliers to take careful note of these points.
Admittedly, this is only my perspective, based on being a technical
reviewer on a number of occasions, but I know for a fact that it's hard
enough to win over a client and you must do as best you can to make it
easy for your potential client to choose you. On the positive side,
there is almost always all to play for. I've seen may examples where
the outsider storms it - but usually only because they've played a
blinder in the selection process. Conversely, never consider it a done
deal. I hate the look on a vendor's face when it finally sinks in that
the sale they've told their directors is a done deal, evaporates in
front of their eyes.
|
-
It seems that nobody can start a discussion about the discipline of software architecture without first attempting to answer the question, "What does a software architect do?" The answers are many and varied. Some think an architect is essentially an uber-team leader. Others believe architects work best when locked in their ivory towers, not dirtying their hands with the drudgery of writing code. I think both can be true - depends on the task at hand. However, what really comes across to me when I read about others' experiences of the job is a single unifying theme: handling the non-functional requirements.
In short, a software architect is the bloke that has to worry about the non-functionals.
|
-
-
Working for an IT consultancy day-in, day-out, it's easy to forget that a significant proportion of the business world is still a long way from embracing IT as an integral part of their working practices. In no area is this 'problem' more apparent than in the field of conveyancing law. Let me illustrate by example:
I'm attempting to move house. I was delighted to find that my solicitor now has an email address (and a proper on at that; none of that such-and-such@aol.com nonsense). In an attempt to improve communications and ensure rapid progress of my sale, I sent her an email. I heard nothing back so decided to follow up with a phone call:
Me: Hello. I was wondering when you would be able to come back with me with answers to the questions I emailed you?
Solicitor: Sorry I haven't received your email.
Me: That's strange; I sent it a couple of days ago.
Solicitor: Oh, ok. I'll switch the computer on and have a look… Then I'll get back to you.
Clearly not online 24x7 then.
I should have taken the hint that his was not going to be the textbook example of modern communications in action. Two days later, I still hadn't had a response. I called again:
Me: Hi. Any answers to my questions yet?
Solicitor (clearly harrasssed by my interruption): Yes! I have answered your questions!
Me: Oh. Can I check you sent it to the right email address as I haven't received it?
Solicitor: Please be patient! I dictated it yesterday and it will be typed up by our typist as soon as she gets to it on the tape. However, it's her half-day today so you may have to wait until tomorrow for her to get round to it.
Instant communications mean nothing unless you get your business workflow streamlined to match.
Ho hum.
|
-
It is very rare that I purchase a subscription to an online service. In fact, the only other two times I have done this was for Friends Reunited (a fact I feel inexplicably embarassed to admit) and then to Genes Reunited, to help in researching my family tree. I don't think I'm particularly reticent when it comes to my willingness to partake of all things online, but it is clear to me that any online proposition must fulfil either one or both of the following criteria for me:
- It must provide a service that enables me to do things I couldn't otherwise do and, as a result, I perceive, significantly improve my life (I think Friends Reunited hits part one of this at least; Genes Reunited both);
- It must be cheap (both Freinds Reunited and Genes Reunited score points here)
How does Flickr fit in?
Well, it's pretty cheap, but what it really gives me is peace of mind. I have hundreds of digital photos and suffered from an increasing feeling of unease that something nasty might happen to my laptop, and I'd lose them all. Yes, of course I back them up, but (a) that's a pain; (b) I don't do it regularly enough and (c) I don't really trust recordable CD/DVD technology.
With Flickr, I can upload pictures to my heart's content (unlimited space and a 2G/month upload limit should be enough for me), and rest assured that they will be backed up with enterprise-level QoS. Should I lose my hard drive and leave my DVDs out in the sun, no worries - my precious photos will not be lost.
I'm a real fan. They've solved my personal DR problem. Thanks Flickr.
At first I wondered how they could afford to do such a thing, but if you do the math, it seems to work out pretty well. I don't know what the price per GB is for enterprise storage, but I'm pretty sure that, even if I managed to use up my 2GB/Month quota, it would still be more than covered by my subscription.
Of course, the real benefit for Flickr is the lock-in potential of customers like me. Given the amount of time and effort I have already spent uploading and categorising my pictures, I cannot see myself ever moving from them. I guess all silver linings have their cloud [note to self: insert appropriate metaphor here at a later date].
Finally, couldn't finish this post without mentioning how exciting the whole Flickr phenomenon is. Check out all the clever things that have grown up around Flickr. The tekkie side of me particularly likes the geotagging stuff. The artist in me finds 50 People See both beautiful and fascinating.
|
-
I love the 'new' and exciting world of AJAX. I love the fact that most of us that have been around a while know full well that we were attempting this many years ago. Back at the beginning of the millennium, I was building transactional sites for supermarkets and using AJAX techniques to update shopping carts on-the-fly and other such 'technical wizardry'.
The stuff we hacked together worked, but there was often a downside - 'power' users (those that put large orders through) sometimes complained that the performance of the application got worse the longer they shopped. Some even had to kill their browsers and start again. I'll have to be honest and say that, at the time, we never got to the bottom of this; most customers didn't see the issue and it inevitably received low priority. However, I wish we had solved it and it always bugged me.
So, I was very pleased to see this MSDN article, in which Justin Rogers from the IE team explains common patterns causing memory leaks in IE. This should be required reading for anyone heroic enough to be considering large scale deployment of AJAX-style applications.
|
-
It's not often that I stuble across a series of posts that keeps me gripped right to the end. However, Ralf Westphal's series exploring the nature of the 'application' did. He starts by asking this simple question and ends up, a few weeks later, defining a completely new modelling language. I think it's very inciteful and I'm considering using this as a way of exploring my designs in the future. The complete series is at http://weblogs.asp.net/ralfw/category/9899.aspx?Show=All. Dig the figures. Enjoy.
|
-
I've not been following the XML appliances field, but there's been an industry buzz growing around Cisco's reported entry into the arena, so I decided to sit in on John Chambers' keynote at Cisco Systems Inc. Networkers 2005.
I'll have to admit to sitting through the first part of the talk and wondering why I was bothering. However, when John moved onto 'Application-Oriented Networking' (AON), things got more interesting.
AON is about moving added value services such as message routing and MDN security into the network infrastructure, so that applications can focus on business logic. John's vision is that the best place for functionality such as message routing, validation, access control, antispam, virus protection etc. is actually within the network infrastructure.
I can see this and it makes a compelling argument. As an architectuct there are some compelling reasons to be delighted with the idea that a properly configured network infrastructure can provide all of this for me. However, I have more questions than I have answers. For example:
1. Does this not result in the distribution of business logic to multiple parts of the infrastructure? Is this a bad thing?
2. Development and deployment? How on earth would one go about building a software solution that relies on additional intelligence in the network?
3. What about testing such applications? Surely debugging would be, well, somewhat more challenging?
4. I guess that from a performance perspective I should be rubbing my hands with glee. Moving all that processing out of my application boxes and allowing the network routers to handle it is brilliant. But then I have to size those things somehow.
5. How does this blur the distinction between application vendors and service providers?
6. From an operations perspective, who owns the application logic?
I guess there will be more detail on all of this coming out over the next few days.
[23-June-05 edit: Cisco press release now available here. More details on AON available here]
|
-
I spent too long working this out, so thought I'd stick it here in case anyone else has the problem.
I think the ability to tag documents in Word and have the tags show up in a SharePoint document library is pretty clever. I've used it alot. However, today I had a problem where, no matter what I tried, I couldn't get SharePoint to match a field in a set of Word documents with an identically named field in its library.
Why? - I had changed the name of the column in SharePoint to match the field in Word. For some reason, under-the-hood, when doing the matching, the old name was being used -> no match.
Solution? - Delete the column in SharePoint and recreate it with the correct name.
Hey presto - all is well with the world again.
I bet there's a knowledge base article to this effect, but could I find it?...
|
-
The alarm bells started ringing when I noticed that the size of the ASP.NET cache is cannot be configured directly; the only way to effect its size it obliquely, using the 'global' memoryLimit setting for the process model in machine.config. Running up perfmon and looking at the Cache performance counters shows that on the surface, there is one memory cache per application domain. However, this is merely a thin veneer hiding the basic truth: the cache is a machine-wide resource.
So what?
'So nothing' if you have a dedicated web server to which to deploy your precious, sandboxed application. The problem is that in many organisations, such as the client for which I am currently working, it is quite common to deploy applications to a shared infrastructure environment. Thus, your application will be sitting on the same web farm as a number of other applications.
Generally speaking, IIS will do a good job of ensuring that applications sitting side-by-side don’t affect their neighbours. IIS6, for example, can be configured to recycle errant processes if things get a little out of hand.
The issue is that there isn't anything like this for the cache. If you turn output caching on for a page or page fragment, then the response is stored in a cache. That's fine until one of the applications doesn't play fair. Suppose an application is misconfigured and attempts to cache different versions of a page for every product ID, or customer ID, etc? Clearly it will 'spam the cache' until the cache starts recycling slots at such a rate that it hurts performance rather than improving it.
That's bad.
It's bad because:
- that evil application will affect the caching performance for all the other applications on the infrastructure;
- the knock-on effect could be to kill performance of all applications on the box;
- it will be difficult to troubleshoot as it won't be the first investigation target;
- it's very easy to set up, and then misconfigure, page-level output caching;
- the tagline 'lots of caching=better performance' is hard-wired into a lot of developers' heads with no caveats.
And we haven't even started to think about programmatic access, where miscreant applications can stuff blobs into the cache with a priority of High, or even NotRemovable! [note to self - more investigation work required here]
Sure, one could modify the memoryLimit setting so that it was something very much smaller than the default value of 60% of total machine memory, but to what?
What's the answer?
I so wish I had all the answers. In fact I wish I had one more than half-baked answer to this issue. I suspect some carefully crafted FxCOP rules might come the rescue here so I'm going to investigate.
Any ideas welcome. I'll follow up in a few days.
|
|
|
|