Wednesday, December 21, 2005
Vendor Claptrap: What vs. How
Deep in my gut over the weekend, I knew this was coming as I perused a stack of professional and trade magazines before taking them to the recycling bin. The headline on the cover of a large-circulation IT rag screams: "Selling SOA to the Business!" Of course, it's laden with pithy vendor and analyst quotes on precisely how you get the biz to caugh up even more cash to store old wine in new bottles. And no benefits to actual business requirements and needs (except the standard admonishment to make sure to collect them) are ever explicitly stated, nor can they be.
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'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.
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.
