Tag: architecture

Beyond the T-shaped person: becoming star shaped

Kris

The T-shaped career model suggests that a person should have a depth of skills in a single field (the vertical bar) and a breadth of skills that enable cross-disciplinary collaboration (the horizontal bar). However to me, excelling in one area and being merely ok in a number of others feels too limiting for this agile, adaptable era of computing. It also risks becoming obsolete due to over-specialisation as the world changes.

T shaped person - breadth of skills as the bar, depth of expertise as the downstroke

I don’t want to be a Pi shaped person either, which simply adds another leg of expertise to the diagram. Instead of having deep expertise in one field, it’s now in two fields. An improvement as it allows for a reinvention from a legacy skill to a new skill, but still not really doing it for me.

Pi shaped person - breadth of skills as the bar, depth of expertise as the two downstrokes

There are variants on the model that I prefer, including the ‘V-shaped’ versatilist described by Pete Cripps.

V shaped person - broader cross discipline skills, getting narrower as expertise grows

The versatilist approach does however illuminate the very thing that bothers me with all of this. The skills development journey in all of these diagrams is towards a fixed point of deep expertise.

By contrast, I feel like I’m floating in a galaxy of fascinating topics, and I need deep expertise in many of them to be able to deliver success for my projects and clients in a rapidly changing world. Of course I’m not going to be a polymath, deeply skilled in entirely diverse disciplines (rocket science and brain surgery?), but the skills I use span across traditional disciplines, mixing IT architecture, UX design, programming, marketing, project planning, security and more to deliver successful outcomes.

I’d like to propose an alternative approach to the T-shaped person that captures how I’m growing my skills as a star-shaped person.

star shaped person - skills growing outward into many different domains

I aim to create a map of my skills, using a polar graph instead of the traditional XY axis. My skills are growing outward in all directions with the arrow length reflecting the level of expertise, and the direction indicating the domain of skill. Areas of the graph can be used to group similar and different skills together.

I’ve used quadrants to contrast for example creative versus analytical skills. Choosing to develop a new skill is reflected by adding in a new arrow, which may grow over time to exceed the existing skills. This dynamic development of my mix of skills over time is another facet that the T-shaped model doesn’t illustrate.

Coincidentally this symbol is author Michael Moorcock’s famous ‘Chaos Star’ symbol which I find very fitting. In a rapidly changing world, sticking to traditional, order-led, straight-line thinking no longer cuts it. To survive as IT people, we need to be adaptive, quickly growing skills and expertise in emerging areas and organically reinventing ourselves as the world changes around us.

In a follow-up post I will work through a practical example of acquiring skills using the T-shaped and star-shaped approaches.

More on Microservices – Martin Fowler article

Kris

Martin Fowler expands on what a microservices architecture is all about.

A lot of the concepts are similar to SOA, so I’m gradually trying to understand what the practical and philosophical differences (and similarities) are. Here’s one:

When building communication structures between different processes, we’ve seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying business rules.

The microservice community favours an alternative approach: smart endpoints and dumb pipes. Applications built from microservices aim to be as decoupled and as cohesive as possible – they own their own domain logic and act more as filters in the classical Unix sense – receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool.

Also I’ve been pondering services granularity and RPC vs the coarse grained calls of SOA. In this regard microservices seem closer to the SOA approach if anything:

In a monolith, the components are executing in-process and communication between them is via either method invocation or function call. The biggest issue in changing a monolith into microservices lies in changing the communication pattern. A naive conversion from in-memory method calls to RPC leads to chatty communications which don’t perform well. Instead you need to replace the fine-graining communication with a coarser -grained approach.

Are microservices made of the clear design principles of SOA but without all the heavyweight implementation details of SOAP, WS* standards, XML and all the rest of it. More reading needed!

Microservices by Paul Downey at GDS

Kris

Paul Downey at the Government Digital Service shares a interesting and visually appealing view of a proposed microservices architecture. The mix of web, APIs and systems of records looks sensible to me. Funny how we’ve gone from fine-grained RPC style webservice calls, to the coarse-grained services of SOA, back to ‘microservices‘ over the course of a few years (at least where I work …).

I do find myself wondering if the business function of the services that are exposed in a micro-architecture is actually much different from a well defined SOA service. Either way, being freed from the painful overhead of SOAP / WS-standards surely makes it much easier to contemplate building or integrating with a microservices architecture!

Microservice architecture