This post was written after a discussion with a co-worker on the most suitable (yet adaptable) model for large-scale enterprise product development from architectural, team & technical perspectives.

Starting Out

Firstly, let’s think about our goals when forming a strategic model for a new product or service:

• Build a relevant & adaptable product that will scale with user growth.
• Build or extend a team to help you when that growth happens.
• Keep that team happy, collaborative & productive, after all, collaborative teams are productive teams.

And from a practical perspective, how to achieve that:

• Know that architectural decisions & team strategy are directly linked.
• Empower your team with upfront standards, tooling, mentorship & clear deliverables.
• Consider containerised, micro-services-first approach in order to unbind yourself from specific frameworks & languages.
• Be ready for next.
• Deployment first.

Deployment In Strategy

The rise in adoption of continuous integration & delivery over recent years has provided software companies a competitive advantage by being able to build pipelines that allow them to iterate fast and deliver value to customers by releasing live to to production in minutes, not days, so absolutely deployment in strategy. In fact, DevOps everywhere!

2008: You release every two weeks? How agile!

2019: We need that feature live in about 15 minutes. Kthxbye!

Of course, it depends on what you’re building and your target audience, but if you are creating a commercial application and you have competitors and/or customers with high expectations (who doesn’t?), having the ability to adapt, change & innovate is key to the success of your product.  Although this has pretty much always been the case, improved tooling and technologies mean your competitors will gain advantages if you can’t keep pace with change.

So that’s all well and good in theory, and you already know that DevOps is an important part of any software team, but isn’t that going to be quite hard to do at scale, and with the rapidly changing pace of technology?

Yes, that’s where we start to look at the piece between software and DevOps: stack abstraction through containerisation!

But let’s not go straight there…

Development Approaches

When it comes to specific software development techniques, the industry moves so fast, that while a seasoned professional should be able to speak confidently about most technologies, even the most experienced developer or team lead can’t profess to know it all.

This has led to a shift in development approach from single-platform/framework, dictated by the technical lead, through to polyglot architecture (still defined by the technical lead, but slightly less of a dictatorship!)

Here’s an anecdotal timeline of architecture trends in commercial software development:

2007: Proprietary all the way (letting developers in)

2010: A healthy mix of propitiatory & open source with API

2012: API first design

2016: API driven micro-services, improved CI/CD

2019: As above, but containerised & pro-polyglot!

Where to start?

So building a solid team is underpinned by platform & DevOps, even if there are just a few of us?

Processes & Systems

If you have the resources,build our your process with maximum visibility in mind so you can get out of your team’s way and let them do their jobs, setting clear and transparent expectations and deliverables. If you don’t have the resources, do exactly the same! Build out your model as if you do, if you can commit the time upfront.

There are plenty of tools available to help a startup match the tech stack & pipeline of a fortune 500 company. It’s an even playing field.

Team Formation

So, to the team formation part…

As Patrick Lencioni says in “Five Dysfunctions of a Team“:

Not finance, not strategy, not technology, it’s teamwork that remains the ultimate competitive advantage.

A technical leader should understand the various different approaches to building a scaleable & maintainable development model, from both a technical and team perspective, and select the programming model and tenancy model is a crucial part of building a team that gels.

The rest, DevOps, feature planning, etc., can then fall into place. I’m not going to cover that in this article!

So, here are three approaches for structuring your teams at the highest level:

Architectural Strategies

Polyglotism Architecture (Free-for-all)

Letting your team develop the solutions your business needs using the technologies they are best at. This is a scary solution for leaders, both technical and non-technical, due to the fact that that it might not always be easy to maintain the skillsets required to maintain your products.

Upsides: Your team is free to use the skills they’re most comfortable with. Your team will probably be happier, programming with the tech they love, and you’ll get a better product.

Downsides: Skill fragmentation, hard to manage, DevOps role is crucial to keep some control over project, so might not suit everyone.

Platform Architecture (controlled free-for-all)

This model involves selecting a core platform which will accommodate most of your needs, but doesn’t restrict your business to a technology per application within your business. With Docker support in Windows Server 2016, this approach is becoming increasingly popular in corporations, as well as small teams.

This way, your team are slightly more free (than using a specific language or stack) to create on their own terms, but having a defined platform at the base provides a little more structure and organisation.

It’s almost the opposite to the free-for-all approach described above and makes things easier to manage under a single platform.

Upsides: Be less fussy about the talent you hire, easier to maintain with common base

Downsides: Might not suit smaller teams

Propitiatory Architecture (closed)

Closed (or vendor specific) software gets a bad name in 2018, but if done correctly and opened up to developers, it can be the right choice in many situations, especially when building a platform.

Upsides: Go deep with industry specific features, entire team on same stack, easier management, better stability if everyone in the team can support it

Downsides: Vendor locking, technology locking, harder to change if entire platform is based on one technology.

Overall, my core values remain consistent throughout the years:

• Build to scale & pivot.
• Team foundations & values are everything.

Note that my thoughts below don’t cover the product side, which is roughly covered here.