Today, virtually every organization has become or is on its way to becoming a tech business, regardless of what product or service it offers. Companies understand that gaining greater success requires IT and business work as reliable partners, making it possible to achieve the business’s strategic goals and create competitive advantages. The challenge, however, is that it is tricky to align the two. Stereotypes reinforce business misconceptions about IT and vice versa. Non-IT staff thinks that IT is too technical to understand. Businesses often view IT as a cost center rather than a source of competitive advantage.
The Issues of Business and IT Alignment
Generally, customers on the side of businesses have a vague understanding of how software is developed. At that, only a few developers can explain how to create a software business product from start to completion as it is a genuinely complex and complicated process. In addition, customers often do not feel like diving into these depths, as they find it challenging to figure out what is happening inside. So, they prefer to entrust developers with the responsibility of deciding on software details.
As a result, there is a big chance that developers misunderstand customer needs and incorrectly record them, which results in missed deadlines, budget overruns, and even a software system that is ultimately useless for customers.
These potential issues are a solid argument for picking a software development process that enables all participants, including customers, users, developers, and company management, to fully collaborate on the software development.
One of possible ways to do it is to build the development process around a unified data model that allows teams and specialists to interact efficiently at all stages of the system development life cycle. And here is where the domain-driven design (DDD) comes on to the stage.
The Domain-Driven Design and Its Implementation within the 1C:Enterprise Platform
The development and design of applications according to DDD will vary depending on the company domain. Project participants develop a common, rigorous language for the subject matter. This language is understandable to specialists from both the business and the development sides. In domain-driven design, we call it ubiquitous language. With this language, team members discuss their project, create a domain model, write code and do much more.
Software development from scratch according to the DDD concept is not easy and far from fast, but with the right approach, the invested effort is more than justified. However, the work of building a domain model often remains out of the scope of an application development budget.
In the 1C ecosystem, this problem has been solved by giving developers a full-stack platform with a ready-made domain model. The model describes internal business processes, covering management of finance, personnel, warehouses, and similar.
Instead of a traditional approach to describing business applications through technical terminology of relational tables, OOP classes, and similar, the 1C:Enterprise platform does the same by means of metadata. By metadata we mean a collection of configured application components. Each component in an application represents a specific type of domain object or process. And together they built up the whole system that we can use in an application. Examples of such components in the 1C:Enterprise platform are catalogs, documents, accumulation registers, and others.
|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.
With these components, developers can create various application modules, as shown in the diagram above. Related application modules and components have identical colors.
This way, the platform draws a unified business-centered context for all project members. Application component types quickly become meaningful to non-developers, thus enabling all members, including analysts, customers, and developers, to discuss the project’s core functionality using one language. As subject matter experts get involved in creating a functional prototype of a business application, a project development team has a high chance to get the right vision of the software product, set proper development goals, and ensure the application functions as required.
Most of the time, even business representatives or analysts with no coding experience can set a task for developers in terms of the 1C:Enterprise platform. More to it, developers can also design business applications, even if they do not have professional training in such areas as accounting, audit, or similar.
Thanks to the platform, business and IT in the 1C ecosystem are aligned “by design.” The high quality of collaboration between them comes with no additional effort on both parts. As a result, IT spending goes down though eliminating costs that do not contribute to the achievement of business goals, and the time-to-market period becomes less.
Got interested in developing applications in full alignment with business needs? Start free with 1C:Enterprise!