An evening of System Security Engineering

Some of you may know that I am a member of INCOSE, but few may be aware that I am involved in the efforts being made to create a Canada Chapter.

As part of its effort to become a registered chapter, the emergent Canada Chapter has held conferences in the past (the last one was on December 21, 2015).

There is a new event coming up on June 16 that promises “An evening of System Security Engineering” (a.k.a., SSE)!

SSE is gaining a lot of traction these days, especially with the rapid growth of the Internet of Things (IOT, or as some like to say, the Internet of Everything) and various security concerns around our infrastructures. If you are building systems, this is a topic that you can’t avoid.

Are you interested in knowing more? Have a look at the flyer and maybe you’ll want to join us!  Tickets are availble from Eventbrite and if you’re an active INCOSE member, it’s free!

I hope to see you there!



Eating the world through DSML

I borrowed this blog entry title from an interesting post in the January 2016 Eclipse Newsletter titled “How to Eat the World with DSLs.”

In that article, the author makes many good point about DSL, such as creating a language with which the users are already familiar and abstracting the more complex aspects of coding (a payroll system implemented in Excel sheet in this case) to facilitate the domain expert’s job.

The same approach can be used when dealing with the complexity of modeling. UML is known to be rather complex, but a using a DSML to represent your domain will simplify the work of your developers. Ericsson presented a good example of this at EclipseCon Europe 2014: “UML or DSML? You can now have both with Papyrus 1.0!

An advantage of using a UML-based DSML, at least in the Systems Domain, is that existing analysis tools can be used on the underlying UML model to do common functions, e.g. traceability. Using UML as the base for your DSML also allows you reuse parts of the UML that would make sense in your domain (e.g., sequence diagrams are already available for free). For other aspects, such as collaborative modeling, you would still need to do some toolsmith work to be able to present the results in the context of your DSML instead of UML. Domain experts should not have to understand the underlying implementation and must be kept at their level of abstraction!

The capability to author DSMLs is already available within Papyrus and will continue to evolve and improve as part of the newly created Papyrus Industry Consortium.

And even if you do not feel like you need to base your DSML on UML, there are other Eclipse offerings, such as Xtext (mentioned in the article referenced above, textual DSL) and Eclipse Sirius (graphical DSML based on its own metamodel).

Within Eclipse PapyrusRT, we already use Papyrus’ DSML capabilities to implement the graphical UML-RT modeling language. We are now investigating combining this with an Xtext-based representation of UML-RT to blur the line between graphics and text. Our take is that you should not limit yourselves to only textual or graphical representation – some things are easier in one or the other and, sometimes, a mix of both can be better!

With a good infrastructure to support it, DSMLs are the modeling approach of the future and is available now. You should take a closer look!

Lesson learned

Short but interesting post about project post-mortem meetings. The results, are somewhat familiar and not at all unexpected.



This is a fellow onion.
Look how sad she is.

We’d just finished, or rather abandoned, a project, so decided to do a lessons learned exercise.

These are specific lessons we learnt during the work and what we wrote on our flip charts….

1: A meeting room of people agreeing something is like a class room agreeing. Nobodies learnt, they’ve just nodded that they’ve agreed not to disagree.

2:  Policies don’t work. Nobody knows they exist, and if they do, they don’t know what’s in them, and if they do, they rightly don’t care.

3: Regular official meetings are worse than ineffective, they suck life from your bones, if you want to communicate with someone don’t “have a meeting”, just meet someone.

4: Use a hand drawn picture, it’s better than a description of something that could exist as it actually does. You can point at it and…

View original post 91 more words

How to ruin a great team

In following through How to ruin a great team, you will find a great piece about what not to do when you take over a team (soccer, in this case). The two main points I got from the original article is that a manager must be able to communicate and must be able to adapt to the culture of the team (instead of imposing his own from the start).

I believe this to be true whether you are talking about a sports team or a software/system development team!