Scaled-Agile with Integrated System Modeling
Scaled Agile is about scaling agile product development. So how does Model-Based Systems Engineering (MBSE) and its System Modeling process enable Scaled Agile so you can start integrated and stay integrated through-out the entire product lifecycle (software and hardware)? A recent webinar by Stefan Bonnet at Thales related their experiences with both which inspired me to look deeper into how Siemens Systems Engineering solutions can enable your Agile Workflow using System Modeling Workbench solution.
System Modeling Workbench leverages Capella as its powerful modeling engine. Capella includes a tooled methodology ARCADIA (Architecture Analysis & Design Integrated Approach) to guide the product architecture development.
The ARCADIA methodology covers both the Problem and the Solution spaces through four viewpoints. Operational Analysis (OA), Systems Analysis (SA), Logical Architecture (LA), and Physical Architecture (PA). The Systems Analysis viewpoint is where the System Engineer/Architect identifies what the system needs to accomplish for the customer. The results of System Analysis directly maps to the first principle in Agile development: “Our highest priority is to satisfy the customer through early and continuous delivery of value.”
Are you not entertained?
If you’re like me, you’ve been locked down recently and are catching up with your favorite TV series. So let’s use planning an on-demand video service as an example– Amazon Prime, Youtube, Netflix, or similar…Where do you start your System Analysis? First, let’s create a Mission Capabilities Blank (MCB) diagram for our System Analysis and dive in from there…
As Netflix CEO Reed Hastings recently said “… We’re in the entertainment business”. So we create our Mission, “Commercialize entertaining of people with video”, but what capabilities would our on-demand service have to entertain people? The most basic one is “Watch a Movie” and others like “Choose Movie from Library” and more. If we consider the business stakeholder’s perspective, we’d want to “Track Movie Watching” and we keep going defining the circumstances our on-demand service would be used.
But who will use our on-demand service’s capabilities? Bring on the actors! Let’s create a Contextual System Actors (CSA) diagram:
Remember our mission is to entertain people, so let’s create a Customer actor for our Capabilities. We don’t want to forget the On-Demand Business actor either, after all – they are someone who benefits from the commercialization of our service.
Moving back to the Mission Capabilities diagram we created previously, let’s identify who is involved with which capability. All people enjoy watching a movie on-demand, but only our business person appreciates trends, so we will “involve” them accordingly.
So why all this work with Actors and Capabilities? In Scaled Agile Framework (SAFe) A Capability is a higher-level solution behavior that typically spans multiple Agile Release Trains (ARTs). What we’ve done so far in System Modeling Workbench is specify, through modeling, capabilities that provide value to some stakeholders that are to be planned for in an Agile product roadmap!
Moving on from our System Analysis, we want to articulate interaction between a person and our on-demand service. What will our System do for its stakeholders? The basic system functions could be: Stream movie, Track watched movies, Provide movie choices,… So let’s model these with the System Architecture Blank (SAB) diagram.
…then articulate in the SAB what the Person does to watch the movie, what the system does to help, and the interactions between the Person and the System as Functional exchanges.
If you ask me, “What does the system do to enable the Watch Movie capability?” I would create a Functional Chain containing the Functions and exchanges.
… and then relate to the capability it describes.
Woohlah! We now have a clear description of what the system must do in its interaction with the Person to watch a movie. But all this work and for what? SAFe goes further and explains that for a software team to develop a Capability, it must first be broken into a feature. How do “features” relate to System Modeling Workbench? The inspirational webinar further explains that the Capability’s Functional Chain and relevant Requirements from the model specify the Feature, an increment of value:
So there you have it, you’ve modeled a high-level feature specification for which is then planned for development in a timebox called a Program Increment in Agile SAFe. Are you not entertained?
Bam! Let’s Kick it Up a Notch
What is not spoken to in this blog is how the solution, defined by Logical and Physical Architecture in System Modeling Workbench, realizes the System Analysis to identify the key components, behaviors, and interfaces that will be developed. The Functional Chain, modeled in System Analysis, is fully traceable to these sets of elements, in fact, providing the expected vertical slice of work to be designed, developed and tested for.
You might be thinking that’s a lot of work for something so simple, of course, this goes well beyond software to the systems running the software and system interacting with the outside world. Imagine scaling this to an airplane and air traffic control system or a refinery and a logistics system. You must think this way if you expect that the software your developing will work with the system it was designed for.
Are you interested in this topic? We have a bunch more, check out the rest of the MBSE blogs we have.
