As part of the product analysis methods, I was discussing that besides the product breakdown splitting a product into separate components for MVP and MBI/MMF and the requirements analysis splitting stories into smaller chunks for estimation and delivery, the model based system engineering (MBSE) concepts, such as the system engineering, systems analysis, value engineering, and value analysis, are tightly integrated looking at the technical subsystem as nucleus of a secure, safe, stable, and sustainable product. Some of the familiar concepts of model based system engineering were unclear which is foundational to product development as emphasized by the agile principle, "Business and Technical stakeholders must work together daily!" While each industry may create different models depending on the specific products and its impact on clients and customers, a few generic MBSE concepts apply in all the industries.
The MBSE concept is analogous to the fable that I heard in India about six blind children touching an elephant and describing the elephant. If elephant is the system and the blind children are the various stakeholders, we are describing the system from what we think we see/feel. Security, for instance, has a different meaning for the technical team members compared to the end users.
For simplicity, let us define the model as a feature-box (functional requirements and non-functional specifications) that adequately represents the set of inputs that can interface requiring the model to prioritize and the set of outputs it will generate. The model's behavior is controlled by a set of complex rules that are manageable. This model now represents the system that must be viewed closely and from far! This requires the system architect not only to see the auditability of the system for diagnosis (such as behavior, paths taken and trail left, considerations for gracious shutdown, etc.). So, how does the system analysis and system engineering differ?
The system analyst will use a combination of techniques (e.g.: data modeling, interface analysis, data flow diagram, and alerts & event triggers) to refine the model! This is reviewing the model at a close distance. So, the system analyst frequently will consider using class diagram, functional decomposition, sequence diagram, network diagram, entity-relationship model, and deployment diagram as well as the total-quality-management (TQM) foundations like the flowchart, scatter diagram, checklist, root cause analysis, and histogram. But, the system engineering discipline observes the model from a long distance.
Therefore the system engineer focuses on interference defining the boundary of the system (where the system can no longer sustain itself to be valuable), behaviors that exposes the system's vulnerabilities (model is no longer safe or secure without subjecting itself for damage or causing harm to others). The system engineer then uses market analysis, business rules analysis, concept modeling, scenario analysis, risk analysis, state modeling, interface analysis, decision-modeling, Gemba Walks, workshops, focus interviewing, SWOT/TOWS analysis, benchmarking, and brainstorming further supplemented by TQM techniques like control chart and pareto charts. Please note that these are additional techniques beyond the techniques used in the system analysis.
Now, both the system analysis and system engineering concepts can be extended to the extent of benefit (value) derived by the users and the performing organization. These values can be looked at from multiple angles. One approach is the approach that I normally recommend as custom value, business value, technical value, and process value (Rajagopalan, 2019). The goal of these exercises are not only to protect the customers and business but also look at efficiency gains through the combination of both the process and technical value giving a competitive market value! When all these areas are reasonably protected, they also enhance the future value (that can be measured using ROI, NPV, IRR) of the product within the product portfolio. The short-term focus will be value analysis and the long term focus will be value engineering.
Another lens, that in my humble opinion, extends from the previous discussions is how the model is sustained and supported. From this lens, we can evaluate model from flow (hence Lean), governance (hence Change Management), behavior (Systems Engineering and Value Engineering concepts mentioned earlier) and decision-making (hence Risk Management discipline, Costing Principles, and Costs of Quality considerations). A few refinements are required here.
- Flow is often thought of as work progressing across the various status. This is horizontal flow. Flow also should be looked at vertically between projects, programs, and portfolios and multiple systems or projects that have to work together.
- Change Management concepts extend in such vertical value flow in terms of risk management, decision-making, funding, and resource planning that happens in program management, PI planning in scaling agile approaches, etc.
- Governance can be supported at a lower level with workflows that enable faster decision-making and system traceability & auditability.
- Behavior can vary very widely depending on the organizational processes as well as the maturity/direction required by the team. Hence, it could range from as simple as time tracking, waiting time evaluation, burn rate as well as evaluating negotiation considerations, team health, conflict resolution, etc.
- The decision-making can be supported by some of the governance considerations but it could also transcend other work authorization systems based on extensive funding considerations (e.g.: Efficient Frontier, portfolio balancing, resource optimization, etc.).
References
Rajagopalan, S. (2019). Requirements Management: A value mapping exercise. https://agilesriram.blogspot.com/2019/02/requirements-management-value-mapping.html
