Imagine you’re in a bustling professional kitchen. The heat, the noise, the coordinated chaos. This is a lot like software development, and you’re about to see why.
Get your introduction to the concept and benefits of Domain-Specific Languages (DSLs). It’s quite a topic, but this culinary journey will make it, well, digestible.
Amuse-Bouche (Software Development through Cooking): Welcome to the kitchen, where every role, from the head chef to the dishwasher, has a counterpart in a software development team.
Appetizer (Recipes do change with Time): Just as orders in a kitchen can change based on customer feedback or ingredient availability, tasks in software development are also adjusted in response to feedback and constraints.
Main Course (Managing Complexity for a growing Kitchen): As our kitchen grows, we need tools and techniques to manage the complexity. Imagine a Kitchen Modeling Language (KitchenML) that helps us coordinate all the moving parts.
Dessert: Finally, let’s reflect on our journey. We’ve seen how a kitchen and a software development team can be similar, but also how they differ. One is physical and sequential, the other virtual and iterative.
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.
OCL, the Object Constraint Language, is a powerful expression language for UML, SysML, and other languages based on UML. Unfortunately, there is no good documentation around for using OCL inside tools like MagicDraw and such. But, at least we have some input from which we can extract most important aspects.
Here is my link collection on OCL. The bad news are, this stuff is pretty old and it also varies in its statements. Either nobody is really working on it as a core module anymore or we just cannot find fresh insights here. Feel free to write me if you find any better resources.
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)
“In einer Zeit, in der die Beschleunigung der Entwicklungs- und Release-Zyklen für viele Bereiche des Business zu einem entscheidenden Wettbewerbsfaktor geworden ist, wird das altbekannte Dilemma zwischen Geschwindigkeit und Qualität weiter auf die Spitze getrieben. Mit ganzheitlichen Herangehensweisen zur Umsetzung von Continuous Delivery hat sich hier im Softwareentwicklungsprozess im vergangenen Jahrzehnt mit der Nutzung von DevOps-Ansätzen bereits einiges getan.“
Nachfolgende Abbildung veranschaulicht die Rundreise mit ihren Phasen rund um involvierte Tools zu den Disziplinen Requirement Management, Requirement Engineering, Output Management und Test Management.
