Today, virtually every organization is a tech business or is on the path to becoming one, regardless of the product or service that it offers. Companies understand that IT and business specialists must work together as partners to achieve strategic goals and create competitive advantages. According to the Gartner forecast, by 2022, half of all companies worldwide will expand how their IT and business specialists collaborate with each other. The problem, however, is that it is not easy to harmonize these two areas.
IT-Business Collaboration Issues
Typically, business customers do not fully understand how software is developed. And only a few developers are able to describe from beginning to end how the product they are ordering should be developed, simply because software development is a very complex process. In addition, customers are often not interested in taking part in the software development process, since they have little understanding of what is happening. They prefer to leave the details to the discretion of the developers in this type of situation. As a result, customer needs are poorly understood, and they are either not taken into account by developers at all or only partially, which in turn leads not only to missed deadlines and budget overruns, but ultimately produces a system that is useless for customers.
These issues provide a compelling argument for a software development process that can manage the actions of all stakeholders, including customers, users, developers, and managers. One approach to solving this problem is to use a unified data model for the application to be developed, which allows different teams and different specialists to collaborate with each other at all stages of the system development life cycle. And this is where Domain-Driven Design (DDD) comes in handy.
Domain-Driven Design and Its Implementation in the 1C Platform
The development and design of applications that follow DDD will vary depending on the company domain. Project participants who understand a particular subject domain develop a common language that their specialists understand from both the business and the development sides. In Domain-Driven Design, this language is called a ubiquitous language. The project is discussed, the domain model is created, and the code is written in terms of the ubiquitous language.
Developing DDD from scratch is not an easy or quick process, but the investment pays off with the right approach. However, building a domain model is usually not budgeted when drafting a plan for application development.
In the 1C ecosystem, this problem has been solved by giving the developer a full-stack platform with a ready-made domain model. The model reflects the company's internal business processes, such as financial management, HR management, warehouse management, etc.
Within the 1C:Enterprise platform model, business applications are described not in the technical terms of relational tables, the classes of an object-oriented programming language, etc., as in most systems, but in terms of metadata. Metadata represents the sum of all the configurable components of an application. Each component is responsible for representing particular objects or processes in the company’s domain that have similar behavior and play a similar role in the overall picture of the application. Examples of such components in the 1C:Enterprise platform are “Catalogs”, “Documents”, “Accumulation registers”, etc.
|1C:Enterprise platform components in terms of ubiquitous language:|
Catalogs — Storage lists of Customers, Products, Employees, etc.
Documents — Business events, such as Purchase Orders, Sales Orders, or Invoices.
Accumulation register — Accumulation document with posted transactions, such as, for example, accounts receivable or a bank register.
Accounting engine — Accounting document with postings, which is typically used for creating specialized ledgers and the general ledger.
Calculation engine — Payroll calculations.
Business process — Used throughout the system for modeling business processes.
The chart shows several platform components and examples of application modules that can be created using these components. The application modules and components correspond based on the block’s color.
Thus, the platform determines a single business-oriented context for all project participants.
Non-programmers can quickly understand the types of application components, which allows analysts, customers, and developers to discuss the functionality of the project using a common language. Domain specialists actively participate in creating an MVP (Minimum Viable Product) of the business application. A good MVP allows the project development team to avoid mistakes when articulating their vision for the product, formulating goals, and defining the application's functionality.
You may often meet business representatives or analysts who do not know anything about programming, but they can still set a task in terms of the types of 1C:Enterprise platform components that are involved. At the same time, programmers can design an application even if they are not specialists in such fields as accounting and auditing, for example.
Thanks to the platform, IT and business concerns are aligned «by design» in the 1C ecosystem. It means that IT and business specialists can achieve effective collaboration without having to expend any additional effort. As a result, time-to-market for the software product being developed diminishes, and IT costs shrink through eliminating expenses that do not contribute anything to achieving business goals.