The art of simplicity

While cleaning up my desktop I found 2 screenshots I had taken during a presentation I viewed online. I don't know what the original source was(if you know from which presentation this is, please let me know) but I found them too good not to share. They state 2 rules that are applicable for every software architect: Rule #1 – Every decision has it prices. No decision is free.   Rule #2 – A decision can only be evaluated with respect to it context

Most of the people I have the pleasure to work with are developers, all great, intelligent people with passion for technology and IT. When I talk with them about their career and how they think they should evolve, a lot of them aspire to become an architect. Now the job title architect can mean a lot of different things, but that is not the topic I want to rant about today … *** START RANT *** I’m a little bit puzzled why a lot of developers think that becoming an architect is the logical way forward. Why you ask me? Let me explain… Developers are creative people, great thinkers and problem solvers. They like to tackle complex problems, that’s what they live for. Once they are no more problems to solve, they start to get bored and start looking at new frameworks and tools just to have new problems to tackle. Developers LOVE complexity. “Developers are attracted to complexity like moths to a flame” As an architect it is quite the opposite. You are not aiming for sprints bu...

Great conversation with Matt Johnson from the Patterns and Practices group, about things we should consider when moving our applications to the cloud. If you want to build your application for cloud scale, this video offers some great insights. Don't forget to take a look at the links he referred to: Azure architecture guidance Performance optimization guidance Scalability best practices Cloud design patterns Async tips

If you are an architect that want to use the power of Microsoft Azure, Microsoft created a set of architecture blueprints for different scenario’s that help you build new solutions fast. For every diagram, a 2D and 3D version(in Visio) and a video explaining the blueprint is available. Certainly useful!​

Once your architecture has grown to a certain scale, things will start to fail. If you don’t design for failure inside your system, one small error can bring your whole system down. Organizations like Netflix and Uber, but also Cloud Vendors like Amazon and Microsoft have shown us a new style of engineering; Chaos Engineering , that embraces failure. With things like the Netflix Chaos Monkey and more recently the Netflix Simian Army different type of failures are induced to evaluate how the architecture handles these kind of issues. This has completely changed the way I think and design my systems. Luckily new patterns appear and some old patterns get a revival(like Circuit Breaker ) that help us implement these principles. More information: Chaos engineering at Microsoft Azure Search: https://azure.microsoft.com/en-us/blog/inside-azure-search-chaos-engineering/ The Netflix Simian Army: http://techblog.netflix.com/2011/07/netflix-simian-army.html Principles of Chaos...

Distributed systems come with their own set of problems. One of these problems is the generation of unique identifiers across multiple nodes. You can rely on the database to generate a sequential guid, but this hinders scalability and makes your systems error-prone. While browsing through the MassTransit code base, I noticed they were using a separate NuGet package called NewId . NewId is a unique id generator with 2 important characteristics: Unique Id generation at a specific server can happen without interaction with other servers Id’s should be ordered(important for database optimization) It’s inspired by (the retired) Twitter Snowflake and Boundary Flake implementations. Certainly useful if you need to build scalable solutions…

With all the goodness that MicroServices has to offer, people think it’s the next silver bullet and don’t learn from their mistakes. I always have to think about this quote from Simon Brown : If you can't build a monolith, what makes you think microservices are the answer?   An interesting video in this regard, is the talk at NDC Oslo from Jimmy Bogard about SOLID Architecture in Slices not Layers. It doesn’t talk about MicroServices but brings some new insights in how to build nicely structured monoliths(and there is nothing wrong with that). SOLID Architecture in Slices not Layers - Jimmy Bogard from NDC Conferences on Vimeo .

Great article by Martin Fowler on Dr.Dobb’s about Errant Architectures . As a (lead) developer/tech lead/application architect this probably happened to you before: you start on a new project and the first day you arrive, the (enterprise) architect shows you proudly his nice architecture; you know; this thing with all the arrows and boxes. You hear the architect explaining; “…And every box runs on its own server…” “…bla bla bla…” “…And performance is critical…”. Now without hearing any other part of the conversation, you know you are in trouble. Especially if some micro services flavor is added to the mix. This is a recipe for disaster. The architect forgot the First Law of Distributed Object Design : Don’t distribute your objects! But how you are going to tell this to the architect, especially on your first day on the job? The answer is simple, forward the link about this article to your architect. 

CQRS is a really useful pattern, but it’s hard to find good examples out there. Jimmy Bogard took the time to rewrite the Microsoft Contoso University Sample app using a CQRS approach. Although not complex enough to show you the full power of CQRS, it gives you a good insight in the mechanics involved. Certainly worth checking out…

As an application architect and technical lead, I not only have to keep up with current technologies but also have an eye on future and upcoming technologies and trends. One of these places I look at is the ThoughtWorks Technology Radar . A must follow for every (aspiring) architect…

One of the less fun parts of my job is that I spend a lot of time doing estimations. As with all estimates, sometimes they are quiet correct and sometimes they are horribly wrong. Either way it cost us time and money to get some estimates, which in the end are… just estimates. Most of the time I use a work breakdown to create my estimates. This approach has 3 big disadvantages(in my opinion): It’s very time-consuming It leads to overestimating. Typically the more depth you add to the work breakdown, the higher the estimation will be. It doesn’t allow you to manage uncertainty. In the end you still have to use some gut feeling to apply a factor depending on the level of uncertainty or risk. Last week I was reading about an alternative approach: Blink estimation . The idea of Blink estimation is that if you bring the right mix of people with sufficient experience in the room you can reasonably assess how this project is similar to, and different from, previous ones, a...

After the Agile Manifesto it is now time for the Reactive Manifesto , focusing on the why and how of Reactive systems…

A few months ago, Microsoft introduced the FailSafe Initiative. The mission of the FailSafe Initiative is to articulate recommendations and approaches for delivering resilient and scalable cloud architectures. FailSafe delivers general guidance on building resilient and scalable cloud architectures, guidance for implementing those architectures on Microsoft technologies generally, and scenario specific architectures that implement those architectures in context. Developed by Microsoft Services and the Azure Customer Advisory Team, this series provides both platform agnostic concepts and patterns as well as Windows Azure specific implementation guidance. Some useful links: http://msdn.microsoft.com/en-us/library/windowsazure/jj853352.aspx http://www.windowsazure.com/en-us/develop/net/architecture/ http://msdn.microsoft.com/en-us/library/jj717232.aspx http://code.msdn.microsoft.com/Cloud-Fundamentals-in-1a3ab1bd And of course, don’t forget the Channel 9 series: ...

Looking for some principles, patterns, smells and guidelines for: clean code class and package design TDD – Test Driven Development ATDD – Acceptance Test Driven Development Continuous Integration ? Urs Enzler created the a new version of the Clean Code Cheat sheet , a short and useful list of DOs and DONTs for every professional software developer.

Are you still using your ‘old school’ relational database or do you want to work with one of the hip and funky NoSQL(Not Only SQL) solutions?  Either way your applications will probably have to store some data. To help you find the best solution for your problem domain, the Microsoft Patterns & Practices team released a new guide about Building Highly-Scalable Solutions for Storing and Retrieving Data (Using SQL and NoSQL Databases)   From the guide: This guide focusses on the most common types of NoSQL database currently available, describes the situations for which they are most suited, and shows examples of how you might incorporate them into a business application. To illustrate good practice, the guide summarizes the experiences of a fictitious organization named Adventure Works, who implemented a solution based initially on a relational database. Some inefficiencies in the resultant system caused them to modify their system to take advantage of different NoSQL da...

Last week I discovered http://www.cqrs.nu/ ,  a great site if you are interested in CQRS and have lots of questions. “ The ideas around CQRS are fascinating, but different enough from the way we do conventional development that some questions come up again and again. This page collect a number of such questions that we've encountered, and attempts to give accurate and satisfactory answers to them.”

Last week I discovered this great Visual Studio extension: Design Patterns UML Toolbox Provides Visual Studio 2012 UML toolbox items representing the majority of the Gang of Four design patterns. The patterns are split into Creational, Structural and Behavioural sections, and includes a supporting UML profile. The extension adds new toolbox items to the UML toolbox. More information: Visual Studio Gallery Codeplex site Blog post by Giles Davies

Always looking for ways to improve the quality of our code, one thing I can recommend is the introduction of ‘buddy reviews’. You probably know the normal code review where maybe once a month, a technical lead or architect has a look at your code. Of course you have already moved on to another part of the code, so it’s way too late to fix all the detected issues (with an increasing technical debt as a consequence).  So let’s introduce the buddy review. It consists of meeting up with another team member informally (ideally before you check-in your code) and having a quick glance (5 - 10 mins) at each other's code at your desk or their's. This approach has the following benefits above the ‘formal’ code reviews: Problems are caught very early. You are always up to speed as to what is going on. Reviews are always very short because you are only looking at new code since the last catch up . Because the setting is informal - there is no nervous tension. They...

If you are still not convinced that NServiceBus could make your message based architecture a lot simpler, maybe this new feature can convince you: NServiceBus Modeling “Visual Studio integrated modeling tools for NServiceBus allow you to graphically design your distributed solution and have all of your projects created, appropriate references set up, configuration of queues and routing made to "just work", on top of all the regular NServiceBus goodness.” This first version includes Visual Studio integration and really makes developing with NServiceBus much more productive and enjoyable. NServiceBus Modeling Tools for Visual Studio from NServiceBus Ltd. on Vimeo . You can get this tool on the NServiceBus download page or via the Visual Studio Gallery here .

Yes, we are living in a connected world. Almost no system does live in isolation. So sooner or later you are confronted with some integration scenario’s. Multiple options are out there and which one should you pick? Paul Stovell did a very well written blog series about this. Go check it out! Integration: Scenario Introducing a simple scenario where two applications need to integrate. Part of a series on integration approaches. Integration: Shared Database One solution to application integration is for the applications to just share the same RDBMS. Let's explore the pros and cons of this approach. Integration: ETL Another solution to application integration to use extract/transform/load scripts to move data between the databases. Integration: Web Services A third solution to our integration scenario is for one application to expose web services. How would that work? Integration: Coupling ...