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