After many years of experience in software engineering, I ask myself what the key factor that accelerates software development projects is. Without any doubt, applying thorough modeling methodologies is my personal answer to this question.

When talking about modeling in engineering, people usually have diagramming and drawing tools in mind. Others immediately think of large, and soon to become outdated, UML models that developers create before implementing software in a programming language. With limited experience in successful use of modeling techniques, many people are reluctant to creating formal models or have experienced its sometimes dogmatic use for documentation purpose. Additionally, too often, there is a gap between terminologies used by engineers and the ones used by domain practitioners or business experts.

Focusing on the use of models for communicating among stakeholders and also in the interaction with technical systems, essentially, modeling is the art of creating a language. A concise language which is used to express the reality as it is or as it should be. Not the entire reality, but just the parts of it that are relevant from a specific perspective. Now, what does that look like in practice? Let us examine three fields that strongly leverage modeling as defined above.

The first field or methodology is enterprise architecture (EA). EA is used by IT managers to align the business activities of a company with information technology. EA initiatives or projects should always start at the highest management level, as they are an important instrument for strategy implementation. Looking at the numerous elaborate EA frameworks, a typical structure of an enterprise architecture covers the following architectural layers:

  • Business and IT Strategy

  • Business Architecture

  • IT Architecture (Application & Data Architecture, Technology, Infrastructure)

Assuming the strategy is given, the business architecture description details the processes and information needed to implement this strategy. Further, the IT architecture maps these business elements (e.g. “procurement”, “CRM” or “accounting”) onto the layer of technical systems which provide the required capabilities (e.g. in form of concrete software applications) to the layer above. Additionally to these stacked layers, there is the important vertical layer "security architecture" that focuses on information security throughout an enterprise. Covering all these different aspects, such an EA model for a company clarifies the terminology to be used in communication among involved stakeholders and herewith defines a common language. This is of inestimable value, because it prevents misunderstandings that often lead to unnecessary additional iterations during implementation or, even worse, to late changes of system requirements.

The next field of modeling is domain-driven design (DDD). This methodology particularly addresses the creation of software systems. Contrarily to methods for designing the software code on a technical level, it targets at the understanding of the software domain, i.e. the real world problems to be solved or the processes to be automated by the software. Designing the domain model (e.g. travel booking) shall result in a precise language (with terms such as “itinerary” or “departure date”) that can be used in communication between domain experts, designers, and developers. Whether this language is based on graphical (e.g. diagrams) or textual (e.g. use cases) artefacts is not deciding, but it is key that its terminology is commonly understood and ubiquitously used by the mentioned roles. Based on my experience of many small and large software projects, modeling shall not be degraded to be just an investment for potential later advantages, because it does not only pay off in the long-run, but very quickly.

The third field of modeling methodology, model-driven software development (MDSD), consequently expands the usage of formal models for creating software by introducing the concept of so-called “domain-specific languages” (DSLs). By the means of DSLs, one can express the models not only in a way understandable by human stakeholders, but they also can be automatically translated into runnable software. For example, if the business processes in one of your specific business domains are expressed with the formalism of a DSL, modifying the details of a process implies an automatic regeneration of the corresponding implementation. Consequently, one could argue that the model in fact “is” the implementation. As the code just can be regenerated automatically, this approach easily handles changing requirements affecting the models, even late in the software development process. While the methodology and its corresponding tools have matured over the past years, it is still crucial to wisely select the parts of the system that are eligible to be generated. In general, the MDSD approach shall be introduced first on technical domains before leveraging it for business domains, in order to let people gain experience in their new roles and for smoothly adapting the related development processes.

Eventually, let us come back to the introductory question about the key factor that accelerates software engineering projects. Larger projects are almost always staffed heterogeneously with people experienced in many different areas. For example, software development projects require domain practitioners, software engineers and project managers. Inherently, this situation introduces the challenge of finding a common language understood by all project members. As described above, there are numerous mature modeling methodologies that help to prevent extra rounds of clarification and revaluation due to misunderstandings among stakeholders. Should you face such a challenge in your projects or just want to further accelerate them, contact Acrea, and we will collectively develop a concise language specific to your domain and ubiquitously spoken in your organization.