Re: offtopic: Infrastructure Solutions architect - any good ?

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
>> >
>> > --
>> > http://www.freelists.org/webpage/oracle-l
>> >
>> >
>>
>> --
>> http://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

Other related posts: