What do we mean by OSS orgitechture?

Image credit: Ico Maker | Shutterstock.com

I have been focusing on ways to improve the OSS transformation process with these two articles: 7 models for achieving startup-like efficiency for larger OSS transformations and speeding up the transition from OSS PoC to getting the solution into production, specifically strategies for absorbing an OSS PoC into production.

Both of these posts talk about the speed of getting things done outside the bureaucracy of big operators, big networks and big OSS. Today, as the post title suggests, we’re going to look at orgitechture – how re-designing the structure and culture of an organisation can help streamline digital transformations.

Do you agree with the premise that smaller entities (e.g. Agile autonomous groups, partners, consultants, etc) can get OSS tasks done more efficiently when operating at arms-length of the larger entity (e.g. the carrier)? I believe that this is a first principle of physics at play. 

If you’ve worked under this arms-length arrangement in the past, you’ll also know that at some point those delivery outcomes need to get integrated back into the big entity. It’s what we referred to yesterday as absorption, where the level of integration effort falls on a continuum between minimally absorbed to fully absorbed. 

OSS orgitechture is the re-architecture of the people, processes, culture and org structure to better allow for the absorption process. In the past, all the safety-checks (eg security, approvals, ops handover, etc) were designed on the assumption that internal teams were doing the work. They’re not always a great fit, especially when it comes to documentation review and approval. 

For example, I have a belief that the effectiveness of documentation review and approval is inversely proportional to the number of reviewers (in most, but not all cases). Unfortunately, when an external entity is delivering, there tends to be inherently less trust than if an internal entity was delivering. As such, the safety-checks increase.

Another example is when the large organisation uses Agile delivery models, but use supply partners to deliver scope of works. The partners are able to assign effort in a sequential/waterfall manner, but can be delayed by only getting time-slices of attention from client’s staff (ie resources are available according to Agile sprint planning).

Security and cutover planning mechanisms such as Change Review Boards (CRB) have also been designed around old internal delivery models. They also need to be reconsidered to facilitate a pipeline of externally-implemented change.

Perhaps the biggest orgitechture factor is in getting multiple internal business units to work together effectively. In the old world we needed all the business units to reach consensus for a new product to come to market. Sales/Marketing/Products had to work with OSS/IT and Networks. Each of these units tend to have vastly different cultures and different cadences for getting their tasks done.

Delivering a new product was as much an organisational challenge as it was a technical challenge and often took months. Those times-to-market are not feasible in a world of software where competitive advantages are fleeting. External entities can potentially help or hinder these timeframes. Careful design of small autonomous teams have the potential to improve abstraction at the interlocks, but culture remains the potential roadblock.

I’m excited by the opportunity for OSS delivery improvement coming from leveraging the gig economy. But if big OSS transformations are to make use of these efficiency gains, then we may also need to consider culture and process refinement as part of the change management.


  1. Agree to many of your points. Jebb Lewis and Have issued papers lately that is very mush addressing many of your points, as well. I do think, whether OSS or BSS have to be motivated by higher dimensions i.e. business model innovation. For argument sake, Digital for telcos operational environments (not new products or services at this stage) is primarily about integrating the operation environment in to a digital ecosystem. That is a major technology re-architecture effort. All the automated Business processes will be broken in a digital ecosystem. They are simply not designed for ecosystem flow through. OpenAPIs alone is simply not enough. Organisation issues are not a technology domain but business model and innovation vs. operation dilemma.

  2. Hi Cato,

    Thanks for your valuable feedback.
    Do you have links to the papers you’ve issued as referenced above? Drop me a PM over at PassionateAboutOSS.com if you’d prefer not to link them here.

    You make some really valid points. Your point/s about digital transformation highlighted an extra item that I hadn’t previously listed in the post, which relates to omni-channel models that have become more prevalent with digital transformations (and are often well-suited to partnership models).

  3. Telco as a service microservices model will eventually prevail where product vs service relationships will emerge. Advance agile tech will need to feed into a service of capabilities an operation requires to thrive as a CSP

  4. Hi Ehtisham,

    You’re right! The telco as a service / network as a service model is exciting indeed. I helped with the early stages of a NaaS project for a tier-one telco and it’s been one of my most interesting projects in the last few years.
    It gave a great insight into just how much telco business models and orgitectures are going to have to change to be able to cope with TaaS / NaaS efficiently.

    Thanks for your feedback!

What do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.