25 July 2017
Posted in Clippings, Architecture
In my latest talk, All Roads Lead to DevOps, I discuss how DevOps fits with modern software architecture concepts like Microservices and Cloud computing.
The talk has been recorded at this year's XConf and the video is now live on the ThoughtWorks video channel.
22 October 2015
Posted in Clippings, Architecture
At a recent Technical Advisory Board meeting Sam Newman and I had a conversation about microservices and cloud computing; how they have really brought something new and helpful, but also how, as usual, they are seen as the silver bullet that will solve all our problems.
The recording has now been published on the ThoughtWorks channel on Soundcloud.
17 July 2015
Posted in Architecture, Conferences
This year, the Java programming language is 20 years old. To mark the occasion, Michael Stal, editor of JavaSPEKTRUM, decided to publish a few anecdotes that we, the members of the content advisory board, would contribute. When I thought about what to write the hype around this year's WWDC was building up, reminding me of the following story.
It is May 2000. A few colleagues of mine and I sit in an overcrowded room at Apple's World Wide Developer Conference (WWDC), looking forward to session 407, to be presented by Rory Lydon. We're here because at our company we work with Apple's WebObjects application server, one of the very first application servers. Originally written by NeXT in Objective-C to be used with Objective-C it moved to Apple as part of the NeXT acquisition in late 1996 and was made Java compatible.
Rory is going to tell us what is going on in one part of Java land and his session has the title “WebObjects: EJB – Making the Best of a Bad Thing”. After an introduction he continues with a description of core parts of the EJB specification, and many in the audience, including myself, find hard to believe what we are hearing. Rory quotes from the specification, compares with the elegant solutions in WebObjects that have matured over years. We frown, worrying how our applications could be implemented with this EJB technology. The specification itself is the target and Rory mercilessly points out gaps and weaknesses. After further quoted passages from the specification the mood in the room brightens and, arriving at bean and container managed persistence, the first laughs can be heard. “This will never work in this form”, many seem to think.
03 December 2014
Posted in Clippings, Conferences, Architecture
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.
08 January 2013
Posted in Architecture
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.
12 November 2012
Posted in Architecture
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.
08 September 2012
Posted in Architecture
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.
09 April 2010
Posted in Architecture, Visualisation
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 core.io package.
23 October 2009
Posted in Architecture
To begin with an antipodean image, using a service-oriented architecture, when it works out, can be as elegant and exhilarating as surfing on a 10 meter wave, exploiting huge uncontrollable forces to move forward at great speed. However, unfortunately, and maybe much like in the surfing world, the SOA wave often mercilessly rolls over a hapless development team, leaving them confused and wondering whether to give up on the idea or to paddle out again.
Despite its complexity a service-oriented architecture is high on almost every project's wish list. I have been involved in eight projects over the last year, sometimes directly delivering working software, sometimes reviewing or advising, and out of these eight projects six were, according to the respective architects, building a system with a service-oriented architecture. On these projects I have come across two recurring uses of language around SOA that I found noteworthy.
01 July 2009
Posted in Architecture, Visualisation
At some point last year I was asked to review the architecture of the software behind a large and popular website. The resident architect explained how he had followed a modern approach, decoupling the web front-end from back-end services that provide content. To gain further flexibility he had put the front-end and the services on an ESB, mostly to cater for the possibility to make the content available to other consumers. In short, the architecture diagram looked a lot like many others: nothing to see here, move on.
The diagram above only shows one of the content services, which for the sake of this article is a service that provides contact details for a person.
Based on conversations with the project sponsors I began to suspect that at least the introduction of the ESB was a case of RDD, ie. Resume-Driven Development, development in which key choices are made with only one question in mind: how good does it look on my CV? Talking to the developers I learned that the ESB had introduced "nothing but pain." But how could something as simple as the architecture in the above diagram cause such pain to the developers? Was this really another case of architect's dream, developer's nightmare?
06 March 2009
Posted in Clippings, Architecture
Admittedly, I've been struggling with the "Architect" title in the IT world. It is not that I think there's no role for architecture, far from it, but too often I've encountered architects who focus too narrowly on architecture, losing track of the realities of actual software development and the context in which the software will be used. I wonder, if there was no "Architect" title and people who are responsible for architecture would be called guide or coach or tech lead, or just the senior developer, whether things would be better.
About a year ago, in a discussion about architects, rather than trying to define what an architect is or does, we looked at what he or she should know. We expressed our ideas as mini-essays, strictly limiting ourselves to one per essay, and it turned out that, at least to my surprise, there was a lot of agreement; maybe because we hadn't come up with hard and fast rules but with ideas and guidelines.
Luckily Richard Monson-Haefel was part of that discussion and he had the resolve and means to make our thoughts more widely available. Our list of the 97 things every architect should know was collected and refined on this wiki, and is available under a creative commons license. For a more convenient read it has now also been published as a book by O'Reilly. As expected, the discussions have begun.
04 May 2008
Posted in Clippings, Architecture
Of the many projects I have worked on the rewrite of the Guardian website is certainly a highlight. And in this case I can even speak about it in detail. In fact, Mat Wall from the Guardian and I presented some of our experiences at several conferences, and now the Software Engineering Radio has published a podcast in which we talk about this project.
29 April 2007
Posted in Architecture
Travelling's good for you, and on a recent trip through Patagonia I unexpectedly found the answer to a question that had tormented me for a while: What does SOA really mean? Well, have a look: The meaning of SOA.