Project Orientated Architecture

Business Requirements

Within most IT organisations, projects are driven by business requirements. For example, the business might want to increase cross-sales across the website. The requirements will come through as a 'Cross Sales' project and usually developers will be put under time pressure to come up with a technical solution.

Developer Reaction

This usually puts developers into 'solutions mode'. This means that they forget that the project is just one business requirement that the technical framework has to support, and instead see the delivering the project as the only thing that matters, and the technical solution will reflect this.

Project Orientated Design

There will be a 'Cross Sales' control in the website, there will be a 'Cross Sales' service in the service layer and there will be a 'Cross Sales' database schema. We will end up with a vertical slice of the system that is purely there to support the Cross Sales business requirement. This may or may not be the appropriate solution, but things start to go really wrong when the second project comes along.

The Next Project

This project is called 'New Offers'. The business want to display offers to customers while they are on the website. The developers come up with the technical solution with a 'New Offers' control in the website, there will be a 'New Offers' service in the service layer and there will be a 'New Offers' database schema. We have another separate solution to satisfy another business requirement, all the way through the stack. This generally continues until you end up with a system that has many, many components and is very complex, hard to maintain and develop.

Project Orientated Architecture makes for overly complex solutions

What Should Happen

What should happen is that the system is built with logical components that support the business requirement, but aren’t built specifically for that particular requirement. This can then be extended to support other business ideas without writing another separate solution.

How To Approach Project Requirements

I think the first rule of thumb is to avoid calling the technical solution after the business requirement. Think about what functionality is called for to satisfy each part of the business requirement. Using the Cross Sales example, the UI control needs to display content in various slots available on each page. Therefore the control is a 'Content Slots' Control. The fact that the content that is served up is to do with Cross Sales isn't really going to have any effect on the solution. The service might have the responsibility of choosing what content to serve to the UI based on the customer profile, so the a 'Targetted Content' service would make sense. The back-end logic can use whatever logic it wants to decide on the appropriate content to send back. In the case of the 'New Offers' project, the back-end code is the only part of the system that should change, and this can go off and work out what new offers should be displayed to the customer, along with any cross-sales adverts or other useful information. It can then decide on the various priorities of the content and deliver this back to the UI, which is simply displaying various pieces of content that it is given, and not caring in the slightest what business outcome it is fulfilling by delivering this content to the customer.

Advantages

This approach will give us a far simpler and more extensible architecture and development and maintenance costs will be far less through the life of the system.