Enterprise Software Architecture: How To Do It

Articles in this series:
Enterprise Software Architecture: How To Do It
Enterprise Software Architecture: How To Do It Part 2
Enterprise Software Architecture: How To Do It Part 3
Enterprise Software Architecture: How To Do It Part 4

Most of my technical reading for the past year or so has focused on enterprise software architecture. Much of this material has been theoretical and vague. It has often included philosophical explanations about how to design a system, along with some detailed diagrams, but there is usually one glaring omission: code samples. This information has generally answered questions such as 'what you should consider' and 'how you should approach a problem', which are important, but it often misses a more fundamental question: 'how to do it'.

Maybe many people think it should just go without saying, that it should just be built in knowledge that every developer comes with, but there seems to be very few resources that describe the basic architectural framework for enterprise systems. And it doesn't seem to be taught in colleges or universities. This is what has led to an abundance of badly conceived 'Webforms over Stored Procedures' type systems. These are commonly unmaintainable, unscalable and often do not function according to specification.

Of course, there is no universal agreement on enterprise software architecture, and each case is different (try asking a software architect a question that is not answered with 'it depends'), but there are a few fundamental rules and patterns that can be followed. I intend to illustrate these on this blog.

This is not so much 'how it's done', more 'how I do it'. People will disagree, and I welcome any constructive criticism. I am after all still learning, and probably will be until the end of my career. So if you think I'm doing something wrong, please tell me and the world how to do it right.

What I hope to provide here is a basic template for enterprise software architecture that can tweaked according to the specific problem in hand. This is not an end to end journey through requirements gathering, analysis and modelling of a complex system. For that, I recommend you take a look at Ayende's excellent Macto posts.