VDA and its Relevance to Enterprise Architecture

by Jonathan Kahn

In Zapthink’s recent article about avoiding Vendor Driven Architectures, David Linthicum makes the case that choosing one vendor for your enterprise’s SOA needs is perilous and potentially costly. While this caution bell rings soundly, it appears that today most enterprises may have little choice but to turn to their chosen vendors. Once this process has been started by an inquiry, there is a tendency to march down a very rigid, pre-defined sales process in a winner-take-all battle of wit, determination and even (dare I mention it) discount-wielding (usually in the form of multi-product bundle discounts and ‘free’ support). Sound familiar, oh yeah, I bet it does.

But, having played on both sides of the “death by committee” and ever-evolving requirements matrix game (aka the loathed ‘RFI process’), I’d say most everyone is aware that vendor and product selections are often based on data that comes from other [in hindsight via ROI lenses] successful deployments. The vendors are all too eager to toss you customer references like tradeshow trinkets to help you build executive confidence. Meanwhile, it all comes down to trust and ability to deliver in the end - even if it takes a few extra release cycles to complete the full reference architecture, right?

In the early days of SOA [technology] adoption, as it's always been, favorable outcomes with trusted partners (in this case the big infrastructure vendors) are just about all that a good architect could turn to in solving our favorite, if recycled issue of IT Governance. (And in so doing, a whole slew of causal issues, related to the pace of change in the general business climate, affecting that of the release-cycle crazed software industry, become prevalent)

All the various pressures to produce with a fast-food style delivery, the architecture blueprints that would ordinarily take patience, devotion and painstaking process to distill into meaning, forces us down a deterministic path of Product Platform Selection or (worse still,) Presumed Business Requirements. Increased urgency to IT alignment and buzzwords like “agility” in the business climate only serve to accelerate the decomposition of even the most seasoned IT Architect’s resolve and diminish the most confident practitioner’s integrity in the unbiased practice of their art. Adding to the challenge are the growing list of skills, certifications and aptitudes that some of the recent Executive Architect-seeking clients we’ve been working on, seem to consider as pre-requisites.

And so, it seems to me that one of the industry’s favorite paradoxes is really at work here. What I am referring to is the incontrovertible fact that growing seasoned architects is challenging; it does not happen in a vacuum, but rather via repeated exposure to the meatiest projects of the enterprise, with an occasional diet of vendors’ approaches to applications infrastructure delivery and management. Though the recipe may come in several versions, high-caliber Enterprise Architects are born and differentiated more by life experience, than by pattern analysis and creative problem solving, though these are very important skills they ultimately need to hone.

And so it follows that as a direct result of their homogeneous rearing, a smaller group of architects are out there with a balanced range of experiences to draw upon, especially when it comes to competency in the bottom two layers of the SOA reference architecture – ‘process’ and ‘service’. Still fewer, I would argue, have the requisite tenure of experience that leads to comfort and facility to finesse (or goad, as it were) a board-room full of business stakeholders toward a viable service delivery model, no matter how many Governance tomes they’ve recently consumed.

And so what tends to happen? We invariably gravitate to the hallowed ground of urban legend: IT Standards - in this case seeking synergy at the business semantics layer, which, while it's evolving makes it hard to have meaningful discussions with our business counterparts. Usually, even the most well intentioned, unanimously accepted and methodologically sound business decomposition effort meets some resistance; and the more complexity involved, the greater the likelihood of a stalled initiative.

The bottom line is that there is no substitute for practical diligence and credibility, which flows like confidence from real-world experience. When combined with business requirements in the proper measures, IT Strategy and Governance can actually lead to SOA nirvana. And even better news is that skilled practitioners do exist, and not only in the womb of large, costlier concerns like the IGS, Accentures and Deloitte’s of the world.... Nay, I’ll be the first to attest that if you’re open to a meeting and a seeker of synergy, you might even rub shoulders with one of these professionals at your next Architecture conference. And so here’s my tip for spotting them: They’ll stand out in a crowd easily as consensus builders (not so much as pundits) because the same traits that make them great architects, usually render them approachable and willing to seek challenges, offering their help to others. In my short tenure in the field, I’ve already met several who seem to really "get it" - who have what it takes to build consensus and promote alignment toward common goals, and I find this pretty encouraging for the rest of us who are still learning these skills.

So, not to shamelessly pitch our own service, we’ve been busy populating and categorizing the profiles into the Architect Resource Center (ARC) to help you find them as easily as possible.