New recording of Architecture without Architects

3 December 2014

In September Michael Tiberg invited me to give my Architecture without Architects talk at the excellent FooCafe. The talk was recorded and the video is available on Youtube.

The Buy-vs-Build Shift (part 4)

7 January 2013

After discussing issues with building software in part 1 and issues with buying software in parts 2 and 3, this concluding post of the series considers two approaches for organisations to deal with the buys build shift.


The Buy-vs-Build Shift (part 2 and 3)

12 November 2012

In part 1 of this series I discussed traditional reasons people have for buying software, which turned out mostly to be based on perceived or real issues with building software. In this post, which contains part 2 and 3, I discuss issues with buying software.


The Buy-vs-Build Shift (part 1)

7 September 2012

When a new IT solution is needed in an enterprise, maybe because the business is changing or maybe because an existing manual process should be automated, the people who are in charge of implementing the solution usually quickly get to the question: should we build the solution or should we buy a package? For a long time the accepted wisdom has been to always buy when possible and only build when no suitable packaged solution exists in the market.

In this article series, which will eventually be published in this book, I want to explore the reasons behind the existing preference for buying and, more importantly, I want to challenge the accepted wisdom and explain why I believe that the changes that have occurred in software development over the last decade have shifted the answer to the buy-or-build question away from buy and more towards build. I am not going as far as suggesting that build should be the new default but I think building software should be considered more often and it should be considered even when a suitable package exists.


Dependency Structure Matrix

9 April 2010

This is just a quick post to raise awareness for a technique that has been around for a while. In software architecture a Dependency Structure Matrix (DSM) can be used to understand dependencies between groupings of classes, that is packages in Java and namespaces in C#. There are obviously other uses, and this Wikipedia article has more background information.

Returning to classes and packages, the following matrix shows a view of some of the core classes of the Spring framework:

In this typical package DSM the packages are listed on both axes. If a package has dependencies on another package, the number of dependencies is listed at the intersection. The package that has the dependency is on the top, the package that it depends on is on the left. In the example above the matrix shows that there are seven dependencies from the beans.propertyeditors package to the package.