Architect vs Developer Responsibilities

Responsibilities of an architect and a developer don’t solely depend on the employees role; it also depends on the project and company type. Let me give you an overview based on my personal experience in Turkey.

Support Agreements

A support agreement is the situation where a SAP client makes a deal with a consultancy company to resolve their daily issues over tickets. In that case, the consultant is responsible of understanding the issue, solving it, making the users test it and eventually transporting the solution to the live system. One of the significant responsibilities is to resolve the tickets quickly if the matter in hand is urgent. This sometimes involves working late or at weekends.

Usually; companies agree on response time for priorities. For example; urgent tickets might expected to be replied within an hour & resolved within 24 hours, while low level tickets might expected to be replied within 24 hours & resolved within a day. In that case, this scheme would also act as the KPI of the support consultants. At the performance evaluation at the end of the year, their actual response & resolution rates are compared against the targets. This can run on team and/or personal level. FTR (first time right) is another typical KPI, which indicates the percentage of tickets where the first technical reply got accepted by the client.

In typical support deals, we rarely see architects get involved. Support issues are basically small corrections or enhancements on an existing system, so no architects are full time present. In case a correction needs modification on the fundamental level or some supervisory advice is needed, that’s where they step in. Knowing and understanding the bowels, standards and deep infrastructure of the system much better than developers, the architect can make those fundamental modifications accurately and risk free. Alternatively, the architect can guide the developer on how to proceed – that’s also possible. Whenever a developer without architectural knowledge attempts to do a fundamental change, we usually see anti-patterns emerge.

You can imagine it like this: You can hire a worker to paint your walls, no architect needed. But in case you want to expand your swimming pool, you ask your architect first.

Implementation Projects

This is the deal where a consulting company implements a new functionality to a SAP client. It can be a huge fresh SAP implementation, or a mid-sized implementation of a new functionality over an existing system; or even an upgrade. That’s where ideally developers work under the supervision of an architect.

Each project has a number of tasks to complete. On shallow tasks, the developers would be allowed to directly start with the development. However, the architect walks in for bigger developments, frameworks, integrations and similar comprehensive tasks. The architect usually designs the framework, does the low level coding, does a few demo implementations, and leaves the rest to developers. Other developers build on top of what the architect has prepared.

If I had to list some typical responsibilities on top of my head; an architect would be resposible of:

• Defining the development standards, naming conventions and document formats
• Technical supervision to functional consultants during the analysis phase
• Supporting time estimations
• Acting as an objective technical authority in meetings
• Communication and agreement with non-SAP architects on integration points
• Supervision to project management for task distribution
• Architectural design & development of complex applications
• Framework design & development for applications sharing a common ground
• Supervising developers so they don’t re-invent the wheel
• Review & validation of code from developers
• Prevention of code duplication
• Pursuing and evaluating test results
• Pursuing architectural, technical, performance and usability excellence
• Early recognition & proactive measures of architectural risks; such as contradicting or overlapping requirements
• General responsibility of the big picture

If I had to do the same for developers;

• Writing clean, understandable, optimized code with enough comments
• Complying with technical standards of the project and global best practices
• Re-using code whenever possible
• Maximizing information flow with co-workers and the architect
• Finishing tasks on time
• Supporting tests and correcting bugs
• Consult the architect on uncertain cases

Pre-Sales

This is the case where the consulting company wants to sell a product or service to a potential client.

In such cases, presence of the architect is more than welcome due to a lot of reasons; of which some are listed below:

• Knowledge of the architect would positively influence the client
• An architect can conclude technical discussions with the client’s employees rather quickly
• In case a demo application is needed, an architect can understand, plan and implement it very well; demonstrating the technical muscle of the consulting company
• An architect can inform the sales team of technical limitations and regulations; proactively stopping them from making unfulfillable promises
• Accuracy of development time estimations would increase

Conclusion

The picture I painted in this article is far from complete; however, I think that it gave you the overall insight you needed. In summary; you can imagine the developers like construction workers, and the software architect like a, well, architect (doh).

Advertisement