I’m not even sure how to say this. Frankly I had assumed it didn’t need to be spoken to. I found my way to this position before I could grow facial hair and figured anyone in the field of Architecture or who had “Architect” in their title at least had an inkling of this fact: the tool you’re hawking is not a substitute for Architecture.
There are few things that really cause me grief. I mean really cause me grief. Exasperation and speechlessness aren’t things I normally ‘do’. However, when someone invites me to a meeting ostensibly about architecture of some sort and I’m presented with a vendor (or an internal champion) flogging their wares, I get really irritated really quickly. As someone once told me, “Chris you have a low pain threshold for idiocy.”
A tool is a tool. The chisel isn’t a wheel. The chisel didn’t even invent the wheel. Man’s intellect and pragmatic innovation and most importantly his need invented the wheel. The chisel made the wheel possible to craft. The chisel, along with a hammer, facilitated the development of the wheel. And if for some metaphysical reason the chisel didn’t work, man would have used something else. The tool exists merely to enable, not to inform design or substitute for it.
(As an aside, I’m reminded of Palacky’s statement to the effect that if Austria hadn’t existed, we would have had to create it: Need drives innovation).
Your technology, no matter how creatively presented, no matter how slick the slides, no matter the sales technique (the Sandler sales technique comes to mind), is still just one of many mechanisms I may use to enable my strategy. It is a chisel. Sometimes not a very good one. It is not the solution, it is not the strategy, and it certainly isn’t the architecture. It is a means, not an end.
Architecture is about holistically describing the system of people, process and technology. It can be abstract and conceptual, or it can be concrete and detailed. But it is never merely a specific product set from a specific vendor. I cannot be convinced that Oracle Platform for SaaS is a SaaS architecture. It may have architecture elements within it, but to me any SaaS architecture must include things that go beyond technology (e.g. what is the business model?) Likewise if I hear one more time that ILOG is a company’s strategic BPMS or BRMS architecture I’m gonna find the nearest IBM Sales guy and string them up by their sport coat. You’ve been warned.
I’m sure you all know of companies that employ hundreds or thousands of ‘architects’ that sit around researching products to buy or projects to manage. If, for example, I wanted to conduct an analysis, architecture and recommendation of how to improve software quality within an organization, I would certainly not start with a demo of an automated system for measuring the quality and size of business applications via code analysis. I would start with distinctly non-technical things such as “why are we doing this?” “what problem are we really having?” “what problem are we actually trying to solve here?”. Sure at the end of this process there may be questions such as “how can technology be brought to bear on this problem?” and “do I have capabilities in the inventory to address this?” but if I never take the time to understand the problem and to architect a holistic solution to address that problem (along with a means to verify improvement), why in the world would I think that buying a vendor’s product would ever really deliver value to the company?
More to the point, why on Earth would I start with buying a vendor’s product? Because I can guarantee you, once the tool is purchased, it quickly becomes the answer to just about any problem you have.