Shared Services in Non-Profit Organizations: Lessons from a Domain-Driven Design Approach

Introduction

In the world of non-profit organizations, where every dollar counts, efficiency and cost reduction are paramount. The concept of Shared Services has emerged as a powerful strategy to streamline operations and maximize resource utilization. This article delves into the Shared Services concept in non-profit organizations and draws valuable lessons from a case study involving two clients. These organizations adopted a Domain-Driven Design (DDD) approach to effectively implement Shared Services, showcasing the potential for efficiency improvement.

Shared Services in Non-Profit Organizations

Shared Services is a strategic approach that involves consolidating common business functions across various departments or organizations to reduce costs, improve efficiency, and enhance overall effectiveness. While this concept is often associated with for-profit companies, non-profit organizations can also benefit immensely from its implementation.

In the case of the two non-profit organizations, their journey towards Shared Services began with a focus on optimizing their IT strategy. The objective was to translate these IT improvements into tangible cost reductions, a compelling proposition in a sector where cost-effectiveness is a top priority. The result was the development of a Shared Services strategy that would not only drive efficiency but also serve as a model for M&A business transformation.

The Challenge of M&A in Non-Profit Organizations

Mergers and acquisitions can be complex and challenging for non-profit organizations, especially when it comes to integrating disparate IT systems. Often, these organizations end up with a collection of IT systems from different vendors that duplicate functions. In the case under discussion, the challenge was akin to that faced by banks, where the core lending process involves receiving loan applications, processing and validating them, informing the customer of the outcome, and ultimately allocating funding (fulfillment).

Domain-Driven Design (DDD): A Strategic Approach

To address this challenge effectively, the organizations turned to Domain-Driven Design (DDD). DDD is an architectural approach that focuses on mapping business functions within a domain and defining shared services based on cross-functional communication.

Here’s how DDD was applied:

1. Mapping Business Functions: The first step involved a deep dive into the business processes related to loan applications and funding allocation. This included understanding the domain’s intricacies, dependencies, and the flow of information.
2. Identifying Business Contexts: The organizations identified distinct business contexts within the domain, such as loan origination, assessment, and fulfillment.
3. Defining Shared Services: With a clear understanding of the business contexts, the organizations defined shared services that would be responsible for specific functions. For instance, a shared service might be responsible for loan application processing, another for assessment, and yet another for fulfillment.
4. Cross-Functional Communication: DDD emphasizes seamless communication between different business contexts. Shared services were designed to interact efficiently, ensuring that information flows smoothly across the domain.

Lessons Learned

The implementation of Shared Services using a DDD approach yielded several valuable lessons:

1. Business Context Clarity: DDD helped in achieving a precise understanding of the business contexts within the domain. This clarity facilitated the identification of shared services and their responsibilities.
2. Efficiency Gains: By streamlining operations and eliminating redundancy, the organizations achieved significant efficiency gains. The loan application process became faster and more cost-effective.
3. Scalability: Shared Services designed using DDD proved to be highly scalable. As the organizations grew, they could easily expand their services without major disruptions.
4. Adaptability: DDD allows for flexibility in adapting to changing business needs. When regulations or market conditions changed, the organizations could quickly adjust their shared services.
5. Cost Reduction: Perhaps most importantly, Shared Services delivered on the initial objective of cost reduction. By consolidating functions and optimizing processes, the organizations realized substantial cost savings.

Conclusion

The Shared Services concept, when coupled with a Domain-Driven Design approach, can be a game-changer for non-profit organizations seeking to enhance efficiency and reduce costs. This case study demonstrates that the principles of DDD can be applied effectively in diverse domains, including non-profits, and offers a roadmap for others to follow. Ultimately, Shared Services driven by DDD can empower non-profit organizations to maximize their impact while minimizing their operational footprint.

How Xagrose Can Help You

At Xagrose, we understand the importance of efficient operations and cost reduction in non-profit organizations. We specialize in helping organizations like yours implement Shared Services using the principles of Domain-Driven Design (DDD).

Our services include:

1. Design Workshops: We can set up design workshops for your team to educate them on how to map business functions to domains effectively. These workshops empower your staff with the knowledge and tools needed to identify shared services within your organization.
2. API Design: In the age of digital transformation, APIs (Application Programming Interfaces) play a crucial role in enabling efficient communication between shared services. We can assist you in designing APIs that facilitate seamless data exchange and interaction between different business contexts.

By partnering with Xagrose, you can leverage our expertise to streamline your operations, reduce costs, and enhance the overall effectiveness of your non-profit organization. Together, we can work towards maximizing your impact in the communities you serve while optimizing your operational processes.

Working across many industries, I have observed different patterns of digital transformation, but the key drivers remain the same. The ultimate goal of businesses in the digital economy is to stay competitive and ahead of the game. There are two elements to this change

• Market Growth
• Cost Efficiency

In both cases, the APIs play a crucial role in this transition, and businesses learned over time that DevOps practices such as CI/CD pipelines, agile development and SIT testing practices could accelerate the transition to an API ecosystem with higher confidence and lower risk factors.  

The DevOps practices help organisations to reduce their time to market for new innovative products, whereas the API-led architecture facilitates building new application out of existing digital assets and services. The DevOps topic is not in the scope of this article, and in the remaining part of this article, we discuss the two drivers for adopting an API ecosystem within your organisation. Let’s discuss it in more details.

Market Growth

For a long time, innovation has helped companies to break into the new market. Newcomers will eventually challenge the old way of doing business. We have seen this in FinTech industries were employing new technologies helped the FinTech companies to reduce the onboarding process for customers and attract customers who were unhappy about long processing time. But how is it done? While Technology helps you to bring on more innovative solutions, at the same time, your internal processes should support rapid growth. In technical terms, your solution should be scalable. 

In this respect, The  API-led connectivity helps you decouple business applications and scale them on demand. The resultant of this school of thought were design patterns such as Microservices. The microservice design pattern is a technology agnostic principle, and the idea is to employ the “divide and conquer” to break monolithic solutions to smaller and manageable services. The beauty of this approach is that your organisation can use Python, Java or Microsoft C to build microservices but ultimately they are all connected as part of a “Network of Applications”.

Cost Efficiency

During economic turmoil, it is not uncommon to see M&As in which bring about the second wave of digital transformation. At this stage, an architect should carefully answer the following:

• Consolidation or defragmentation.
• Regional or Central

When M&A happens, an essential task is to support business continuity. In this respect, one challenge would be connecting and integrating two organisations core systems together. The core systems would likely involve financial, treasury, ERP and HR systems. 

Often organisations start integrating these systems directly, aka Point-to-Point. A P2P integration, or what we call an ad-hoc integration involves extending existing solutions to communicate with a secondary system(s). 

Although the ad-hoc approach sounds less expensive in the beginning, experience shows it will become costly and a tedious job to maintain a working solution. An alternative approach is to promote interoperability across the businesses by using standard protocols/mechanisms as the contracts between different systems. Once you have a set of “contracts”, then there is a lesser risk of vendor-locking and hence more comprehensive options for the business.  

The second component of API-led connectivity is a Service Bus, where it looks after connecting various systems together and look after some critical tasks such as data integrity, reliability and scalability. Modern Service Bus solutions have extended their support to modern integration patterns such as Event-Driven Integration. But what are the differential factors for Service Bus vendors? 

Over time, certain vendors such as Salesforce CRM, SAP ERP have positioned themselves as the de facto standard within the industry. Hence one factor to consider when choosing a Service Bus is its compatibility with those underlying systems. For example, for many users, MuleSoft would look like a natural choice when it comes to Salesforce integration. This is due to the wide range of connectors developed by MuleSoft to allow smooth and reliable data exchange between Salesforce and other systems.  

Finally, adopting an API-led integration can help your organisation to grow while maintaining the costs at a lower level. Secondly, choosing the right Service Bus solution is a crucial factor in reducing the cost of development and stepping into a proven path rather than an unknown territory.