Telling my story...why I think I'm a Digital TV Expert...

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

this one I penned I 2013 but didn't publish...

So much has changed in 7 years!!

At a recent training session with a life coach, I shared my current challenge of me/my ideas not being taken too seriously and an apparent misconception in the organisation that I'm largely theoretical & academic in nature - that there's this innate resistance from people to consider new approaches. I had spent a decade overseas, gained some solid experience and knowledge (working with the best companies in the Digital TV Software field), and have come back to my home country, South Africa - where I'm interacting with most of the same people that I'd left behind over 10 years ago, having grown and matured and reached accolades that most people (in SA) will have only dreamt about...I left as an Engineer-in-Training, returned as a Senior Manager, dealing with people who were originally (10 years ago) either my team leaders or managers...Although no one says it out aloud, I'm pretty certain that people think "This guy thinks he's a big shot, coming from overseas and trying to change our ways. There's nothing wrong with our way of working, it's worked for us all this time...This best practices spiel is all theory, he's not a person of action, he's a politician - more talk, very little action!". Alas, I am anything but academic, and this post will try to clarify this misconception!

As lame as this might sound, it is well-known fact that working with human beings is really difficult! The coach hit the nail on the head that a possible reason I was facing resistance is most likely due to a mistake by senior leadership of not communicating to the rest of the organisation what my role entailed, especially in the area of introducing changes or best practices. I was probably not introduced to the company as someone who has a lot of value to offer, my positioning and expectations were not clear from the senior leadership, hence people are not sure what to make of me. Indeed this is true since I was initially interviewed for Scrum Master role, but was instead offered a Project Manager role due to my experience; and then later on in a short time, having influenced many areas, especially after resetting the project back on track, the company realised I'm more than just a Project Manager - and so moved to a Senior Program Manager Role, positioned as a Strategic Planner. But there still wasn't a clear mandate from the upper echelons of leadership to say to listen to me...nor was there outright acceptance that most of the existing processes to date were somewhat flawed; and miles away from following best practices.

My experience covers a variety of areas: Software Development, Architecture, Technical Management, Technical Leadership, Systems Integration, Engineering Management, Software Product Management, Software Project Management, Delivery & Integration Management, Agile, Scrum, Software Engineering...

I am equally passionate in all these areas, so wearing the hat of "Strategic Planner" that creates direction for Programs and sets a high level project plan into motion, is somewhat limiting the value I bring to the organisation. I can contribute to many areas in the company, but run the risk of sticking my nose in where it doesn't belong, the corporate structures preventing cross-collaboration; and the tendency of people building empires makes it really difficult to influence change; unless direction comes from the top. Being the person I am, I can't sit still and see things being run inefficiently and somewhat mismanaged - surrendering doesn't sit well with me!

So this coach strongly recommended I must tell my story every chance I get (if I'm meeting new people, etc)...that I need to tell my story so people can understand where I'm coming from, what my insights are, and get people to acknowledge the value I can bring to the team or organisation...

...so this is my attempt at telling my story...How did I get here? What makes me think I have expert knowledge worth sharing with the professional world? Why do I feel I have a sound grasp of best practices? Why am I passionate about Software Engineering? Why do I think I'm Software Management Consultant material??

• Embedded Engineer: Set-Top-Box Developer
• Systems Software Engineer: Fault-tolerant Server-Side Computing
• Entrepreneurial: Ideas to Products
• Software Architecture: Architectural Insights
• Software Testing Experiences
• Software Manager: Project, Programme & Delivery Manager
• Software Consulting: Development Processes, System Integration & General Management

Opinion: Cloud Services impact on TV

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

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

Architecture Patterns: How to design an EPG?

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

Managing Large-Scale Projects using Agile, Part 5 - Implementing a Large-Scale Architecture Model

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

This is Part 5 in my series of posts on a case study in Large-Scale Distributed Software Development using Agile Methodologies for a Digital TV Set-Top-Box project. I have covered the following topics to date:

• Part 0: Introduction: this post - Objectives
• Part 1: The Stage: What is a Large-Scale Software Development Project (LSSDP) anyway?
• Part 2: Organisational Structures for Large-Scale Software Projects
• Part 3: Implementing Large-Scale Agile/Scrum Model - Product Management Methodology
• Part 4: Implementing Large-Scale Development, Integration & Delivery Model

In this post, I'll discuss a Large-Scale Architectural Model we adopted, touching on the concepts and challenges we experienced. I have broken down this post into the following sub-topics:

• Recap the project, STB Software Stack & Organisational Structure
• Overview of the Organisational Structure around the Software Architecture
• Breakdown of the Architecture Processes, key areas of maintaining architectural integrity
• Requirements, Design & Implementation Model
• Communication Challenges (Collaboration, Reviews, Meetings, Documentation)
• Controlling Change (APIs / ICDs)
• Scaling the Roadmap - Advanced Features, Multiple Customers, Short Release Cycles