Wednesday, December 21, 2005
Vendor Claptrap: What vs. How
If you're in the position as an EA where you have to hard sell technology-specific wares to your non-IT management, one or more of the following major problems exist in your organization:
- IT (and probably all other departments) are financially micromanaged to the point that paper clips cannot be ordered without the CFO's approval. Forget technology here folks, organizations like this are in deep trouble across the board.
- Line-of-business execs micromanage all technology buys, even if the company is flush with cash. This usually happens in organizations with weak and/or dissrespected IT management regardless of how good or awful the EA effort is.
- The EA's, simply put, are not doing their job properly, or at all.
It's the solution to point (3) that requires more explanation. An EA doing their job properly should never be in a position to have to sell any specific piece of technology to the business. The actual sale of an architecture is done in the context of meeting business issues and processes with the appropriate level of services and systems, regardless of how they are obtained and constructed, and within negotiated time and cost parameters.
In this example, to wax rhapsodic to the business about SOA as a primary solution completely misses the point about why we do enterprise architecture in the first place, because the technology-to-business mapping is either obfuscated or worse, missing entirely. EAs talk to the business about process and process enablement - what will be done for the business in terms that the business understands and not how its accomplished. Go into a meeting with your line executives and talk only about SOA, how great it is, what vendors you'll use, etc. Have a Powerpoint deck full of box-and-arrow diagrams using IT acronyms and dialect. The response will usually be glazed eyeballs and wristwatch or Blackberry checking after about 2 minutes (and you lose them completely) or ensuing, perhaps vicious, arguments about cost and time to deployment. I've seen both outcomes in cases like this, and they are never pretty.
Don't fall for magazine/vendor crap like this, it won't help you in any event. What helps is making that transformation from your technology base to the business strategies and processes you're supporting, and to discuss it only in those terms. You can accomodate anyone wanting a peek 'under the hood' offline - its a reasonable thing to do if certain managers are that interested in technical details. But if you've done your architectural duties properly, the decisions that you and your IT management make about architecture must and should stand up.
It just needs to be explained to the business in a different dialect, the translation of which EAs are also responsible for.