Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

Typical responsibilities of a Technical Architect??

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,
I was wondering what can the duties of a Technical
Architect could typically be.I have an interview for such a position,but the position just describes the requirement of proficiency in a programming language(Java/C++) and good object oriented design skills.
As I do not have any prior experience into this ,can anyone point out as to what could typically be the job requirements and what can be expected from the interviewer, though I understand that it could be company specific.
Any ideas would be greatly appreciated.
Thanks in advance!
 
Author
Posts: 6049
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A partial listing (in no particular order):
  • Design products--you will be responsibile for over product design and integration into existing product lines.
  • Explore new technologies--keep on top of new tools and technologies and find those which apply to use.
  • Be a technology evangelist--promote the technologies, within your company, which you feel are appropriate.
  • Train and mentor junior developers
  • Coordinate--very often there will be a large team and you must provide technical coherency.
  • Arbitrate desiputes--team members may have disagreements (often technical but somestimes not), which you will need to settle.
  • Leading--as a senior team member, they will look to you for leadership, both formal (what's been officially assigned to you), as well as informal (based on respect you've earned).
  • General help--an architect is pretty high up, so people will look to you for help.
  • Project management--while there will likely be an official project manager, you will find that from time to time, you must help with some of these tasks.
  • External meetings--as a senior technical person, you will likely meet, present to, get input from, and otherwise work with people outside of engineering, including (but not limited to): sales, marketing, management, customers, and other companies looking to work with yours.
  • Sales: you may help with sales calls and/or work the booth at various conferences.
  • Running a small team--you may have a team under your direct supervision.
  • Assisting the project manager
  • Long term technical planning--looking 2-10 years into the future for your company and its product lines
  • Presenting work--you may present some research your team/comapny did in papers and/or conferences
  • Oh yeah, you might do some direct development work, too.


  • --Mark
     
    zena sam
    Ranch Hand
    Posts: 41
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks a lot Mark..I appreciate it
    -Zena
     
    Ranch Hand
    Posts: 775
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I'd add another area of possible responsibility not mentioned - create and/or manage the software development process. Hopefully some manager is responsible and capable of doing this, but if not you'd be facing issues with doing builds, configuration management, QA, ensuring integrity of the architecture as a system evolves, etc.
     
    Mark Herschberg
    Author
    Posts: 6049
    2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Originally posted by Reid M. Pinchback:
    I'd add another area of possible responsibility not mentioned - create and/or manage the software development process.


    Isn't that project management?
    --Mark
     
    "The Hood"
    Posts: 8521
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    NO!!! It is NOT Project Management!
    The industry today is strongly influenced by structured processes and this is a BIG issue in most companies.
    In the company that I work for - if you are not up to your chin in the Software Development Processes as currently defined by the company - then you are on your way out the door. I don't CARE how good a techie you are. Gosling himself would be fired. Even Sun insists on this.
    It is corporate survival that they can document themselves as ISO9002 certified or CMM LEVEL 3 or 4 and that these practices are strictly adhered to. It is a requirement for getting many contracts and growing in "Maturity" as a technical shop.
    It takes lots of "semi-techies" to keep the current processes updated and documented and implemented.
    The current processes that I am expected to know, understand and execute on a daily basis include my companies documented version of:
    Change Management Process
    Software Development Processes
    including Analyze Process, Design Process, Produce Process, Review Process, Release Process
    Maintain System Component Process
    Change Request Process
    Support Customer Process
    Software Quality Assurance Processes
    Activiy Management Process
    Project Management Process
    etc.
    etc.
    If you are not prepared to be actively involved in the implementation, growth and well being of these FORMAL processes then you might as well FORGET ever getting ahead in any company of any magnitude in America today.
    You are stuck in the Mom and Pop contracting houses - or the shops so small that they just can not afford what it takes to play with the big boys.
     
    Mark Herschberg
    Author
    Posts: 6049
    2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Cindy, I think we agree but are just splitting hairs. While I am a big fan of process, I also think most processes will not work well, right out of the box. It must be tailored for the specific group.
    Yes, in theory, there are the prople who develop the processes, and then the people who execute them. The reality is most project managers are told, "get me that software [I don't care how you do it]" and so the project manager is responsibile for creating, growing, buying, modifiying, or ignoring a software development process. For this reason, I consider project management to include: selecting a process to manage. Although you're probably right that, they really should be listed separately.
    --Mark
     
    Cindy Glass
    "The Hood"
    Posts: 8521
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    "get me that software [I don't care how you do it]"
    True, that is how many places DO it. That is WHY they are considered immature. CMM measures these groups as Level 1 (chaos). That is why the industry is working on putting an end to that thinking.
    I assure you that "ignoring the process" is NOT an option in any way shape or form for ANY project manager in my company.
    The project manager is allowed to tailor the process within the defined parameters - only by describing the project (we happen to use a tool that he answers a bunch of questions in) - and that description drives the modification of the processes. How that tailoring is defined is decided by others - folks with LOTS of experience who define the processes. He does NOT get to pick and choose what to do. He CAN choose to have folks work overtime to get the job done using the proper processes :roll: .
    Now, if the project manager is stuck executing the project using processes that he does not like he is welcome to put in requests for modifications to the process and document his reasoning. Then perhaps in the next release of the process those thoughts might be implemented.
    But that will not change anything on the current project.
    And when the Software Quality Assurance folks come around for a review, and they say "the process says that you should have produced this document using these standards and getting this signature" you darn well better be able to produce all such documents to standard and process. If you do NOT, then you get to take your case to your bosses boss and explain to him why he should give you dispensation (he won't unless you can show how you tried and it couldn't be done for some reason).
    Unless of course the importance of the item was marked "high". In that case your bosses boss will NOT keep you from having to go to the Divisional Staff and explain yourself. Getting the job done is NOT an adequate explanation. The question is why you did not get the job done CORRECTLY.
    Of course your job performance is measured on how well you get the job done ACCORDING TO THE PROCESS.
    And of course your pay is driven by your rating on your job performance.
    So unless you want to be very LOWLY paid, you had better follow the processes as defined.
    SR Technical Architects have considerable influence over how those processes are defined. Actually, by the time you are a Senior Anything you are expected to be actively involved in evolving the processes.
     
    Ranch Hand
    Posts: 664
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Great, Cindy. Presicely the reason I am avoiding giant conglomerates like a plague.
    Let me ask you this. How many ground-breaking ideas did EDS produce lately?
    I know 4-5 people who worked for EDS in PA, NJ and California, all of them like the company and enjoy working for it, especially those who work for smaller shops that EDS bought out. Heck, I even send my resume there. They produce very competitive software, but it really has NOTHING to do with EDS and it's methodology.
    All this ISO and CMM stuff (great as an idea) sounds very bureaucratic. Did Napster, CheckPoint Software, Amazon, eBay followed these standards when they released first versions of their software? I think not. What happens thought, is when company matures and starts making money not through innovation, but relying on pushers, personal contacts, lobbying, government, versions 6-7-8 of their software, etc., then it really needs to get this bureaucracy on the way to protect itself, to give it's customers stability and security.
    That's also why, when I research new tools and software, I tend to recommend not to use it until version 4, when it matures and gets fat customers. Want examples? PowerBuilder, SilverStream and WebSphere. Or, in case of Microsoft, it is Service Pack 2.
    Yeah, we also had a few folks in my last 2 "immature" companies who came from big shops. They coudn't make a step on their own. They were practically worthless in our dynamic, go-get-it, environment. Of course, we didn't have perks of having weeks without any real work, but heck, this doesn't really bother me that much.
    JMHO
    Shura
     
    Mark Herschberg
    Author
    Posts: 6049
    2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Originally posted by Cindy Glass:
    I assure you that "ignoring the process" is NOT an option in any way shape or form for ANY project manager in my company.


    Then you're lucky. I've worked for, advised, and talked with friends who have worked for, companies where this is very commonplace.
    At my last company, I had the luxury of creating the process myself (btw, I was technically the architect :-). The yang ot my ying, however, was that the engineers were very junior, so I could only adopt the program piecemeal. That, and the president figured if it cost money, it wasn't practical.
    --Mark
     
    Cindy Glass
    "The Hood"
    Posts: 8521
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Originally posted by Shura Balaganov:
    How many ground-breaking ideas did EDS produce lately?


    This is a valid point. Of course EDS does not define itself to be in the "ground-breaking idea" business. The are in the business of keeping systems running smoothly. Very LARGE systems, for a LONG time. They are in the business of providing consistant, repeatable, dependable results - not one time wonders.
    The major problem with concepts such as XP etc is that they have their blinders on. The whole focus is on the development cycle. In FACT, the development cycle comprises less that 10% of the life of a system. It is production support and ongoing enhancements and maintenance that make or break a company.
    When development teams skip the essentials that will be required LATER (using the excuse that it stiffles the creative spirit, or "get me that software [I don't care how you do it]", or whatever) then SOMEBODY is going to pay the price. And it is going to be the folks that inherit the "ground-breaking" system that is a MESS from a support perspective.
    And Mark - in all truthfulness, different areas of EDS are in different levels of growth in the maturity department. There are whole pockets that are still back at square one. :roll:
    (PS: I hate the process overhead as much as the next guy. I just understand the need for it).
     
    Mark Herschberg
    Author
    Posts: 6049
    2
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Originally posted by Cindy Glass:

    (PS: I hate the process overhead as much as the next guy. I just understand the need for it).


    I don't hate it. I really love it. Of course, I'm also the type person who usually volunteers to be a parlimentarian, so it's probably just something about me. :-)
    --Mark
     
    And then the flying monkeys attacked. My only defense was this tiny ad:
    Thread Boost feature
    https://coderanch.com/t/674455/Thread-Boost-feature
      Bookmark Topic Watch Topic
    • New Topic