Setting a challenge for clever OSS Architects

Back in the old days, there was really only one OSS build model – via big milestone/functionality delivery. You followed a waterfall style delivery where you designed the end-solution up-front, then tried to build, test and handover to that design. The business value was delivered at the end of the project (or perhaps major phases along the way). For the large operators, there may have been multiple projects in-flight at any one time, but the value was still only delivered at the end of each project.

Some clients still follow this model, particularly if they outsource build/transformation projects to suppliers. These clients tend to be smaller and have less simultaneous change underway. OSS build/transform projects tend to be occasional for these clients.

But the larger operators now tend to undertake a constant, Agile evolution of their OSS. There are constant transitions, delivery of value at a regular cadence (eg fortnightly sprints). The operating environments (and the constraints associated with them) tend to be in dynamic flow, at an ever increasing speed. There is no project end-state. The OSS simply doesn’t stay in one state for long because change is happening every day (give or take).

For this reason, I find it interesting that Architects tend to design solutions for a particular end-state. This can be a good thing because it stops Agile projects from meandering off track incrementally. 

Unfortunately, this type of traditional solution design doesn’t fully suit modern delivery though. The traditional solution design doesn’t show the many stepping-stones that delivery teams have to implement – the multiple states required to transition from current-state to end-state. I’ve seen delivery teams being unable to determine a workable sequence of stepping stones that allow the designed end-state to be reached.

So, a challenge for the many clever Architects out there – help delivery teams out by designing the stepping stones, not just the ideal end-state. Update your design templates to describe all the intermediate states and the transition steps between them.

Include diagrams, pre-requisites, dependencies, etc as you normally do, but only as bite-sized chunks for easy consumption by delivery teams rather than even more massive documents than today.

After all, those intermediate states are only experienced briefly and then gone. Obsoleted. In fact all OSS delivery states are only transitory, so we may need to re-think our document template models. Pre-build, during-build and post-build documentation requirements are all waiting to be accommodated within a stepping-stone timeline in a new style of design template.

In most cases, it’s a greater skill to navigate an OSS journey rather than simply predict a destination.

I’d love to hear from Architects and Delivery Teams regarding how you’ve overcome this challenge at your organisation! What models do you use?

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

2 Responses

  1. Hi Jeffry,
    I see a similarity In this approach and the TOGAF recommendation in the migration/transition from Legacy to Target Architecture. The Transitions can be based on Value.
    Best regards.

  2. Hi Issam,

    Really valid point! I was thinking about TOGAF’s ADM when writing the article too.
    The ADM certainly espouses an ongoing view of architecture (hence the circular ADM visualisation).
    I’m curious about whether we’re doing a lap of the ADM loop per sprint (eg 2 week cycle) or over a longer architectural timeframe (eg the length of a “project” in months)?

Leave a Reply

Your email address will not be published. Required fields are marked *

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