Case studies
We learn so little and forget so much.
Case 4 - How do you talk to a suit? Guide to dealing with "Big" IT
March 12, 2001
![[Image]](../tklogimages/Toms_cartoon.gif)
The question: How do you talk to a Suit?
Many contributors here have registered complaints of the form, "I wanted to achieve objective X by implementing technology A but management demanded we go towards objective Y using technology B which was clearly inferior for the following obvious reasons..."
Granted that managers are going to feel threatened, ignorant, etc., I would be interested in your thoughts as to best practice for handling such folks: getting what you need while sparing their tender feelings.
Terry's take:
From the movie, "Shirley Valentine," "Marriage is like the Middle East, there's no solution." For enterprise wide computing, there are few easy solutions.
Pick the right battle.
I spent the last 10 years as a standards manager and inside architecture consultant in a really-big-company. My experience is that the IT suits had brains. The business unit suits had ambition. The business unit suits believed that they could do anything with a computer and do it on time, on budget, and on scope if only they could get rid of the dinosaur IT folks they had and get some really smart, modern ones.
I spent a great deal of my time fighting and escalating against vendors and consultants who wanted to achieve objective X with technology A when the company really needed objective Y with technology B. These confrontations often ended with the business suits winning over the IT suits. When the business suits won (we pay our consultants more than we pay you), the resulting systems very often failed. I mean very, very often. The IT dinosaurs would then come in and rescue the project if possible. The issues were almost always about scalability, integration, and manageability, issues not always completely understood by the business suits.
Often heard: "But SQL server on an NT box is so much cheaper than Oracle on a Sun box and the world is going Microsoft anyway." "Why do we need a development box?" "We only need to query 13 months of daily transactions." "Why do we have to have a gateway router?" "We've just got to use OODB." "We'll just use Lotus Notes because our folks already use Notes for mail and it even has a data base." "Why use CORBA, we have a built-in API to Oracle." "Why do you still have data in a mainframe?" "The consultant we hired has built a system X for company Z in only three months." "My 14 year old daughter can build a website."
So, if you storm into the IT Suit's office and trash their "clearly inferior" standards they will probably agree with you. They really wish you could just plug your system into their existing infrastructure. If they could redesign and re-implement all of their systems based on "what they know now," they surely would. In fact, for the last fifteen years they have been begging the business suits to fund just that.
My advice is for you to talk with your client's architecture gurus very early in your engagement. Where I worked, there were only about 10 of these artists and they are probably busy and cranky. Your business unit clients may not even know who these folks are so you may have to start with an IT suit and work your way to the gurus. Meet early with the guru and his boss. Make your case, believe what they say, and enlist their support. Leave quickly and graciously if your solution is a bad fit. Be grateful that you didn't get sucked into that hole. Then, go find another client.
You may get a contract signed with a business unit suit over the objections of the dinosaurs but you are taking a big risk. A year later they will probably say, "Yeah, we threw out that vendor who tried to achieve objective X with technology A. He was a year late and $1M over budget but they still couldn't get the system to work."
You can win the battle.
You can sell Big IT on open source; in fact they are already sold. They've always wanted open standards. They hate proprietary systems, but they run the business on SAP, PeopleSoft, and CICS. They despise using 40 NT machines to operate a system that could run on 2 UNIX machines. They know that the business suits rarely care about the underlying technology as long as it works. It drives them nuts.
So, ACS has the technical high ground. It's open, extensible, standards based, probably runs on Big IT's favorite infrastructure and the inside gurus will secretly admire it. But you still have barriers.
The IT suits will fret over products developed by the "hacker" community. They will be very concerned about the vendor's history, longevity, and long-term viability. The purchasing department may look at your financials and not even send you an RFP. They will be happy to own the code but they'll worry about finding TCL programmers. They will need a long portfolio of successful implementations in companies like theirs. They want proof of scalability/extensibility/integration. They want to visit your other clients to get the real lowdown. They want to read glowing reports from Gartner and Meta.
What can the ACS community do to help over come objections?
- Long list of ACS developers.
- Long list of successful ACS projects.
- Long list of really-big-companies that use or have adopted ACS as a standard.
- Long list of successes in difficult integration environments.
- Long list of horror stories about ACS competitors.
- Marketing campaign directed toward IT suits, Gartner, Meta, et al.
- ACS evangelism directed at the suits and the non-ACS community as well as the ACS community.
- Emphasize open source in practice rather than just open source in theory.