Continuity is a free cross-over drawing and modelling tool with strong support for creating model diagrams that look good on screen and on paper.

I wrote Continuity for fairly straightforward reasons. I wanted (and couldn’t find) a modelling tool that:

• Allowed the production of models that look good on screen and on paper,
• Combined the more sophisticated graphical capabilities and free-style experiences more commonly found in drawing tools with foundations and advanced capabilities in formal modelling, and
• Broke down the barriers to adoption of formal modelling faced by many real-world would-be practitioners, thereby improving the IT industry’s uptake of modelling at large and improving the quality of IT outcomes as a result.

In unrelated industries, such as building architecture or mechanical engineering, the need for modelling is fairly well understood by professionals and lay-people alike and comes in various forms. Architects use sketches, technical specification drawings, CAD models and even physical models to explore, explain and elaborate the details of an architecture to themselves and to different sets of stakeholders.

In many cases, the need for various models is enshrined in statute or professional charter requirements. The range of formality of models leveraged by such professions has parallels in the Information Technology; we too use sketches, conceptual drawings and formal models at various degrees of abstraction to describe the problems and solutions we come across.

Unlike other industries, however, formal modelling in IT suffers from an unfortunate paradox: That modelling skills take time and commitment to develop (often many years), but the advantages of modelling are not easily understood to the beginner or layperson (that is to say, unless you’ve had some experience in doing it yourself).

Formal models in IT are often about highly abstract subjects, they are less tangible and less obvious to those not in ‘the know’ than, say, models in building architecture. It is also generally accepted in our industry that professionals don’t need training in formal modelling to do their job. I find that people leverage informal, unstructured models extensively but formal modelling is much undervalued and much less common. Practitioners in IT have not yet had the benefit of well-established norms or statutes that make the need of formal models unquestionable or the skills to prepare them a necessity. All this means that it is hard to inspire the adoption of formal modelling – to find the money and people for the tools and training – amongst practitioners and management alike. The unfortunate side effect is that an endemic lack of awareness of modelling often pervades IT teams and I believe they and their outputs suffer as a result.

Practitioners in IT have not yet had the benefit of well-established norms or statutes that make the need of formal models unquestionable or the skills to prepare them a necessity Click To Tweet

Some of the key barriers to entry to formal modelling relate specifically to the tools that are available to us. These include:

• Lack of ability to produce attractive diagrams. This is the biggie. Time and again I find professionals in IT turning to informal drawing and painting tools to articulate diagrams that speak, creatively, to audiences that are not familiar with formal languages. They do this because the formal tools don’t appear to offer support for them in this endeavour. The loss here is that, at best, multiple (drawing and modelling) tools have to be leveraged and at worst the formal modelling tools get thrown out or never acquired in the first place.
• Inability to model less formally. This is useful for drawing sketches or conceptual models but, more fundamentally, is very important in allowing practitioners’ journeys in formal modelling to evolve and grow. I find inexperienced practitioners are put-off by the heavy-weight nature and hard-pressed formality of many modelling tools, which discourages them from using them. This is not to say that formal modelling language constructs can be ignored or broken at will, more that a tool should offer both informal and formal modelling opportunities to its users and encourage them to learn the differences and benefits.
• Constructs that act as a barrier to effective collaboration. For example, lack of support for centralised repositories, poor tool-interoperability and lack of in-built features that aid the collaborative process.
• Accessibility: Poor platform options and interoperability, pricey licensing.

At its core, Continuity is based on foundations in formal modelling. Out-of-the-box it supports a wide range of common, formal modelling concepts: Popular general purpose languages (e.g. the OMG’s UML and BPMN), file-based (XML) and centralised repositories (Database and soon-to-be Web API cloud-based repositories), Catalogues and Views, support for XMI model interchange with other tools, meta-model extensibility features, iteration planning and prioritisation, sophisticated structured and fuzzy searches, basic change management features and so on.

When it comes to graphics and drawing, however, this is where I really wanted capability in a modelling tool. I started Continuity with a specific view to providing features to allow – and actively support – users in creating model diagrams that look good. Continuity therefore has the feel of a drawing tool, allowing many shape manipulations and styles, diagram layers, format, diagram and properties inspectors, free-hand markup, drawing and sketching, gradient fills, 2D and 3D diagrams, rulers and guides, poster-layout guides, various paper styles and graphically-oriented extensibility features like the ability to easily define your own shape types. Continuity has productivity helpers such as shape colour formatting suggestions based on the colour-wheel and the ability to design, apply and share diagram themes (a number to get users going are provided on our web site).

I started Continuity with a specific view to providing features to allow - and actively support - users in creating model diagrams that look good. Click To Tweet

Whilst the initial release of Continuity was published in 2015, the tool has come a long way since. I have chosen to leverage a significant degree of automation in testing and release which allows me to code and publish changes quickly, often at a weekly cadence, or sometimes every few days, when features become available. I’ve been keen to ensure that the user audience has visibility of upcoming features and bug fixes through a published product backlog, and an ability to participate in suggesting and prioritising backlog items through interactions either via the Continuity web site or through the tool itself.

A significant up-coming feature – mentioned above – will be the ability to use Web API-based repositories that can be hosted either locally or in cloud IaaS to provide organisations another direction in sharing and access. Continuity has the ability to create 2D and 3D models: Currently, Perspective projection 3D diagram types are available and Isometric and Orthographic projections in the pipeline.

Continuity also has backlog items aimed at improving the user’s experience of the designer for diagram themes, extended shape graphics manipulations, extended association styles and auto-layout of diagrams as well as more modelling-oriented features like model integrity checking (but only of you want it turned on!), support for SysML, SoaML and support for model-driven software development (code reverse and forward engineering). Naturally, the priority of the graphical features has taken precedence in the last two or three years, since that’s where the main thrust of Continuity’s benefit lies.

I’ve found that the journey for new modellers generally begins with a desire to communicate to others, which means a wide range of stakeholders from technical people to executive leaders. This places stress on the practitioner to produce different modelling outputs for a wide audience and it is helpful if this can be achieved in one tool.

The lack of opportunities to beautify or present models in conceptual rather than formal syntax has pushed some away from modelling tools because the perceived benefits of formal modelling were not higher than the perceived loss of time and expense in having to use two or more tools to communicate to stakeholders. This, coupled with the high prices often charged for formal modelling tools, means many practitioners don’t even start the journey. Once on the journey, however, there almost always seems to come a point whereby the practitioner realises that a core benefit of formal modelling is in helping them do *their* job, without necessarily touching on the need to communicate.

Using formal modelling in IT is a bit like a plumber using a wrench – a tool for the job. Use of formal modelling helps the practitioner understand the landscape they find themselves in; to identify pertinent questions to ask, to find answers to questions other people have, to have confidence in the answers they find. Once people get to this stage, I often find they stick with modelling in their career and begin to understand — and actively support — the advantages of model-based rather than document-based ways of working and experience a step-up in their value. The ability to mix informal and formal modelling, selecting approaches based on fitness for purpose and knowledge of the modelling landscape’s costs and benefits, brings us closer the varied mix of techniques found in older professions and closer to quality outcomes in IT.