Heronswood, Mornington Peninsula, Victoria, Australia
I am an author, speaker, and loud-mouth on the design of enterprise software. I work for ThoughtWorks, a software delivery and consulting company. This site contains lots of my writing on software development, which primarily focuses on software design and agile methods. To find your way around this site, go to the intro guide.
My atom feed (RSS) announces any updates to this site, as well as various news about my activities and other things I think you may be interested in. I also make regular announcements via my twitter feed, which I copy to my facebook page.
Fri 04 Apr 2014 17:59 CEST
Wed 02 Apr 2014 14:23 CEST
Most EnterpriseApplications store persistent data with a database. This database supports operational updates of the application's state, and also various reports used for decision support and analysis. The operational needs and the reporting needs are, however, often quite different - with different requirements from a schema and different data access patterns. When this happens it's often a wise idea to separate the reporting needs into a reporting database, which takes a copy of the essential operational data but represents it in a different schema.
Tue 25 Mar 2014 15:52 CET
ThoughtWorks recently announced the open-sourcing of our product Go - which supports Continuous Delivery. This kind of event tends to raise questions, so I organized an interview with Chad Wathington, who is a Managing Director of ThoughtWorks Studios (our product division). He answers questions on why we did the open-sourcing, why we announced it before making the source available, about the name-clash with the go language, and our future plans for Go.
Tue 25 Mar 2014 14:37 CET
The final installment of our article on microservices moves beyond the list of characteristics to assess the question of whether microservices should be the future of enterprise application architecture.
Mon 24 Mar 2014 15:17 CET
The penultimate installment of our article on microservices looks at the last of the list of common characteristics: an evolutionary approach to the design of microservice systems.
Mon 24 Mar 2014 15:15 CET
In the early part of this century, I worked on my book Patterns of Enterprise Application Architecture. One of the problems I had when writing the book was how to title it, or rather what to call the kinds of software systems that I was writing about. I've always been conscious that my experience of software development has always been focused on one particular form of software - things like health care records, foreign exchange trading, payroll, and lease accounting. These are very different to embedded software inside printers, games, flight control software, or telephone switches. I needed a name to describe these kinds of systems and settled on the term "enterprise application".
Sat 22 Mar 2014 18:43 CET
Wed 19 Mar 2014 14:50 CET
To get the benefits of a microservice approach you need to able to deploy code frequently, so deployments and infrastructure management needs to be automated. All this services also imply more frequent partial failures, which have to be expected as part of service design.
Tue 18 Mar 2014 15:03 CET
In this installment we look at the particular effects of decentralization on data storage, leading to polyglot persistance and a much reduced use of transactions to manage updates..
Mon 17 Mar 2014 14:13 CET
In this installment we talk about how microservices live in a world of decentralized governance. Rather than having a governance group define standards for services, services make their own decisions and are encouraged to share common solutions. With this installment we also look at the relationship between microservices and SOA.
Sat 15 Mar 2014 16:38 CET
Fri 14 Mar 2014 14:22 CET
When many people think of services, they think of service collaboration organized by a smart central communication infrastructure such as an Enterprise Service Bus (ESB). Part 4 of our microservices article explains that microservice architectures take a different approach.
Thu 13 Mar 2014 14:33 CET
The third part of our article on microservices explains that microservice architectures dislike the traditional notion of projects for organizing software development.
Wed 12 Mar 2014 15:04 CET
We continue our article on microservices by looking at how the services are organized around business function rather than technological layers. We also take a swish at the question of how large a microservice should be
Tue 11 Mar 2014 14:05 CET
Mon 10 Mar 2014 14:59 CET
There’s been a recent growth in interest around a style of software architecture known as “Microservices”. To help understand and explain what all this is about I’ve teamed up with my colleague James Lewis, who has been an active pioneer in this style. We’re working on writing various materials about microservices and have published the first installment of an article that explores the common characteristics we see in microservice architectures and what role they can play in software systems. With this installment we talk about how microservices think about componentization. We’ll release further installments to explore more characteristics over the next couple of weeks.
Sat 08 Mar 2014 15:46 CET
Thu 06 Mar 2014 15:28 CET
It's common for software systems to make remote calls to software running in different processes, probably on different machines across a network. One of the big differences between in-memory calls and remote calls is that remote calls can fail, or hang without a response until some timeout limit is reached. What's worse if you have many callers on a unresponsive supplier, then you can run out of critical resources leading to cascading failures across multiple systems. In his excellent book Release It, Michael Nygard popularized the Circuit Breaker pattern to prevent this kind of catastrophic cascade.
The basic idea behind the circuit breaker is very simple. You wrap a protected function call in a circuit breaker object, which monitors for failures. Once the failures reach a certain threshold, the circuit breaker trips, and all further calls to the circuit breaker return with an error, without the protected call being made at all. Usually you'll also want some kind of monitor alert if the circuit breaker trips.
For a long time I’ve been a champion of Continuous Integration which reduces integration risk by integrating early and often, an application of the principle of Frequency Reduces Difficulty. We’ve found CI to be a core technique at ThoughtWorks and use it almost all the time. At the heart of this is a style of development that minimizes long feature branches with techniques like Branch By Abstraction and Feature Toggles.
While this is useful, there was still risk present from software that works in the development environment to getting it to work in production. As a result we developed Deployment Pipelines to reduce this risk, moving closer to our aim of Continuous Delivery: building software in such a way that we confidently deploy the latest builds into production whenever there is a business need. We find this improves feedback, reduces risk, and increases the visibility of project progress.
For more information: take a look at my guide page on Continuous Delivery.
I’ve been involved in enterprise software for two decades and while we’ve seen huge technological change during that time, the relational database has been a constant figure. Previous attempts to dethrone relational databases have failed, but some people think the new rise of NoSQL databases will finally consign relational databases to history. While I think relational databases are going to an important part of the landscape for a long time, I do think that there is a big change coming in the database field.
I discovered ThoughtWorks in 2000: then a small American company whose philosphy of software development was remarkably similar to my own. Now we’ve grown to around 2500 people world-wide, but kept the values that make us special. My colleagues have built critical systems for many clients in that time, and I’ve learned many lessons from them. While doing this, we found we often didn’t have the tools we needed, so we started to build them. This led to open-source tools such as CruiseControl, Selenium, Frank, and Moco as well as commercial products.
I have many opportunities, but I’ve stayed at ThoughtWorks because of the quality of my colleagues, who include both well-known speakers and those who may not be famous names but do an excellent job of software delivery (and feed me the information to write about). We are inspired by working with each other and our unusual three-pillar philosophy that raises professional excellence and social justice to the same level as financial performance.
And we are always looking for more great people to join our curious company. Maybe I’ll see you in one of our offices some day.
As with any style of process, agile software development has bred lots of interest in metrics. The thinking goes something like this, “We need a number to measure how we’re doing. Numbers focus people and help us measure success.” Whilst well intentioned, management by numbers unintuitively leads to problematic behavior and ultimately detracts from broader project and organizational goals. Metrics inherently aren’t a bad thing; just often, inappropriately used. Pat Kua, author of The Retrospective Handbook, demonstrates these issues and offers an alternative approach that uses metrics well.