Are you one of them or one of the other?

Work In Progress!! - leave a commentif you can expand on this

Currently there is heated debate and quite a large amount of hair pulling (from both camps) at my workplace over how ICT people 'should' operate within the business.

There is essentially, to my mind, the following two pure paradigms at loggerheads:

• Business driven (BD)
  
• Technology driven (TD)
  

No-one is able to put their hand up to being totally (100%) on one side of the fence or the other ... but most of us ICT people tend to come to work leaning heavily one way or the other.

And so you know where I come from, I have a (mostly) "Business driven" (BD) approach to the work world - in fact, it's probably something that I do outside as well, simply replace "business" with "Customer", "Client" or even "Person".

Whilst both of these approaches interact within the culture of the organisation the BD approach is more involved ('connected', 'integral', 'within') with reality of the organisation and assumes that the requirements for everything (and that truly is everything) comes from the business.

A case in point (not one that's actually causing the heated discussions here ... yet):
Most companies have an email system which both world-views (BD and TD) could suggest has arrived into a company through the business need to communicate effectively with external agencies (the solution then generally turned inwards and is now more commonly used by staff to staff communication).
We then come to update the "solution" (no longer supported, no longer works, no longer whatever) to which the Technology Driven (TD) approach would list the vendors supplying email software, choose the best fit to the business and implement.
The BD would revisit the business and ask what they want - maybe email solution isn't the way to do business (it's merely a way, not the way), maybe on-line collaboration, maybe txt'ing is what the customer wants, maybe everyone uses email internally merely to share content ... and thus a combination of solutions that truly fit how the business wants to work could be offered.

----------
Rule 1: The solution works within the organisations culture
Whatever the solution set is proposed it should always reflect the current and desired ("future") culture of the organisation it's being used in. Rarely, if ever, can an off-the-shelf product do that and they tend to force the business to adapt their ways to the software.
-----------

Another example (again, using communication as the subject):
Businesses want people to have the relevant information to do their work as they need it - who doesn't want that for their own business whether you're in central/local government, private sector, NGO, community agency - everyone wants their people to have the information they need to do their jobs. Unfortunately most company's have had the solution of "email" given to them by their IT people as the way to pass information around. This has been known to force people to:

• Duplicate information (attachments)
• Miss out on info (forgot to add you the "To" box)
• Read irrelevant info (added you to "CC", just in case)
• Duplicate information again (cut-and-paste into other software)
• Lose information (no idea where it is in my InBox)
• Be at a desk to receive the communication (in a meeting, not good)
  
• Use the one channel of delivery (email - maybe I'm on my phone)
  
• Choose from the limited options of response
  
• ...
  

(not all may happen in your organisation but I'm sure you deal with a few of them)

Why? Because we have been given a technology solution to what is inherently a human thing, "I want the relevant information to do my job."

Here's a thing - email isn't the only way to communicate in an electronic world:

• Web sites
• Blogs
• RSS feeds
• Wiki
• On-line collaboration (Writely as an example)
• Instant Messenger
• ...
  

And that's just talking about email - I'm sure you have a gazillion pieces of software in your place of work that are all doing "almost" what they should but you have to bend over backwards or, even worse, adapt your natural work patterns to fit with.

Before I get the comments about "this is work, we all have to work to some sort of rules" - true, but they are business rules and not ones brought on by what is supposed to be a solution. You will wear a uniform" is a business decision but, "You have to have multiple copies of one thing because you've gotta attach it to emails to get feedback" isn't.

------
Rule 2: The technical solution works how the business wants to work

Of course vendors of software don't want you to think about this because their product will never fit the way you want to do business - not even Microsoft themselves will be totally, 100% happy using Outlook and have to change their business practices to make it fit.

What are we to do - build everything ourselves? Possibly, yes - if you can I would suggest you do. Most organisations don't though, they want to leverage the work being done outside - why write an operating system when it's cheaper to buy one. Well, not "cheaper" but more cost effective. But what if there isn't (and as I have proposed, there never can be) one vendor that will give you the complete solution to your business requirements (don't forget those business requirements, that's why we're here) then what?

Well maybe a little from here, a little from there and some clever gluing of the bits together into a cohesive whole is the approach. Maybe Microsoft's spellchecker is the best going (I've never met one that works so well and I love it) and you'd like it to be used whenever someone types in words. Why not let your wordsmith tool call on the spellchecker and why not let your blogging tool use the same one.

The power is in the glue.

With these little pieces of IT bits-n-bobs performing (business) functionality as the business really wants we can start to join them together into more complex pieces of business functionality but give us the freedom to rip out one and replace with another. If Google started supplying a "better" spellchecker ("better" is defined as "more closely reflects the business need and culture") they could use that one without having to replace everything. Some of the bits the business might have to pay for, fair enough.

Rule 3: Building blocks that work the way the business wants

This view, of course, is not new.
This view, however, is at odds to most the IT vendors in the world and with a lot of IT professionals.

Can we do this now? Yes we can.
Whilst the major IT vendors look at the world differently they are not the only suppliers of software. OpenSource software.

But don't forget, the power is in the glue. Technically there's a few types of glue out there:

• XML
• RSS
• SOAP
• "AJAX"
• SQL
• OpenDoc
• WSDL
• ...
  

And probably many more I don't know about as I don't need that particular service at this moment in time.

With a toolset at ones fingertips the IT professional no longer has to come at it from the technological standpoint. They translate the business requirements into something that the technology environment requires, plug in the services and you're away.
Of course this isn't something most business people want to care about and why they hire techies like you and I, we look after all that for them.

So, in summary ... hmmm, not sure this is actually expressing it fully for me. I will re-visit and amend. You got any views?