[QUOTE="Brett said:
I would say that the important things are having the confidence and
respect of your colleagues in your technical skill, the communication
skills to explain your ideas and a full knowledge of the problem domain;
bear in mind that your problem domain is not just supporting the
requirements of the business, but also supporting the requirements of the
developers. By this, I mean that you need to know not only what the
systems delivered on the back of your framework will be required to do,
but also how they will be implemented.
It's fun, though.
[/QUOTE]
I like your view of this. Thanks. What was your official title?
Consultant (Software Architecture)
We had another guy who was at the same level and responsible for the
database architecture.
You didn't get any formal training for the position?
Not specifically. My background is science, and so my instinct is to
seek out the literature. Our training budget was always overstretched,
but there was usually money for books.
At what point did the
company decide you were ready for this position?
*Laugh*
The promotion from Senior Developer was a recognition of what I was
already doing rather than a change in it. I started as a junior
developer doing VBA/Access development, moved on to VB6 thick client
apps and then ASP/MTS distributed apps. The latter was a new technology
for our company, and I did the research to find out how to build them. I
also wrote an authentication system for the intranet using VB6 to mimic
the NT challenge/response mechanism; we couldn't at that time use
windows authentication, so I wrote an activeX control to query and hash
a secure attribute in the Novell directory system and an MTS component
to verify it against a database. So I was gradually moving towards
having a hand in the common application infrastructure and being the
team expert on how the technology worked.
I got a number of technology/methodology research projects, one of which
was an evaluation of the beta .NET release. By this point we'd taken to
heart the Gospel according to Deborah Kurata, and were about as OO as
you could be with VB6. The limitations of the language were starting to
drive me nuts, so the prospect of real OO in VB.NET was very exciting.
As part of my research I taught myself C#, and instantly fell in love
with it. I recommended that we adopt .NET immediately it was released,
and that we take the C# route rather than the VB.NET route. After some
initial dissent from other developers, this was accepted. I'd also
taught myself UML, and recommended that we adopt UML/UP. We sent all of
the developers on a five day C# course, and the whole department on a
UML course.
So, I guess how I got the position was by making myself the team guru on
the technologies we were using, and by being a strong advocate of the
need to get reuse from components by factoring out architectural
functionality from application specific functionality. I wrote a lot of
the framework code because it was easier to do it myself than to get
someone else to do it.