blogUdoNink

Category: architecture

  • Will MBSE Benefit from Textual Notation?

    Model-Based Systems Engineering (MBSE) is evolving, and a key question arises: Will MBSE benefit from textual notation? The answer is a resounding yes, but it is not the whole story. Graphical representations and much more are still needed. Here’s why.

    Textual Notation as a Complementary Tool

    Textual notation is already a fundamental aspect of many basic modeling tools. Languages like PlantUML and Mermaid derive graphical representations from textual descriptions, making it easier for engineers to visualize their models. Similarly, domain-specific languages (DSLs) like Franca IDL being integrated into modeling tools like MagicDraw have proven effective. These tools allow users to either code or draw, integrating seamlessly with other model content, providing flexibility and ease of use.

    The Emergence of Two-Way Solutions

    Advanced tools are taking this integration further. For instance, sophisticated tools like MagicDraw now offer two-way translations between SysML v2 textual notation and graphical representations. This functionality allows for editing on both sides, akin to how markdown plugins work in VSCode. Such advancements are critical as they cater to both textual and graphical preferences, ensuring broader acceptance and usability.

    Bridging the Gap Between Coders and Modelers

    Textual notations are particularly appealing to those who are closer to coding. For coders, the familiarity of textual input can significantly lower the barrier to entry into the modeling world. Integrating textual notations into Integrated Development Environments (IDEs) where coding happens can streamline workflows and enhance productivity.

    However, for managers, architects, designers, and analysts, graphical representations, output management, and comprehensive lists consistent with models are crucial. Therefore, to effectively engage both technical and non-technical stakeholders, providing a combination of textual notations and corresponding graphical representations is essential.

    Addressing Broader Needs

    Reflecting on over a decade of experience in automotive projects, it is clear that MBSE must address a range of needs to be truly successful and widely accepted. Models must encompass various aspects such as cross-product, cross-solution, product solutions, functional modeling, system architecture, software architecture, and boardnet modeling.

    Additionally, the existing model content in UML and SysML v1 predominantly features graphical representations. Transitioning to textual notations won’t happen overnight. The need for tool integration is paramount. The enterprise environment is a complex network of tools for planning, requirements, system modeling, simulation, test management, and implementation. Tool content is often replicated between neighboring tools or linked, necessitating seamless integration.

    Machine-Readable Models and Analytics

    Models that are not machine-readable are essentially ineffective, serving only as “marketing” diagrams. Ensuring that models are machine-readable and providing model analytics, such as making model content available to tools like Tableau, is highly valued by business users.

    Conclusion

    In conclusion, textual representation like SysML v2 is foundational and will significantly benefit MBSE. However, it must complement diagramming and address other critical needs to be truly effective. The standards are in place, and now it’s time for the tool business to catch up. By embracing both textual and graphical representations, and addressing the diverse needs of stakeholders, MBSE can achieve greater acceptance and success.

  • Tool Styles for Architecture

    #architecture #clarity #velocity #direction #enterprise #modeling

    When doing enterprise architecture as well as systems engineering (or system architecture in detail) the question arises if there can be one meta model like Archimate and one tool that does it all.

    That means, supporting the strategic portfolio level (comparable to city planning) as well as the development-oriented system level (architecture for one building at a time).

    Roles vs Tool Styles

    A very important requirement if talking about ‘enterprise’ is easy access to the captured landscape and its building blocks if for business products, applications, data, or technology as well as blueprints, planned architectures, and governance. This access must be provided for a range of users comprised by many people in the enterprise very probably having various roles and skills.

    Since all this architectural information shall not only be consumed but also improved and maintained in a distributed fashion, it becomes clear that a tool focusing on diagram-first modeling style cannot be the answer no matter if based on UML, SysML, Archimate, or any other formal modeling language. The reason is that most of the users are not able to model and only a fraction can be taught due to the costs. Mostly, the focus lies on roles already having a certain skill set you can easily build upon, i.e., mostly roles matching the word ‘architect’. Prominent examples of such expert tools are MagicDraw (Cameo) by No Magic (now Dassault Systèmes), ARIS Architect by Software AG, Adonis by BOC, Innovator by MID, Enterprise Architect by Sparx, and others. But, as we will see, any of these can be part of your overall story.

    Since the average user needs a tool that makes live easier and not harder, most EA tool vendors have focused on an approach that is data-first ERP style – typically providing web-based access to collected portfolio information (products, applications, business objects, technologies, and such). That information is presented as profiles or sheets like for each application which can also be updated via data forms. Tools like Alfabet (planningIT) by Software AG, LeanIX by LeanIX, LUY by iteratec, ADOIT by BOC, and others follow this path. From the captured data, they automatically produce dynamic graphical or tabular reports. Some of these tools also support Archimate ranging from basic import over addition to their own metamodels to own metamodels based on Archimate.

    But why do EA tools always provide more than Archimate provides? This is because many important aspects in daily life are missing in Archimate like roles and permissions, multi-tenancy, life cycle information (planned, active, deactivated; generally state per date interval), portfolio planning capabilities (as-is, plan, to-be; the later with alternatives), tool integration features (requirements, publication, test management), and a lot more.

    Scaled Architecture

    On the other hand, the last decade has shown, that focusing only on the strategic portfolio level ignoring the reality on the ground easily leads to the ivory-tower syndrome producing badly accepted plans to change the IT landscape.

    In order to avoid this, it is important to couple portfolio data with refined software and hardware architectures. The portfolio acts as the common structure and its content had better reflect the software and hardware inside (compare with reporting). And that’s where the above mentioned architects come into play again. They can bridge this gap by drilling down deeper to system architecture level and even further.

    In that case, diagram-first modeling style tools for experts are more appropriate. As mentioned above, these are typically based on UML, SysML, Archimate, another modeling language, or even a combination of those. Modeling tools supporting Archimate as a dialect can make integration with enterprise architecture tools that are also supporting Archimate a little easier.

    Conclusion

    Being able to address both worlds is an important issue and not an easy task. Common meta models may help, but are not a must. More important is the ability to map high-level enterprise architecture blocks to medium-level system architecture content and that in turn to low-level system design content which can also partly be reverse engineered directly from running systems.

    There are also tools that address both tool styles like ADOIT or upcoming versions of Bpanda that might be helpful, too. Let’s call it hybrid data-diagram style. Again, it is not a must, especially if different tools are already set in the organization and shall be integrated. The options are ranging from built-in integration features like export/import capabilities to separate integration tools like Smartfacts which provides a portal merging data from different tools via OSLC or classic synchronization.

  • And now for something completely different…

    #architecture #clarity #velocity #direction 

    Architecture Modeling is like sex.
    When it’s good, it’s really really good!
    And when it’s bad, it’s still way better than nothing (or Office tools).
    (adapted from Dick Brandon)

  • Feature Lifecycle in Architecture

    #feature #lifecycle #tracing

    When changing your application landscape on a bigger scale you might have to worry about a target architecture that you can only reach with intermediate steps like per year or release. Even a high-level roadmap may be rather complex due to necessary plan changes. The following reduced example shows the core problem:

    Feature Roadmap

    As you see, applications are repeated in different time windows and so are the features they provide. Moreover, feature provisioning may change like “Duplicate Check” might move from “LegacyCRM” to “BrandnewCMR”. In addition, features themselves may change like “Search Customer” and “Search Partner” being merged into “Search Account”.

    I see people doing these things in Excel and Visio or, even worse, in Powerpoint. And everytime my hair stands up expecting a lot of waste or worse like lost COVID-19 results. Excel is a powerful thing, no doubt, but it has its limits. The right way to do such an exercise is using a proper method with a proper tool set. There are many options like application lifecycle tools, enterprise architecture management tools, and modeling tools. I will explain the core concept using a modeling tool, but it can easily be translated to other tools.

    The core concept is based on adding the notion of lifecycle or time in general to your plan elements. Each gets a begin and end date between which it is valid. Consequently, showing an application being valid from 2018 to 2022 in a plan scenario for 2025 is not valid because it is long gone. But, since applications and also features typically live for many years, we can save a lot of redundancy by reusing the same elements wherever valid which also drastically improves consistency of your plan.

    Now, you can understand much better how we build the diagram from above. In fact, our database contains less elements and relations than you count on the diagram since we simply reuse them where valid.

    Plan Elements

    You may already guess the drastic improvement you can achieve in your very probably much larger scenario. It’s getting even better because we are now able to improve data quality with data validation as well as Powerpoint slides and Excel sheets by simply getting those as results of reports. We can even transfer plan data from and to other tools if necessary like for requirements management or budget planning.

  • The Power of Feature Models

    #feature #modeling #tracing #portfolio

    In the following, we will have a look where feature models can help improving management of software development.

    Example for mapping features to apps

    Definition

    In software development, a feature model is a compact representation of all the products of the Software Product Line (SPL) in terms of “features”.

    source: Wikipedia

    There are many more sources on the subject, but this simple one will suffice here.

    Manage Development using Feature Models

    In software development features are mostly implemented by code. Your development process like e.g. Scrum typically focuses on people, communication, self-organizing teams, and a running system among other things. A Scrum team sprints its own way from stories to running code. A typical question popping up looking at the big picture is:

    “How can development be managed across teams and products?”

    Cascaded agile working models like SAFe and LeSS (Scrum of Scrums) argue that architecture plays an important role and at the same time needs to be aligned with the code. How can you scale architecture from product code to product portfolio?

    Scaling Architecture from Products to Portfolio

    Imagine you need to report a KPI for sales YTD based on weekly and daily sales data from various sales apps having different sales models. Three different app teams might be involved probably using different technologies and documentation. How do we get to a common denominator helping to organize development?

    First, let’s understand the business logic regardless of technologies. The feature “KPI sales YTD” itself is agnostic of sources delivering the raw data. It provides a unified concept into which some magic transforms the feature “Timeline of sales numbers” from sources B2C and B2B.

    Having identified those features we can now organize development. The app “Sales Information System” is responsible for calculating the KPI sales YTD while the apps “Sales System B2C” and “Sales System B2B” each manage timelines of sales numbers. Development effort can now be partitioned for the teams and dependencies are known too.

    The central idea here is to find a common concept for both products and portfolio. For those managing across products and teams features are used as basic units while app teams refine those to their specific needs.

    If you need more precision e.g. in the case that the aggregation of the timelines needs to be done in several steps like export timeline, enrich timeline, and sum up timeline you can cascade features. There are good approaches refining a feature model using e.g. business functions or business data or a combination of both.

    Conclusion

    Breaking products down into features has a lot of benefits

    • Speak a common language (portfolio and products)
    • Avoid double work (deduplicate feature implementation)
    • Avoid overall waste (streamlined feature catalogue)
    • Make progress transparent (plan per feature)
    • Ease analysis (impact per feature)
    • Clearly specify changes (story per feature change)

    Feature models support improvement of software development especially in case of self-organizing product teams.