Bryan Watson via database-career 
# View Group Archive: http://ITtoolbox.com/hrd.asp?i=939
The Question was :-
'I got turned down for an interview and was told my skills
were too 'light' for a DW Architect - what does this mean ?

Bryan's Answer was :-

You have experienced the gap between the "classic" definition of architect
and the "marketing" definition of architect.

Classic architecture (in system definition) describes the principles which
govern the creation of a solution. These principles are rooted in the
business drivers and needs, the anticipated business ROI, the functional
impact (positive and negative) on the business operation, the technical
models which support the business functions, the technology options which
support the models and the implementation plan for creating the solution.
This architect produces a description of the complete solution, linking
technical implementation to business needs.

This architectural description becomes the rules that govern tool,
platform, and technology selections for constructing the solution.

Marketing architecture usually ignores all or most of the business
relationship and focuses on technical skills. Typically, the skillset is in
a single product or technology area (Oracle architect, ETL architect, Java
architect) rather than in the total solution (data warehouse, or better,
Customer Relationship and Marketing).

What makes these narrowly focused skills "architectural"? Actually,
nothing. These are implementation or management skillsets. But, services
companies can charge much more for architects than they can for DBAs,
programmers or sysadmins. And people feel better if you call them
architects. So, this is a marketing title only.

The essential skills of an architect, whether dw or any other environment:
(1) ability to understand (or get the customer to articulate) the
business needs in terms of business value
(2) ability to combine differing "visions" of the company into an
integrated whole that conforms to the company's stated mission
(3) ability to assert "best practices" among the company's competitive
peers and lead a discussion of which practices are appropriate to the company
(4) ability to identify opportunities to support that mission, those
needs and those practices through technology
(5) understanding of the viable current and future technologies and how
they impact on that support
(6) ability to articulate a coherent integration of technologies in a
technical/business process model
(7) ability to guide the evaluation and selection of tools which fit that
model and which are appropriate to the company's "readiness" to adopt this
solution
(8) ability to articulate the rationale for that tool selection and the
circumstances under which an alternate tool should be adopted (and the
impact of that adoption)
(9) ability to establish the architectural model of the total solution
(near and far-term) and the rules that govern adherence to that model
(10) ability to monitor the implementation of that model, identify
variances from the architectural model and direct re-alignment between the
architecture, the design and the implementation
(11) ability to assess the completed solution and establish the degree to
which the implementation conformed to the anticipated business benefit

Of these, only (7), (8) and (10) demand specific product skills -- and,
even there, the skill required is knowledge ABOUT the product, rather than
hands-on skill with the product.

imho, of course....

Bryan Watson