In our world, the Solutions Architect role is different. Our Solutions Architect works with the customer to determine application features that are needed, and then the features are negotiated and agreed to in a feature agreement. The Solutions Architect also works to develop the generic product solutions to be incorporated into new products. He is supposed to document what needs to be done, but not cross over the line of telling someone how to do it. His view of the system is broader as the features can cross over multiple systems and applications but he is not necessarily well versed in all of the specific technologies in play, although he may be an expert in the key technologies. Once the high level is defined, the systems architects get to figure out to make the feature a reality and for me (database architect), this includes everything from the hardware, the OS, the database, the data model and the database code. I'm responsible for identifying the appropriate hardware and ensuring capacity and scalability requirements are provided for. We're expected to be deep in our technology and understand the interface points of the rest of the system, but not necessarily all the details of the other components. Our Solutions Architect may set requirements for capacity and performance in his area of expertise but he will just collect the info for other components of the system, and compile the total requirements based on his knowledge and feedback from the rest of the team. So I would agree that a Solutions Architect may have broad knowledge in some areas, and very deep knowledge in others, and as long as you have one that knows what his strengths and limitations are, they can be quite useful to have around. If you get one that assumes they know everything, they're a pain in the ass. On Thu, Jul 15, 2010 at 9:42 AM, Dan Norris <dannorris@xxxxxxxxxxxxx> wrote: > I also commonly see the solutions architect role being somewhat responsible > for capacity planning and sizing the target environment properly. From a > technical perspective, this usually requires significant knowledge about the > application and/or database and oftentimes is more art than science from > what I've witnessed. > > Dan > > > On Wed, Jul 14, 2010 at 1:50 PM, MacGregor, Ian A. > <ian@xxxxxxxxxxxxxxxxx>wrote: > >> The architect is involved in putting together what machines are needed >> for a project, what OS they should run, what application server should be >> used, and what database management system He is mainly a collector if >> information. However if the OS team wants to run LINUX and the database >> team wants to run Solaris, he would make the decision on which way to go. >> >> The architect has too look at all the projects and design a cost-effective >> strategy for them all. He is usually not i the chain of command, but has >> the power to make decisions as discussed above. >> >> >> On Jul 14, 2010, at 11:11 AM, <Laimutis.Nedzinskas@xxxxxx> wrote: >> >> > I ment a job title. where does this this guy stand in a command chain >> and >> > what good does he produce. Architect sounds like a person who knows a >> lot >> > but nothing in particular. >> > >> > >> --------------------------------------------------------------------------------- >> > >> > Please consider the environment before printing this e-mail >> > >> > -- >> > //www.freelists.org/webpage/oracle-l >> > >> > >> >> -- >> //www.freelists.org/webpage/oracle-l >> >> >> > -- I may not have gone where I intended to go, but I think I have ended up where I needed to be. Douglas Adams