IT Architecture in the Enterprise

What is IT Architecture and why is it important to the Enterprise?

I once looked up IT Architecture on the web and found dozens of different definitions, but not one that satisfied me adequately. I think most people think of IT Architecture as a "technical layout/design" exercise. In other words, what cable connects to what, iSCSI vs. Fiber channel, Windows vs. Linux all Cisco network vs. a mixed environment. While any or all of the above could potentially be part of an architectural decision process, they would only be a small part. Architecture should accommodate how something fits into the fabric of an entire business. In other words, when you drop a pebble into the pond, you need to observe where the waves go and what impacts they have before you make a decision.

What are some of the things you should consider in applying architecture to a project or technology acquisition decision? The following points are in no particular order of priority. In fact, the priority any of these bullets are given would apply differently based on many factors including; business type, size, maturity, industry, etc., etc.:

Does this technology have any negative effects from a business parnter perspective?
Example: If you're looking to buy equipment from Cisco, but your company does a large OEM business with HP or Juniper, then you might want to consider the alternative options these "partner" companies provide. In the end, the cost of the equipment and the cost of ownership shouldn't be any more important than any other decision factor. If one of your decision factors is "potential to decrease business with a key partner" vs. "save a little money on IT" then I would argue that buying from the partner is probably the better way to go, even if the downside is a negative impact on your team's efficiency. IT should never make decisions because they make IT better for IT, only because they make IT a better partner to the business.

How does the solution scale?
Scale could be up, down or sideways, how you view "scale" should really depend on your business requirements. If you have a rapidly growing company then you should be extra cautious about any implementingion of "home grown" or non "mainstream" products. As your scale grows the cost of entry is soon overwhelmed by the cost of on-going management if the wrong solution is implemented. However, this doesn't mean you shouldn't consider the occasional risk. Taking a risk is OK, as long as the potential payoff is much greater that the cost of failure.
How will the solution you choose work or be supported when or if it has to work in a geographically dispersed enterprise?
Many an IT organization has been caught with their collective pants down when they've implemented a solution that has any or all of the following characteristics;
Doesn't have good support outside the US
Staff with training in the new solution are difficult to find
Adding capacity isn't as simple as adding more boxes or licenses
There a huge number of factors to be considered when architecting your next solution, the above are just a few of the more obvious. I'll be talking more about this subject in subsequent blogs. Suffice it to say, don't assume you've done your architectural work because you chose hardware from the same vendor as the time before!