Part -2 Introduction to DEMO and the Complete Transaction Pattern

In this second installment, we explore DEMO (Design and Engineering Methodology for Organizations) and its foundational Complete Transaction Pattern (CTP), which models organizations as networks of actors fulfilling commitments through standardized transactions. By focusing on core services independent of current structures and technology, DEMO reveals essential operations and enhances efficiency. Join the journey every Monday and Thursday for the next four weeks.

DEMO (Design and Engineering Methodology for Organizations) is a comprehensive framework which is grounded in enterprise ontology [D&M, 2020]. DEMO sees an enterprise – any goal-oriented cooperative – as a network of actors with commitments regarding products (services) that they create (deliver). Commitments are the results of coordination acts (such as requesting and promising), which occur in universal patterns, called transactions.

DEMO focuses on modeling, analyzing, and designing organizations by identifying and understanding their fundamental transactions and communication structures. The methodology aims to uncover the essential business services that drive an organization, providing a clear and unambiguous description of how the organization operates, independent of its current organizational structure and IT infrastructure or implementation details.

Introduction to the Complete Transaction Pattern

At the heart of DEMO is the Complete Transaction Pattern (CTP), which serves as a universal template for modeling all transactions within an organization or supply chain. The CTP is essential for understanding how business interactions unfold, providing a structured approach to modeling a formal transaction between two parties.

The CTP breaks down every transaction into specific coordination acts between the initiator (the party requesting a service) and the executor (the party responsible for fulfilling the service request). These acts occur during the three phases of the transaction.

Order Phase:

• Request Act: The initiator (e.g., a customer) expresses a need or request to the executor (e.g., a service provider). This act initiates the transaction.
• Promise Act: The executor evaluates the request and commits to fulfilling it, thereby making a promise to deliver the desired result.

Execution Phase:

• During this phase, the executor processes the request and works to produce the desired out-come. This phase is where the core activities of the transaction take place, transforming the request into a tangible result. This may include executing transactions with other parties, whose results contribute to this result.

Result Phase:

• Declare Act: The executor communicates the completion of the requested action, declaring that the result is ready for evaluation by the initiator.
• Accept Act: The initiator reviews the result and, if satisfied, formally accepts it, thereby completing the transaction.

These phases and their associated acts are universal, meaning they can be applied to any transaction within any organization or supply chain, regardless of the industry or context. This universality makes CTP a powerful tool for modeling business processes in a way that is both consistent and comprehensive.

Managing expectations and achieving consensus

When handling business transactions, it is essential to maintain open communication between parties to manage expectations and achieve mutual understanding. Two key acts within the transaction process, Decline and Reject, allow for flexibility and ensure that both the initiator and executor can align on desired outcome.

• Decline Act: The executor may decline a request if it cannot be fulfilled as requested. This act ensures that the executor can manage expectations and avoid overcommitment. When a request is declined by the executor, it is up to the initiator to consider expressing an adjusted re-quest.
• Reject Act: The initiator may reject the result if it does not meet the specified requirements or expectations. This act ensures that the initiator has the authority to maintain quality standards and refuse unacceptable results. When the result is rejected by the initiator it is up to the executor to consider providing an adjusted result to the initiator.

Handling Exceptions with Revocation Acts

Additionally, the CTP also provides supports for the handling of exceptions and ensure that transactions can be managed effectively even when issues arise:

• Revocation: Any of the coordination acts (Request, Promise, Declare, Accept, Decline, Reject) can be revoked. Revocation allows for the correction of errors or changes to the transaction’s outcome, ensuring that both parties remain in agreement throughout the process. For example, if a promised delivery date needs to be changed due to unforeseen circumstances, the earlier promise can be revoked and renegotiated, maintaining transparency and trust between the parties.

Example: Applying CTP to an E-commerce Platform

When the CTP is applied to a business model, it significantly enhances service quality by ensuring continuous agreement between the initiators and executors throughout the transactions. This flexibility enables organizations to manage exceptions more effectively, boost customer satisfaction, and deliver a consistent service experience.

Consider an e-commerce company that is transitioning from a monolithic system to a microservices-based enterprise solution architecture. Using DEMO, the company identifies its key transactions: product ordering, payment processing, and order fulfillment.

• Order Transaction: The customer (initiator) requests a product from the catalog, and the e-commerce platform (executor) processes this request. If the platform can fulfill the order, a Promise act is issued, committing to the delivery. If the platform cannot fulfill the order (e.g., due to stock issues), a Decline act is issued, informing the customer.
• Order Payment Transaction: The e-commerce platform (initiator) requests the payment gateway (executor) to transact a payment with the customer, ensuring that the funds are transferred. The transaction with the customer is yet another independent CTP transaction between the payment gateway (initiator) and customer (executor). The payment gateway conveys the outcome of payment transaction with the customer to the e-commerce platform. If the payment was successful, the e-commerce platform starts the execution phase. However, if the funds were not transferred, the e-commerce platform can address this by taking appropriate action within the Order Transaction. Depending on the state of the Order transaction, this might involve executing a Decline act or a Revoke Promise act.

• Fulfillment Transaction: The fulfillment service (executor) handles the shipping and delivery of the product upon request of the e-commerce platform (initiator). Once the fulfillment service declares the shipment is completed, and the customer accepts the delivery upon receipt, the e-commerce platform can declare the delivery of order.

After modeling the business process as transactional services, the organization can create dedicated teams responsible for each transaction type. For instance, one team might manage the entire order process, from product selection to payment confirmation, while another oversees the logistics of fulfillment. Additionally, the organization can set up procedures for handling exceptions, such as product unavailability or payment failures, ensuring a seamless and high-quality user experience.

This approach ensures that the enterprise business architecture is perfectly aligned with the essential business services, enabling the organization to scale and adapt more effectively while maintaining a consistent and positive user experience.

Designing and Engineering a CTP-based Business Model with DEMO

After exploring how the CTP can be applied to an e-commerce platform, we can now focus on how to design and engineer a CTP-based business model using the DEMO methodology. DEMO provides a comprehensive framework for creating a business model that aligns the essential business services, independent of the current organizational structure and IT infrastructure or implementation details.

The DEMO ontological model captures the core of an enterprise by focusing on the products and services it delivers. It consists of four key aspect models that are crucial for specifying and aligning the CTP-based business model with the organization’s processes and interactions.

The Cooperation Model (CM)

The Cooperation Model focuses on the relationships and commitments between actors within an organization. This model provides the overview of all the essential transactions within an organization and the coordination structures between them. It defines the roles of initiators and executors in various transactions, mapping out how they interact through communication and agreements. By clearly defining these roles and interactions, the CM provides the foundation for understanding how transactions are initiated and managed within the organization. This model ensures that every transaction is grounded in clear, mutual understanding between the involved parties, which is vital for the consistency and reliability of the CTP-based business model.

The Process Model (PM)

The Process Model describes the flow of activities within the organization, detailing how different actions and events are sequenced over time. It captures the dynamic aspect of business transactions, showing how they progress from initiation to completion. The PM aligns closely with the phases of the CTP—Order, Execution, and Result—providing a timeline for how these phases unfold in practice. By defining the sequence of events and the conditions under which each action occurs, the PM ensures that the organization’s processes are coherent, efficient, and aligned with the overarching business goals.

The Fact Model (FM)

The Fact Model is concerned with the information that is created, processed, and stored during transactions. It specifies the facts that are generated by the actions and decisions within the organization, ensuring that there is a consistent and accurate record of all business events. In the context of CTP, the FM plays a crucial role in maintaining the integrity of the transaction process, as it captures the results of each coordination act—such as the acceptance or rejection of the result of the transaction. This model supports the enterprise solution architecture by providing a reliable and traceable record of all the information generated during all phases by the transactions, which is essential for auditability, compliance, and decision-making.

The Action Model (AM)

The Action Model delves into the operations that are performed by the actors, which initiate and execute the transaction within the organization. It specifies the rules which guide the actions taken by these actors to fulfill their roles in transactions, detailing what needs to be done to achieve the desired outcomes. The AM ensures that each action aligns with the commitments made in the Cooperation Model, translating these commitments into concrete tasks and operations. In the context of CTP, the AM provides a detailed blueprint of how the transactions are executed, ensuring that the enterprise can perform the necessary actions to fulfill business transactions effectively.

Integrating the Aspect Models with CTP

When combined, the four aspect models of DEMO provide a comprehensive specification for the CTP-based business model. The Cooperation Model establishes the roles and commitments of actors the Process Model sequences these operations over time, the Fact Model ensures that all outcomes are accurately recorded, and the Action Model details the operations required to fulfill these commitments. Together, these models ensure that the enterprise architecture is fully aligned with the organization’s essential business processes, providing a strong foundation for designing and implementing an operating model for an organization that is both effective and adaptable.

Discover how this journey began in Part 1 – Introduction and Overview. Explore what lies ahead in Part 3 - Event-Driven Architecture: The Natural Companion.

Unluck Exclusive Insights!

If you're eager to dive deeper into the methodologies and strategies discussed in this series, we invite you to request a copy of the comprehensive whitepaper, containing all the articles in this series. To get your copy, simply fill out our form here. Don’t miss out on the opportunity to enhance your understanding and transform your organization!

References

• [D&M,2020] Dietz, J.L.G. and J.B.F. Mulder, J.B.F. (2020). Enterprise Ontology — A Human-Centric Approach to Understanding the Essence of Organisation. The Enterprise Engineering Series. Springer, Cham, https://doi.org/10.1007/978-3-030-38854-6 ??
• [G,D&A 2018] Gouveia, Duarte & Aveiro, David. (2018). Modeling the system described by the EU General Data Protection Regulation with DEMO. ??
• [JD, 2017] Dietz, Jan. (2017). The PSI theory – understanding human collaboration. 10.13140/RG.2.2.12739.91680. https://dx.doi.org/10.13140/RG.2.2.12739.91680 ??
• [K,O&P 2024] Krouwel, M.R., Op ’t Land, M. & Proper, H.A. From enterprise models to low-code applications: mapping DEMO to Mendix; illustrated in the social housing domain. Softw Syst Model 23, 837–864 (2024). https://doi.org/10.1007/s10270-024-01156-2 ??