A Tool for Process Merging in Business-Driven Development (Category Architecture)

While looking for materials for a book on architecture, I came across artifacts from the past in the form of a "Business-driven development" approach that 20 A few years ago, IBM promoted:) The original IBM article on business-driven development is not available. article The tools are still with us. In fact, BDD is a methodology for developing IT solutions that directly connects business needs with IT implementations, in which the stages of the type were distinguished. 1) Modelling: Defining business goals and building business process models. 2) DevelopmentTransformation of models into IT-realization. At that time, the use of language was used. BPEL (Business Process Execution Language), which allowed you to orchestrate business processes on top of SOA services (service-oriented architecture). Now SOA is a thing of the past, and we often see use of it. BPMN (Business Process Model and Notation) Engines like Camunda for about the same breeding, but now microservices:) 3) ImplementationIntegrating solutions into infrastructure and monitoring their performance.

There were two problems with this model: The gap between business models and iT-reality – business process models that were designed to achieve business goals may not translate directly into scalable, reliable and productive choreography of IT services There could be problems with the existing infrastructure - this top-down approach could not fit into existing restrictions, software, hardware, networks and so on.

The authors suggested that 2 Reality models: An analytical model that focuses on what processes do and is used by business analysts Design model that is responsible for IT implementation, including data flows, decision logic and implementation specifics

In general, this was an attempt to jump from business processes to implementation on top of services through the generation of BPEL code, but the latest version of BPEL came out in the middle of the project. 2007 The approach turned out to be non-working, since the questions that were highlighted within the article remained unclosed. Maintaining consistency between business models and code (round-tripping) Determining the optimal detailing of services

• Quality assurance of models (detection of design errors) Improve the visualization of large models and search in their collections

Although the authors predicted that the model would become code, where graphic and text elements would be combined into a single system, and transitions between levels of abstraction were supported by quality assurance methods.

It seems to me that this whole topic died because of its heavy weight. As a result, in many technology companies, the concept of creating a map of business processes and linking them with IT gave way to creating a technological product for users, and then fixing the processes that it supports:) Conventionally, the approach from business processes to IT services was a top-down hike, and the hike from the creation of IT products to the business landscape is rather bottom-up. The latter approach turned out to be more adapted to living in changing conditions - it yielded faster results and provided greater flexibility, which led to his evolutionary victory:)

P.S. Around these years, I defended my master’s degree on the topic of business process reengineering and retail company automation, so I perfectly remember a large number of options for modeling business processes and their automation:)

#Management #Architecture #ArchBook #Retrospective #History #Processes #Software