Start enterprise modeling with domain models

Who is domain modeling for?

You are an enterprise/solutions architect leading a development team of software and systems engineers. You have been tasked with defining and establishing the standard and best practices (methodology) for the team and for the department. You are in the process of adopting MBSE, SysML, and other modeling languages and tools, so you are organizing the trainings for your team members, working on enrolling other teams in the adoption, and to top it all off, you are in charge of "architecting" the enterprise and establishing the blueprint and framework for system architecture in the model-based environment.

What exactly are your skills?

If you are an employer looking for someone like that, what do you write in the position's requisition?

What is domain modeling for?

Obviously, as an enterprise modeler, you must be above and beyond being experienced at SysML and UML modeling. Yes, you have accumulated a few framework certifications and black belts in Agile and all sorts of "BOK" programs. But in the end, none of those equip you with the specific knowledge and skills that a head enterprise architect requires to fulfill all of the above requirements.

In that "enterprise architect" role, you will work with advanced and "meta" practices. A meta practice is a practice for designing practices, frameworks, and toolsets for other roles in the team or organization. Your purview of systems engineering and enterprise software development focuses on the backdrop, the developer's superstructure and infrastructure, before system architecture. Your role is similar to that of a process control engineer who fine-tunes the factory and optimizes the facilities for other engineers and technicians to operate in.

One of your superpowers is "domain modeling." This is what this post will introduce you to.

Every engineered system is built to serve within a specific domain of practice. For example, a system that aids in mission planning could exist within the domain or spaceflight in the astronautics industry, or within the domain of battlefield in warfare.

Domain models establish the relevant ontological space around the system under consideration. Ontological refers to the linguistic framework as the basis for what something is. What it "does" falls under functionality. Therefore, the domain model constrains communication amongst stakeholders, technical and business, to a small, finite set of fundamental concepts that are specific to the domain.

For instance, the domain of battlefield is modeled in terms of a location of ground warfare, terrain, the point of contact between opposing forces, and the strategic importance of the geographical location. That domain model could be further extended to include "multi-domain battlefield", which is the interconnection of multiple battlefield ranges of concern.

Domain modeling requires a domain-specific language (DSL)

"A DSL is a computer language specialized to a particular application domain. This is in contrast to a general-purpose language (GPL), which is broadly applicable across domains." (Wikipedia)

Your internal development standard determines whether the modeling strategy requires DSLs, or a general purpose language such as the Unified Modeling Language (UML), in order to model the baseline for building systems and enterprise applications in the company you work for. The choice between the two will depend on whether a project can greatly benefit from a DSL. There is a high cost associated with developing, or adopting, a DSL in-house and must be accounted for in your enterprise technology investment plan. A central component of this cost is the high pay rate that companies are willing to spend for hiring someone with the skills and meta practices mentioned in this post.

The strategic value of domain models

Generally speaking, DSLs offer great value in model-driven development environments. They are the basis for generative technology. Model-driven development is an advanced extension of model-based development where models at higher semantic levels are utilized to generate downstream models—e.g., design and implementation models—and eventually, software code. Model Driven Architecture (MDA) is the standard for model-driven development.

Other application areas for DSLs are projects building enterprise software applications for a specific profession, say accounting, or a specific domain, such as Enterprise Asset Management (EAM). The idea is for the lead enterprise architect (the role) to hand application modelers the precise language that the application intends to serve. The power this grants you is, instead of thinking in terms of classes, associations, and parts as your fundamental building blocks, you are thinking in terms of domain constructs, such as, Asset, Asset Type, Asset Management Plan, and Asset Lifecycle. The latter cuts development costs by an order of magnitude. This makes it a long term strategic investment in technology, and even, intellectual property if you were to invent your own languages.

In some cases, language invention can be appropriate for what is needed. For example, in a recent project we invented an “interaction modeling language” for application modelers to build apps based on the interactions that occur in real work scenarios, say for example, the interactions between a physician, an assistant nurse, and a patient in a clinical visit. In this manner, you can devise non-standard methods for building software apps on a behavioral basis, not system structure.

In your modeling journey, so far, you have utilized languages such as SysML, ArchiMate, and BPMN. These are “extensions” of the base modeling language UML. You can think of SysML as a domain specific language for the domain of Systems Engineering. SysML, as well as ArchiMate and BPMN were built as extensions of UML using UML Profiles for their respective domains.