What Really Defines a Software Architect? Lessons from Tieto, Sony, and Banking

What Is an Architect and What Do They Actually Do?

There is no single definition of a software architect; the role varies across companies and projects. The author shares personal experiences to illustrate how responsibilities differ while some core principles remain constant.

Experience at Tieto (2012‑2013)

Joining Europe’s largest IT services firm during its transition from Symbian to Android, the author was tasked with two main duties:

Elevating the Android skill set of the team by forming domain‑focused sub‑groups (Framework, USB/MTP, App, BSP, Multimedia, Local Connectivity) based on expertise, project needs, and the company’s long‑term plans for sites in Beijing, Chengdu, and Poland.

Leading the team through a multi‑site Android system upgrade project, coordinating with the main project manager in Poland and the Czech site, planning work, validating milestones, and applying agile practices, regular reporting, risk alerts, and task‑force groups for high‑impact challenges.

Key takeaways from this period include the need for architects to understand the "Big Picture" of a project, identify weak points and risks early, and maintain open communication with project managers and testing teams.

Experience at Sony Mobile

As a senior architect at a world‑renowned consumer‑electronics company, the author observed a more granular division of architectural roles:

Project Architect (PA) : Acts as the technical lead, co‑creates schedules with the project manager, convenes expert reviews for critical issues, makes decisive technical decisions, and monitors risk through test reports.

System Architect (SA) : Focuses on Android system‑level concerns such as performance tuning, power consumption, crash analysis, and collaborates with the "MiB" (Man in Black) team.

Sub‑System Architect (SSA) : Owns a specific module (e.g., kernel), conducts code reviews, selects solutions, and resolves domain‑specific problems.

Verification Architect (VA) : Leads testing strategy, designs test cases, develops automation tools, and evaluates the impact of optimizations.

Although the title "architect" is shared, the actual responsibilities differ significantly across these roles.

Current Role at Minsheng Bank Technology Department

While the bank does not have a formal "architect" title, the author’s duties mirror previous responsibilities:

Designing and refining the technical specifications for the bank’s smart POS system, guiding vendors, and encouraging innovation within the standards.

Providing a comprehensive SDK and documentation to attract third‑party developers, while enforcing strict security and quality requirements for submitted applications.

Deep‑diving into critical POS functionalities (e.g., card‑payment processing) to gain mastery and enable independent development.

The work remains architect‑like, merely shifting focus from Android smartphones to smart POS devices.

Why Everyone Is an Architect in Life

The author expands the concept beyond IT, arguing that anyone who plans, executes, monitors risks, and iterates—whether organizing a national parade, publishing a book, or planning a family—acts as an architect. This mindset involves understanding the big picture, maintaining execution discipline, and exercising proactive risk awareness.

Recognizing oneself as an architect encourages deeper engagement with project goals, systematic bug analysis, and the establishment of long‑term learning standards, ultimately leading to more effective software development and personal growth.