What I expect from a STB Architect Role...

(11-Dec-21 clearing out old drafts cache 2012-2016, articles I didn't get round to finishing) 

One of my most well read and often-sited posts, and the post that steered much of the changes I got introduced into my project was my Overview of Architecture Roles in Digital TV Projects. I have yet to change my view on the demand and need of real architects on software projects, and since my focus is on software development in Digital TV Systems, I remain unconvinced that the role is either not required, or the expectation from the role remains purely a high-level technical co-ordination or problem-solving role. I also remain totally unconvinced that Agile/Scrum calls for less focus on up-front architecture activities either.

I have worked with Digital TV Software Projects throughout my professional career, some might call this expert knowledge (although I am thinking of branching out into Cloud-Services as an attempt to remain up-to-date & current) - I have seen traditional Waterfall projects, classic Agile/Scrum small-scale projects and also managed Large-Scale Distributed Projects implementing a mix of Structured & Agile. I have been on training courses on Agile/Scrum, read most of the popular books on the subject, and haven't found much evidence that speaks against following at least some rigour when it comes to Software/Systems Architecture. 

This post is about sharing some of the activities that I've come to expect from a STB Architect Role, by building on the high level requirements that I introduced in the original post on Architect Roles:

[RECAP typical STB Architecture Stack]

[HAL / CDI Layer - broad profile / review / etc]

[Basic STB Architecture building blocks:

- device memory map

- device hard disk partitioning

- device hard disk management

- component interfaces

- component communications

- interface patterns / protocols

- software classes / framework - base classes

- use cases: Product Use Case - System Use Case - Feature Use Case - Functional Component Use Case, etc

- tracking memory management

- tracking stability

- assisting in defect triage / classification

- security aspects - kernel hardening, etc

- open source knowledge

- co-ordinating technical discussions, not doing the technical debugging - but advising/co-ordinating

- managing vendor expectations

- future looking roadmap features

- works on multiple projects & activities at once

- excellent time management & documentation skills

- high level design - UML

- interface control definitions