Microsoft Press's Professional Series (the silver ones ) aim to create a series of books that provide information for IT professionals in a technology independent manner. Examples of previous books in the series that I've enjoyed are Code complete by Steve McConnell and the Object Thinking by David West. Both of these contain information that can be easily transferred from one language to another such as between Java and C#.

Simple Architecture for Complex Enterprises by Roger Sessions sets out to create another book in this series; this time focusing on enterprise architecture in particular the focus is on the idea of creating simple solutions. The Book is split into two sections, the first concentrates on the issues of complexity. It starts off by giving an overview of the current state of play in the field of enterprise architecture. Following on from the description on enterprise architecture Roger gives an overview of The Zachman Framework, The Open Group Architecture Framework (TOGAF) and The Federal Enterprise Architecture (FEA). He points out how these should not be seen as competing against each other and how they can in fact be used to complement each other.

Now we dive into the main target that this book is hoping to address with chapter 2 "A First Look at Complexity". Along with defining complexity Roger proposes a solution in the form of partitioning that can be used to break complex system down into manageable chunks. This idea is well illustrated with the use of a Rubik's cube and how a 4-by-4 cube has 7.4 x 10⁴⁵ possible permutations, whereas a 2-by-2 cube has 'only' 3.7 x 10⁶ permutations. There eight 2-by-2 cubes would only have 29.6 x 10 ^6 possibilities. So this example proves with undisputable numbers that splitting a complex problem into smaller simpler problems allows us to produce simpler solutions.

The second section of the book is "The Quest for Simplification" is where we find Roger's suggestions on how we can avoid complexity in our applications. The methodology that is proposed to control complexity is Simple Iterative Process. SIP describes the main approaches used for complexity control: partitioning, simplification and iterative delivery. After this chapter 6 shows us an example of a system gone badly wrong and illustrates how SIP could have helped this system. The system in question is the National Program for Information Technology (NPfIT) that the British government commissioned for the National Health Service (NHS), even if you have no interest in IT and pay taxes in the UK this chapter should be of interest due to the colossal money squandered on the project due to late delivery all of which can be attributed to a complex solution being implemented for a complex problem. The next chapter the looks at how we can start designing software to control the complexity problem using a technique called "Software Fortresses".

I liked this book particularly because it does what I think is important when writing on a topic such as enterprise architecture, it will help get you thinking! I would encourage developers, architects and CIO's to read this book and ensure they are aware of the danger of complexity entering their projects.

I would like to conclude this post by referring to thoughts from the book. To be a successful architect you must be passionate about simplicity, you must aim to make it your goal to deliver a simple solution for complex problems, anybody can develop a complex solution, it takes a great architect to take a complex problem and deliver a simple solution.

The practice of coding against interfaces is already a well recognised best practice for software development, one of the advantages of this is that it helps loosen the dependencies between a class and the various other classes it uses. An application where this can be extremely useful is when unit testing your code, by loosening the dependencies of a class it becomes possible to test a class in isolation.

A good example of how to use these would be in data access classes, the real data access class would undoubtedly make calls to a physical database which would required configuration etc. However when testing a class that depends on the data access class we don’t want this dependency. Therefore the solution is simple. Define an interface, make both he real and mock classes implement this interface, the only difference is that the real implementation would go ahead and make calls to insert, update and delete from a database the mock will return only hard coded values so that you know exactly what to expect when testing a class that uses the data access components.

There are various frameworks that help to facilitate the creation of mock objects such as NMock, these are slightly more complex and give some extra features but the principle of coding to interfaces must be adhered to in order to take advantage of such frameworks.

To see an example of using mock objects see my post on PrivateObject, here I have simply used standard interfaces as this proved effective enough to conduct the testing. If your situation requires something more you can always look into NMock which is a free download.