As enterprise Architects, depending on the organization we are adopting readymade software applications (or COTS) and tailoring or customization of the software to the needs of the organization. The tailoring can involve UI changes, workflows changes, integrations with other systems in the organization and sometimes business logic added or modified. The UI changes usually must happen on the COTS (Component of the Shelf) application and so are workflows unless you are building a UI façade for this application. I saw one organization did build a completely different Web App to provide its employees access to work shift schedules as the Time and Attendance system could not handle the access by the hundreds of thousands of employees and save on licensing and infrastructure costs. This leaves us with Integrations and business logic. In this installment. I will address Business Logic.
Should we build the custom Business Logic as Microservice or part of the COTS Application?
Aha, this is a tough decision. I prefer to put all customizations out of the software package somewhere else. Would it be in Microservices or built as part of the ESB. I want to have the freedom to have the business logic as platform independent as possible. By moving the custom business logic out in webservices implemented by Microservices or part of the ESB I accomplish that. There are political aspects to this issue too? First the COTS vendor wants to have all the business logic customization in its application for the following reasons:
- The vendor wants to increase the $$$ from the custom development services they will provide.
- The vendor can enrich its application offerings and business logic by taking this customized business logic and generalizing it in future releasee.
- The more customizations and business logic embedded in the vendor logic the harder for the organization to switch to another competitor as they will the cost of customizations from scratch would add up.
The delivery department would prefer not to take ownership of new software components, especially if the organization does not have many software developers and depends on consulting companies.
My argument is that, all software be it ERP system like Dynamics AX or Time and Attendance systems is generic and the vendor offer it to your organization and your competitors. What differentiates your organization from your competitors is the custom process and business logic your organization uses. If you let the vendor build these customizations in their software then you end up subsidizing your competitor upgrade, and maybe giving them your edge. That is why I tend to recommend extracting any custom business logic new or modified and building it outside the COTS. Sometimes this is not possible due to the CTOS platform limitations or due to organizational standards. But whenever is possible extract any custom business logic outside of the COTS
Let me know your thoughts on that.
Why do we call engineers who deign building Architects? When I visited Rome in May 2018 and visited the colosseum, our guide pointed out that the colosseum arches were the inspiration for the architecture science or the knowledge of how to build arches. How to build arches is a very complex process, it took a lot of effort to rediscover it in the Renaissance times. We call software engineers who design large software architects and those who guide organizations through the business, information, process, and technology changes necessary to execute the organization strategies Enterprise Architects.
Figure 2: Me inside the colosseum
Enterprise Architects define solutions to business problems by creating a solution architecture blueprint. Solution Architecture is the process of defining the design or organization of different systems and components to fulfill a business needs and requirements. By systems and components, I mean software applications, hardware devices the software runs on. With the emergence of Microservices enterprise architects are working on defining the required microservices for building IT assets that enable the organization in achieving it business goals. Domain Driven Design – Bounded Context principle resonates with how to define the actual size of Microservices (“Micro” does not mean tiny in this context). Recently I was chatting with a couple of colleagues about how to define and implement strategies for embracing Microservices and Domain Driven Design (DDD) within a large organization. And the following question came up:
Can we apply Domain Driven Design to existing Mainframe code and legacy Monolithic Applications?
My answer was “Yes we can” just like Obama slogan . DDD is about defining and designing better software that achieves the business goals, has supple design that can be enhanced by adding new features in the future, and can be easily understood by software developers and the business experts. You do not need to adopt new platforms, technologies to do that. You can app the DDD principles to any large complex business solution you are building. Think of DDD as a guiding way to approach a problem by decomposing it into smaller problems and tasks. You can apply that to anything in the universe just listen to Stephen Duneier Ted Talk https://www.youtube.com/watch?v=TQMbvJNRpLE
What is Domain Driven Design?
Domain Driven Design is an approach to combining business analysis with software design to make sure the developed business software meets the business problem it is trying to solve. It is part of the agile software methodologies that focuses on the actual software being built. But unlike extreme programming or the other agile methodologies where the absolute focus is on the code written, Domain driven design focuses on:
- Creating a representative model of the software- the focus of this model is on the actual components, classes, packages, modules and relationships that actually solves the business problem at hand rather than the code required to code the software for the chose platform, framework etc.
- Making sure that the model is understood by both the Business experts also referred to as Domain Experts and the developers
- Making sure the model and the code are in synch
Domain Driven Design introduces several techniques to help with achieving those goals:
- Divide the problem domain into several smaller domains called Bounded Context
- Bounded Context
- Ubiquities Language
- Refactoring both the code and the model
To be continued …