In this blog series I will explain the architecture that I recommend to my customers from a business and technical level.

The series will contain 4 main posts:

1. Business value driven architecture with microservices (This blog post)
2. Example business application. An example application including technology choices including some comparisions between alternatives?
3. Continuous delivery of the applications that support business value. How to operate, maintain and enhance the different applications continuously?
4. Team structure and roles. How to structure the teams that maintain these business applications?

The following diagram shows typical applications that are needed by a IT consultancy like Incentergy and these will be used as an example in the series for marketing reasons we will call them microservices but technically these are just plain old web applications:

Business value in general

Every application in a typical company has to contribute to the business goal of the organization. Modern organizations are structuring their operations in processes and the maturity of a organization can be measured with the CMMI. Standard processes are typically grouped together e.g. Michael Porter propossed the following value chain:

A lot of ERP systems are structured based on these groups. These groups are also giving us as the IT guys a good way for structuring our applications.

Bounded context

Martin Fowler describses these process groups as Bounded Context. Most of the time these groups do not have a lot of dependencies and if so the dependency are well described by interfaces often given as paper forms. Let me give you two examples one with no relations and another with well defined paper forms:

Processes from different groups with no relations

1. Human Resource Management
   1. Educate workforce
2. Marketing & Sales
   1. Write invoice to customer

The two processes given above are often executed in every company on the world but the people responsible for them are different people and often they are using different software systems or no software at all.

Processes from different groups with well defined interfaces

1. Procurement
   1. Order parts from supplier
2. Inbound logistics
   1. Place order into stock
3. Operations
   1. Pay invoice

The procurement department will order parts from a supplier and then they are done. These parts will arrive at the warehouse and are put into a stock location. When they arrive in the warehouse there are two documents attached: The invoice and the packing slip. The packing slip can be used to update a warehouse management system. The invoice is send to the operations department for payment.

As you can see the processes are executed by different people and the communication uses paper forms.

Modularizing software

We know that modularized software is easier to maintain because changing one part only has implications for the dependent parts. There are multiple ways for measuring this an example would be SQALE.

So now is the question how to create your modules? For a long time the recommendation was to design software in layers e.g.:

1. Data storage e.g. SQL Database
2. Application layer e.g. Application server
3. Presentation layer e.g. HTML5 Application

Multiple frameworks and stacks help in doing so e.g. MEAN, .NET, LAMP or Java EE. While I still agree that this is a good idea the business function plays an important role as well. The current microservice movement puts the business value in the center of the software modularization.

Parts of software that can modularized

1. Software configuration management e.g. git
   1. How many repositories do I need?
2. Build management
   1. How many maven artifacts should I produce?
   2. Which artifacts should be released together?
3. Continuous integration management
   1. How many Jenkins builds should I have?
4. Deployments
   1. On how many servers should I deploy?
5. Monitoring
   1. Which metrics should I observe?

Communication of software components

Let’s assume we now chopped our software in tiny little parts based on business value. These parts still have to communicate. Before answering the question how. I will give a recommendation about what. My recommendation would be to always communicate in business objects. The picture in the begining shows these objects.

The time tracking system produces a time sheet. One or multiple timesheets can be used by the invoicing software to create an invoice for a customer. This invoice can be fed into the accounting system.

Conclusion

Current software systems are becoming bigger and bigger. To manage the complexity and make them changeable in a fast way modularization is used during multiple activities in software engineering. Some modularization has technical reasons like backend and frontend some modularization has  business reasons like time tracking and invoicing. If you want to be a good software architect you have to become a domain expert and use that knowledge to structure the software in an optimal way.

If you are interested in our services feel free to contact us.