UML Operator Blog

My focus today is on launching a new "Tool" or "Major Version of a Tool". I am not a big fan of Humans or Human Nature, but we must embrace it. Yes, humans can be fickle, meaning they are inconstant and unreliable because they change their minds frequently. And yes, I am "human" too, and constantly challenged by my own human nature. Moving to any major platform release can be a challenge. We tend to let ourselves get in the way of progress. The top three things are: Human Nature to be Negative to Change Slowing down progress is frustrating and costly (money and labor/energy) Learning "new" things Learning "new" things may not be necessary. However, doing old things and potentially learning new approaches can be beneficial. This is where I embrace change, and often look forward to changes! This gets my creative juices flowing. Make Learning Rewarding When we are forced to move from the mundane, mindless, and repetitive motions, we are fo...

I get asked, quite often, "Is there a way to integrate Sparx Enterprise Architect (EA) with other tooling?" My answer is always, "Yes". There are multiple approaches, from very simple to more advanced. I have helped several shops do this over the years, and may do videos on this in the future. Integrating Sparx with Azure DevOps and other Cloud platforms, as well as other Tooling, is very possible and beneficial for managing delivery, such as requirements, problem solving, design, and development... all in a unified way.  The integration can allow companies/shops to seamlessly synchronize between Sparx EA's modeling environment and platforms, such as Azure DevOps'. Remember that one of the biggest benefits of Sparx EA over other modeling platforms, is that Sparx is based on Data-First implementation and supports open integration. Years ago, something call Open Services for Lifecycle Collaboration (OSLC) came out and Sparx was one of the first to embrace it. ...

The problem with most diagrams, whiteboards, drawings, and presentations, is that they "dazzle" but do not have "dazzling results". Maybe I should title this post as, "Dazzling Results Don't Lead to Dazzling Outcomes". The whole purpose of documenting things is to "remember things", to "communicate things", or to "reuse and deliver things better and faster". In the UML Operator Channel , we talk about and demonstrate Modeling. As a Systems and Software Architect and Engineer, I have seen the good and bad in documenting and collaborating on things . Drawing Tools vs Modeling Tools There are many "drawing tools" in the marketplace today. Tools such as Draw.io, Lucidchart, and more. These are amazing and simple tools, and I use them quite often. However, they are not very good at "documenting" and only...sometimes...result in nice "drawings". I often have to ask the team, "So what does this ...