Building Skills - Centralized Expertise - Central Practices - Centers of Excellence/Communities of Practice

This discussion is about what companies can do to upgrade technical skills and implement best practices to increase the quality and capabilities of delivery teams.  It is not discussing project management or cross-team delivery issues. This is mostly built on experience with Software Delivery and Development. The general concepts are probably valid for process teams that require multiple skills.

Delivery Team Complexity

Software delivery continues to evolve requiring ever-increasing technical expertise as system complexity, system scale, and compliance regulations increase.  Modern applications face continually evolving security threats further increasing the burden on software delivery teams.  Shift Left initiatives increase the accountability and responsibilities of the same delivery teams.  


This image shows some of the roles played by delivery teams as part of historical capabilities in addition to those added as part of You Build It You Own  Agile Dev Ops transformations.  Everyone in delivery needs to be able to support each of these roles. Team members may specialize as SMEs in some areas while maintaining basic understanding in most.

Maintaining and Distributing Required Technical Skills

Organizations can take a variety of organizational approaches to increase the skills and depth of technical teams. 
  1. Smart People will Take Care of It: Teams own their own everything.  Architecture and governance set guidelines.  There are no real best practices or skills-building groups unless they are self-organized.
    Some companies essentially upskill by only hiring experienced talent and dump the bottom 20%. Companies with this philosophy often also use the same approach for cross-project coordination and task management.
  2. Centralized Technical Matter Experts: The traditional centralized service teams that do work on demand.  TMEs are part of the central organization and support delivery teams on a ticket or per-call basis.
    People that have been around for a while should be aware of the historical pendulum of organizational changes for Centralized DBAs and System Administrators.  PaaS services in the cloud have eliminated much of the demand on these groups. Infrastructure as Code has dramatically changed the skills requirements for Operations and Developer Operations (DevOps) staff.
  3. Central Practice Matrix'd to Teams:  Technical Matter Experts are centrally managed and deployed to development teams where they act as full members.   Think of the org chart as a solid line into the practice and a dotted line to the development organizations. This is a common model for Solution Architects and System Architects.
  4. Center of Excellence Matrix'd to the Center: The Technical Matter Experts are owned/tasked solely by the development teams.  Shared services resources exist in central groups that the TMEs report to in a dotted line fashion or may report to for management purposes.  This is the inverse of the Central Practice.
  5. Community of Practice: This is a slightly more supportive version of Smart People will Take Care of It. All interaction with the CoP is voluntary. Architecture or Shared Engineering supports the CoPs and schedules regular meetings, presentations or events. Engineers have no leverage on their team to commit to the CoP or the practices of the CoP.

Video

Central Practice

This approach struggles because delivery team management feels like they have a lack of control over the resources. The policies and recommendations of the central practices are seen as impediments to faster delivery. 

Centralized practices can be pretty common for software testing, Dev/Ops common platforms, software architecture, and data modeling.  This model provides strong backing for TME activities aligned with best practices principles.  Development management tends to treat these resources as wholly owned and may intimidate the matrixed resources into doing development work in place of or out of alignment with the Central Practices principles.  

Center of Excellence (COE) or Community of Practice (COP )

This approach struggles because the Centers of Excellence and Communities of Practice are wholly dependent on the delivery team management for their effectiveness and influence.  Software Development Engineering operations are most often based on COE/COP because software developers are almost always totally under the control of the development team management.


The primary weakness of the CoE is that it can be ignored by Development Management hierarchies unless it has enforcement capabilities.  Security CoE can offer additional security training or provide competitions like Hackathons.  Software best practices CoE tend to really struggle without any type of automated software quality auditing.   Development management can deny CoE-related time and activities by de-prioritizing them against regular work.

Differences across the Towers/Stovepipes

Different departments in the same company can take completely different approaches  The following chart describes two VPs, each of which has its own organizational style which permeates their organization. 

The top organization is built with cross-cutting or matrix-style capabilities.

Click Image to Enlarge

The bottom organization is built as a set of standalone teams where each team is responsible for creating all its own expertise

Fiefdoms

Fiefdoms are organizations that take on the personality of their VP or senior management.  Each fiefdom operates in its own fashion with its own guidelines.  They completely own their own prioritizations cross-cutting concerns like compliance, governance, best practices, etc.  Fiefdom based organizations make many of the above patterns difficult.



Created 2022 04

Comments

Post a Comment

Popular posts from this blog

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

Image
I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with  gadget drivers  that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget  is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device.  All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget  in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update  or  Upd...
Read more

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Image
The Windows Subsystem for Linux operates as a virtual machine that can dynamically grow the amount of RAM to a maximum set at startup time.  Microsoft sets a default maximum RAM available to 50% of the physical memory and a swap-space that is 1/4 of the maximum WSL RAM.  You can scale those numbers up or down to allocate more or less RAM to the Linux instance. The first drawing shows the default WSL memory and swap space sizing. The images below show a developer machine that is running a dev environment in WSL2 and Docker Desktop.  Docker Desktop has two of its own WSL modules that need to be accounted for.  You can see that the memory would actually be oversubscribed, 3 x 50% if every VM used its maximum memory.  The actual amount of memory used is significantly smaller allowing every piece to fit. Click to Enlarge The second drawing shows the memory allocation on my 64GB laptop. WSL Linux defaul...
Read more

Almost PaaS Document Parsing with Tika and AWS Elastic Beanstalk

Image
The Apache Tika project provides a  library capable of parsing and extracting data and meta data from over 1000 file types.  Tika is available as a single jar file that can be included inside applications or as a deployable jar file that runs Tika as a standalone service. This blog describes deploying the Tika jar as an auto-scale service in Amazon AWS Elastic Beanstalk.  I selected Elastic Beanstalk because it supports jar based deployments without any real Infrastructure configuration. Elastic Beanstalk auto-scale should take care of scaling up and down for for the number of requests you get. Tika parses documents and extracts their text completely in memory. Tika was deployed for this blog using EC2 t2.micro instances available in the AWS free tier. t2.micro VMs are 1GB which means that you are restricted in document complexity and size. You would size your instances appropriately for your largest documents.   Preconditions An AWS account. AWS ac...
Read more