Being new to an enterprise organisation, I found that reading Martin Fowlers book Patterns of Enterprise Application Architecture (PoEAA) a cathartic exercise. It described the confusing and often frustrating world I found myself in, and prescribed solutions without claiming to be a panacea.
Enterprise systems are difficult, and not only because they can be technically challenging. In this post I will briefly look at two problems of enterprise systems (illogical requirements and modelling objects across teams) and try to describe ways to mitigate them.
Note: In a previous post I discussed When to be a Software Architect, which was also inspired from reading PoEAA.
Illogical Enterprise Software Systems
What is enterprise software?
[Enterprise Software is] purposed-designed computer software used to satisfy the needs of an organisation rather than individual users — Wikipeidia> [Enterprise Systems] support business processes, information flows, reporting, and data analytics in complex organisations — Wikipeidia
That is, enterprise systems are business focused systems that are purpose designed for a complex organisations. They are focused on the business instead of the individual.
So enterprise systems are large and complex. What does Fowler have to say about them?
enterprise applications often have complex data — and lots of it — to work on, together with business rules that fail all tests of logical reasoning. — PoEAA
My manager put this idea another way:
Just because you can draw an infinite staircase doesn’t mean you can build it!
So, enterprise systems are:
- Business Focused
- Purpose Designed
- Complex
- Illogical
The illogical nature of enterprise systems is probably due to the first three points. Any big business will be complex and have many intricate internal flows and relationships. Given the enterprise system is meant to represent these complexities, it will have to try and implement the complex logic which seems illogical (from a sane developers view).
To fix the problem seems straight forward, fix the illogical aspects of the system. However, this can be very difficult, as Fowler states:
business rules are just given to you, and without major political effort there’s nothing you can do to change them. — PoEAA
It therefore may be necessary to incorporate the illogical aspects of the business into the enterprise system.
Organisation is the Key
Fowler’s core technical advice for building an illogical enterprise applications is:
organise the business logic as effectively as you can, because the only certain thing is that the logic will change over time — PoEAA
Sandi Metz (author of Practical Object-Oriented Design in Ruby) describes a more specific way of organising illogical code in her presentation Go Ahead, Make a Mess. She advocated to allow bad code as long as it is in an Omega Mess, which should:
- Be at the end of the line
- Have no Dependencies
- Have no Dependents
This way the omega mess of illogical code is hidden from the main flow of the application, and it will then not impact the design of the rest of the application.
As Sandi Metz states:
Since it has no dependants and no dependencies, there is no way that changes to it can effect you app or changes in your app can effect it. It is not connected in one of the threads on your tapestry.
So to deal with the illogical parts of enterprise system:
Organise the illogical parts into places where they will have limited dependencies, and where they can be easily changed
Same Model, Different Properties
Enterprises are big and comprising of many teams, the also generally are focused on a few core concepts like product or service. This leads to a problem where the same concept (or model) can have vastly different uses and properties between teams.
In Brandon Byars post Enterprise Integration Using REST he gives an example of a product model where a marketing team may require each product to have a picture, a blurb and uses them in promotions. Where the accounting team requires them to having a supplier, a cost price and uses them as lines on invoices.
The marketing and accounting teams will have different rules and constraints on the properties and uses of the product model, and these may not be easily merged into a single definition, e.g. an accountant may join multiple similar products together to reduce lines in invoices and a marketer may break down products into variants to advertise.
Creating each model with all the necessary properties and logic for each team may be very difficult. Organising and reusing code can cause fragility in the system by creating dependencies between teams, e.g. if one team changes how they use a product, it may effect another team.
Byars further states that:
Attempting to rationalise the entire enterprise view of a product into a single catalog simply makes that catalog both fragile and inflexible.
This echoes Domain Drive Design, that states:
the total unification of the domain model for a large system will not be feasible or cost-effective
Boundaries are Key
Byars solution is inspired from Domain Drive Design, where for each team the the domain model is split into bounded contexts where the interrelationships are explicitly defined and can be mapped to and from a universal terminology.
An example of a domain model with bounded contexts is:
The benefits of this approach are:
- Having code specific to a team separated from other teams and core logic
- Minimising the dependencies between teams
- Reuse of the universal terminology across teams
- No upward dependence from the universal terminology to the team specific logic
Drawbacks of Layers:
- Cascading changes if the universal terminology changes
- Lost reuse between the team contexts
- Drawing the boundary between universal and team specific logic can be difficult
Conclusion
I found reading Patterns of Enterprise Application Architecture useful to understand enterprise systems and environments. By understanding that the illogical requirements and complexity is not unique to my work, but is actually a property of the business, makes it easier to identify and mitigate problems as they occur. Plus, I no longer go crazy when a specification comes in telling me to build an infinite staircase.
P.S.
An excellent example of building infinite staircases in enterprise is given in this video: