Most people generally agree that a Software Architect should mostly be involved in high level design, setting standards, choosing tools or frameworks, evaluating products, implementing prototypes and Proof Of Concepts, and training and mentoring developers

The reality however is that the title often can be a political appointment to a developer, a special title given to lead developers of projects, or even something as simple as a management-HR workaround to hire a badly needed developer at a salary or rate that HR or upper management would find unacceptable for the Software Developer or Software Engineer title.

In other words, titles are mostly meaningless.

Wikipedia article defines software architect as:

a computer programmer who makes high-level design choices and dictates technical standards, including software coding standards, tools, or platforms…

Given above, your estimates “50% of my time spent… analysing the software logs… 30% fixing other’s bugs” put you far far off of what software architect is normally expected to do.

• I would say above makes the title they gave you about 50+30=80% fake.

Note that per se, activities like analyzing logs or fixing other’s bugs could legitimately occupy part of architect’s time – provided that these serve the primary purpose of this role – that is, making high-level design choices and establishing technical standards. Actually, this is the case for any kind of software development / maintenance / testing activities.

For example, if analyzing logs led you to an insight on how to make it easier – by improving design, or tooling, or coding standards – this would be perfectly justifiable effort for an architect. Similarly, it could be completely OK for architect to get their hands dirty fixing particular bug(s) – as long as this would result in specific design / process improvements leading to lower bug rate, etc.

_{On a little more positive note, your question demonstrates at least one skill that is quite important for architect: ability to classify different kind activities and track efforts spent on these. Consider adding to your “toolbox” complementary skills to summarize your observations and estimates and clearly communicate these, especially up the management ladder. 🙂}

As a software architect, am I supposed to focus that much on analysing
the logs and fixing other’s bugs?

Supposed to? yes and no. You’re in charge of the totality of the product quality and evolution path – make it work tomorrow, but also make it work next year.
Does that mean lending a helping hand to solve tough issues? Absolutely – at least I do. You can’t make the product work tomorrow if your customers leave you.
Does that mean you should devote ALL of your time to that? Absolutely not. You’re in charge of TOTALITY of the quality and evolution. Devoting that much time to chasing issues is counter productive.

You’re supposed to be proactive:

1. Initiate education plans so other people (dev/support) can lift the load. “teach a man to fish” and all that jazz.
2. Invent ways and develop tools to support faster and easier defect analysis and root cause isolation. If you find this boring, other, possibly less talented or experienced developers find this not just boring, but also difficult and maybe even daunting. Help them overcome this by technology.
3. Start an effort to raise the quality of the product – simplify, modularize, create testing frameworks – lead by example, not by whining and threatening to quit.
4. Make sure developers know what you’re doing – but also your managers. An architect role is much more about relations with other people then it is about coding and analysis. As much as you might hate this, politics play a key here. Making sure your peers see your accomplishments makes it easier to convince them later that you’re right. If you’re not there yet, back your claims by research and POCs.
5. If all else fails, and only after spending time to try to make things better, talk to your manager. Say that your skills are better used in planning and design phases and see what can be done to change the current situation. Your product might be in a pinch and your manager’s answer might be “we need you for this thing right here, right now”. I would insist on a long term plan though – how are we going to change the current situation.

I see the role of an architect a privilege. You get to influence the product in a way not many other people can – the only one theoretically more influential than you are is he product R&D manager (and, possibly, marketing) – but he’s way to busy managing.

The role of a Software Architect traditionally doesn’t have them fixing bugs. Software Architects do help fix design issues in software so if by bug you mean the core way the software was designed lends itself to more fragility or difficulty in expanding/maintaining then it would be the the job of the SA to propose or redesign aspects of the software to solve for that problem.

Given what you said:

50% of my time spent in Notepad++ analysing the software logs and trying to figure out what went wrong. 30% fixing other’s bugs and the remaining (if any) reviewing developers spaghetti code.

That is not the role of a true SA and instead is more of what I would have our developer 1 and developer 2 level programmers start with alongside a senior developer. I say that in particular because I find it really helps new developers in our company get into the product and code by working at that level on issues of code quality. Are you a new SA in your company and they are having you do this work to get into the system? If so then maybe that is OK for a short time. If this is your daily work and has been for more than a year, then quite possibly it is time to look for another role.

I understand your frustration, but understand if you wrote the code or were the last to touch it, time is short, and they can reach you, many managers are going to go to you to fix it, regardless of your title.

Figuring that you still have friends in the development group that is in the crisis, you will help. The problem is when they, and more importantly their management get used to you helping out, they keep coming back. As the say “no good deed goes unpunished.” If they can count on you to fix the problems, regardless of your title, you are just another developer, and someone else they can use.

It is a hard problem to solve, but my advice is:

1. Ask for the charge number for the project this non software architect project time. I find project managers are not as eager to ask for your time, if they have to be accountable for it.

2. Talk your manager about how much time is being lost and to what groups or projects. Your manager might tell you not to help them, and stay focused on his projects. If so, then the other group comes and asks for help, you tell them your boss said not too.

3. Organize your work, keeping your priorities clear, and not be so responsive to outside your architecture projects.

4. Act like an architect, get your peers to see you as an architect, not as the same developer you have been all these years. You have break others of the habit of treating you just as developer.

Good luck.

No, you’re here to manage the big picture.

You have a management issue: fixing bugs and improving code quality is the job of developpers, as an architect you should be issuing guidelines and actual architecture (UML or whatever floats your boat), then giving regular code reviews to ensure these guidelines are followed correctly.

You may, however, implement and fix bugs on the core architecture.

Example: you’d work on PRISM, MEF etc in a WPF/C# project, but you wouldn’t work on the XAML to display the splashscreen.

You’d work on DB design but you wouldn’t write stored procedures for CRUD operations.

etc.

50% of my time spent in Notepad++ analyzing the software logs and trying to figure out what went wrong. 30% fixing other’s bugs and the remaining (if any) reviewing developers spaghetti code.

This is definitely a type of work that you are NOT supposed to do, for this role. According to my experience/observations, architect have to be involved in application design, improvements, technical requirement clarifications and potential performance issues (not checking logs everyday, but primarily analyzing sever issues/errors ) that needs to be addressed or avoided.

In another words, my point # 1 is – architects are the high level designers and system integrators with hands-on experience on how inner-workings of technology work/apply and need to be used.

If you have opportunity to assign and manage the code quality then your work management skills need to be improved. Thus, planning work should be your priority on “how to do the work” approach.

Point #2: if you the one of few developer on these application(s) – then this title is just another sugar glaze by company management to keep you in the same “fix it” role with a new fancy title.

Part of the answer would be to find an engineer who is willing to take on this load.

Of course, the reason this is a problem is that you find this work undesirable, which doesn’t send the message that it is attractive to the other engineers, so they aren’t eager to pick it up either.

I see two possibilities.

1. You were given the position of architect so you could work on bigger picture items.
   In this case, you should mention to management that you are unable to work on these bigger picture items because nobody has stepped up to take on the lower-level support role. That is then their problem to solve.

2. The title is largely ceremonial — a bone thrown to you to keep you around.

In this case, managment may not be terribly interested in easing your support load.

—

One thing that will definitely not be helpful to your goal is adopting an attitude of contempt for the other developers and engineers that I see leaking through in your question. You want these people to step up and confidently handle these problems so you don’t have to (possibly making some mistakes along the way). If they know that you’ll just badmouth their solutions and fix it up for them afterwards, they’re probably not going to ever step up.

The role of a Software Architect is much more than what you are doing in your present company. He is responsible for defining software design standards, making high level design, standards for coding etc., and fixing bugs may be considered only a small part of it thought actually it isn’t. But as you have said, you are working on a product, it means, being a Software architect, the expectation from you for the reliability of the product will be quite high, and in such a case, your involvement in such things will not only help the product but also the company, as you are quite experienced in that. But you should also be provided with some exposure to new feature development and new tasks, that will inculcate your interest in your present organization.

As a software architect, am I supposed to focus that much on analyzing the logs and fixing other’s bugs?

In a matter of speaking, ‘Yes’.

Here’s how I’d qualify my answer:

1. By default, you should let the software developers analyze the logs and fix the bugs.
2. However… You must be aware of defects that incurred a data loss, require an onerous database rollback, take a long time for developers to resolve, or require a customer apology.
   1. As a rule, your direct reports should let you know about such defects.
   2. You should create a culture in which your direct reports feel empowered to tell you about such defects, but not compelled to tell you about trivial ones.

More on #2:

1. These types of defects generally imply an architectural failing. When they do, you must understand the precise nature of the defect and architect a fix.
   1. So by extension, you must be ready, willing, and able to sift through the logs and fix other people’s bugs (even if you don’t directly commit code to the source code repository).

The answer is probably no. Why are you spending so much time debugging and support issues? Is someone assigning that work to you?

It sounds like you need to clarify what you should be doing. You may need to fix bugs; that probably should not be the majority of your time.