Frank Carver's Punch Barrel

A fascinating presentation from Barcelona Ruby Conference. Fred George talks through the history and examples of his thinking about system architectures composed of micro services.

I found this particularly interesting as it has so many resonances with systems I have designed and worked on, even addressing some of the tricky temporal issues which Fred has avoided.

Thanks to Steve Cresswell for pointing this one out to me.

There’s an interesting discussion going on at The Wisdom of Ganesh in which Ganesh Prasad and “Integral ):( Reporting” (presumably the “JJ Dubray” mentioned in the article) are trying to work out some issues around versioning, REST and SOAP. This post is also referenced and commented on at infoQ.

In the 14th comment to the original article, JJ calls for a real-world example – this is a good idea which should help ground the discussion and diffuse the temptation to communicate in abstract principles. In the spirit of this request, I will describe an example based on problems I faced in a previous job.

The first version of the system we were working on consisted of a server component, coded in Java, which provided remote services to several client systems. Each of the client systems was a Java web application, responsible for providing customer-specific web pages and navigation using the services and content provided by the central server. For some customers there would be just one instance of the web client, for others with greater load there would be several.

The server system was responsible for managing products for sale, including descriptions in multiple languages, format and compatibility meta-data, thumbnail images in several sizes, prices in multiple currencies. As well as access to individual items and collections, a search facility provided a way to discover or look up products. The server also managed customer details and purchase histories, and handled both delivery of content and general messaging (by email and SMS) during the purchase process. The client systems were responsible for display and navigation of a product catalogue, customer branding, “shopping cart”, login/logout, and everything else a user experiences.

The API between client and server included ways to list products by category, fetch details of specific products, search using a variety of criteria, make and cancel purchases, fetch and update user data and so on.

I suggest this should be a reasonable system on which to base a discussion – it embodies similar concepts to many other systems, and is neither trivial nor impossible to build. Interestingly, both SOAP and REST versions of the interface between the clients and the server were implemented at different points in the life of the product.

So, on to versioning. It seems to me that there are several kinds of changes which might require versioning. I will list a few here, but I welcome suggestions for others I might have missed.

• The first deployment of the system worked with only a single currency. The move to multiple currencies was a potentially major change in the interaction between client and server, even though each client works only in a single currency.
• The customer for one client implementation required the provision of extra services, specific to their market, which were not required by (and should not be available to) other clients.
• The initial version of the search facility returned data for all matches, with paging through the results implemented entirely on the client. When there was a lot of data in the catalogue this became an unacceptable performance bottleneck, especially as results beyond the first few pages were hardly ever viewed. An alternative approach was suggested where a client would request a specified page (of a specified page size) from the search results. This required changes in both the search request and search results.
• A new source of products introduced the idea of collections. Items in a collection could be purchased individually or as a bundle. Viewing a collection while browsing, searching, or in a user’s purchase history, should allow a user to “drill in” to the collection to view the items within it. Items located while searching should indicate how to purchase the collection, as well as how to purchase the individual item.

Is this a useful amount of detail for a scenario? I have my own experiences of working with this system and the choices we made, but I’d love to read any suggestions for how you might handle any of the transitions above in a live system with multiple client systems deployed, many of which can not be changed easily or often, and a server full of historical purchase data. Procedural remoting approaches (SOAP, XML-RPC and Java RMI etc.) and resource-based approaches (REST) are all welcome.

It’s a common software development situation. In front of you is a problem which seems to require a large solution. It has several parts which may be deployed separately, or may just need to be swapped out or independently managed. It has infrastructure bits and business-specific bits, servers, services and clients.

Now imagine that you have a large chunk of time (months to years) and a team of several people (or perhaps even several teams). The daunting challenge is how to plan the work so that it all gets done and all works together.

Agile Coach and Mentor Chris Pitts of Thirsty Bear has recently written some thoughts on this issue which broadly align with my experience.

It’s extremely tempting to begin by setting separate people or teams to work on separate parts of the system. Even if the team are working together, it’s tempting to take on one part of the architecture diagram at a time and continue until all the blocks are in place.

This risks several common problems, though.

The most obvious is that this heads straight for the nightmare of “system integration” – that theoretically short, but all too commonly deadline-busting, period after all the components are “done” but before the system can be shown to actually all work together. This is the part of the classic design/build/test lifecycle which is often ignored yet can force significant (and rushed) changes to the components when assumptions are shown to be wrong.

A less obvious problem is that the longer the delay before being able to show full end-to-end operation, the longer the wait for feedback from all the stakeholders who only care about what the system does on the outside, not how it does it inside. Building a system based on guessing what the stakeholders want based on theoretical discussions, documents, and the hot features offered by some big-ticket infrastructure is very risky compared with real feedback on a system which does at least one small thing completely.

Chris suggests

Slice the functionality, not the components

Which is good advice as it goes.

I’d add a warning that it is also all too easy to define the tasks to produce a system in terms of parts and modules. A task card such as “install database”, or a story for “web client” risk distracting the team from the real desired outcomes the stakeholders care about. If you see any such stories (or tasks, issues, tickets or whatever you call them) try and find some end-to-end scenarios or use cases which require such things, and describe them instead. When that story is tackled, then the required infrastructure and components can be implemented as part of that story.

A “workflow engine” is becoming the new must-have for enterprise system development. In days gone by it might have been an automatic choice to go for an expert system, Enterprise Service Bus, messaging infrastructure or big-ticket database, but those now seem a little bit passé.

There are several commercial workflow engines available, and a whole bunch of open source ones. Here’s a list of workflow engines written in Java, for example.

Boris Lublinsky has written an article at InfoQ expressing the strong opinion that writing your own workflow engine should not be an option.

I’m not sure I completely agree. For me the most telling part of the article appears near the end:

People today rarely implement their own database or O/R mapper or application server. Why is it often that people think that they should write their own workflow engine?

As it happens, I have implemented my own database, O/R mapper and application server, and found the experience invaluable in understanding the challenges and important features of such software. Writing a workflow engine would presumably be a similarly valuable lesson.

An interesting question from Simon Brown, and some interesting responses.

Why aren’t software architects held accountable? – Coding the Architecture.

Personally I don’t believe in the idea of an architect contributing during only part of a project. If architecture is important (and on some work it is obviously not) then whoever is responsible for architecture needs to be involved throughout the project, and just as accountable for the outcome as any other team member.

Sometimes in software development it seems that everything is turning into a “service”. For diagram-loving architects, decribing everything in terms of services is a great way to avoid getting involved in fiddly implementation detail.

The trouble with this approach is that hiding everything behind services can lead to thoroughly de-optimised systems. Greater hardware needs, greater software licence costs, duplication of development and maintenance effort, higher data-transfer and bandwidth requirements, etc. …

Phillip Calçado “Shoes” has a good example of some of these problems at What Is a Service?

YAGNI – it’s a neat term for a valuable technique. Ignoring an unknown future to concentrate on a known present. That does not mean that it’s application is obvious, though. I often find myself in “discussions” with architects and designers who recoil at the idea of building something specific to one customer or situation, when it is “obvious” that a general solution will be better.

Mark Needham has written some of his thoughts on this topic.

YAGNI: Some thoughts at Mark Needham

I’m in two minds about Service-Oriented-Architecture (SOA). On the one hand it seems obvious that future systems will need to inter-operate increasingly in order to gain business benefits without requiring complete software development projects. On the other hand, I am distinctly under-impressed by the current approaches to SOA, and even by the emphasis on services rather than the equally applicable resources, messages, or processes as the integration building blocks.

Here are a bunch of conflicting views on this area which have collected in my “blog this” queue over the last few days:

InfoQ Article: Will Cloud-based Multi-Enterprise Information Systems Replace Extranets?

Will Cloud-based Multi-Enterprise Information Systems Replace Extranets? (confusingly, a different article with the same title!)

Meme Agora: Tactics vs. Strategy (SOA & The Tarpit of Irrelevancy)

Enterprise Java Community: Extend the Data Grid With Hub-less Messaging

Services & Workflows: SOAP and REST with WCF and WWF

Year of the cloud

SOA equals Integration?

When I first encountered Duncan Cragg’s “REST dialogues” I was not sure how they would develop. As I have read more, I have become progressively more impressed. Cragg uses the style of a Socratic dialogue with an imaginary “eBay architect” to teach about the nature and use of REST techniques as an alternative to more traditional approaches such as SOAP and SOA.

Recent dialogues on Business Conversations and The Distributed Observer Pattern are particularly thought-provoking, but the whole growing series is definitely worth a read.

The REST Dialogues

It’s a common conundrum once a team embraces test-driven development (TDD). What becomes of the role of architect? Some suggestions include moving the role of the architect even higher than in a typical waterfall or “over the wall” process.

Sarah Taraporewalla’s Technical Ramblings » How does Architecture fit with TDD

My take on this is a bit different. One of the toughest things when developing software using TDD is choosing which tests to write next. This drives in a very real way the capabilities and design of the resulting system. At a low level the choice of test is often relatively easy, but at a higher level it can be easy to get lost in the detail.

So here’s my suggestion for the role of the architect in TDD-based development: driving the choice of high-level test cases to implement, and moderating the discussions between developers about how such test cases are split into finer tests and eventually implemented.

The benefits of TDD (evolutionary design, scaffolding, etc.) are still there, as is the input from an individual with collected understanding of which possibilities are implemented and which are not.

Thoughts?

An article drawing an analogy between the architecture of software systems and the structure of businesses. Might be useful, but the commenters hanve a lot of reservations.

InfoQ: Thoughts On Software Architecture and Corporate Structure

This article certainly echoes some things which I have observed. It’s hard to gain the full power of an agile approach, if the agile teams don’t have the ability to address issues across the whole solution. However tempting it may seem to solve the problem of team size by splitting teams across architectural boundaries, this is rarely a good way to solve big problems in a smart way.

Splitting teams by task or feature, and letting each team solve their task or feature in a way which is optimal in the context of the whole system, will almost always result in a more effective solution, and often a solution which is actually much simpler/cheaper than the way it might have been achieved if each team only considered one part of the system.

InfoQ: Choose Feature Teams over Component Teams for Agility

I have been banging on about this for ages. Modern RAM sizes are so huge, and so much faster and easier to use than disk, that a lot of traditional assumptions about enterprise architectures need radical revision.

InfoQ: RAM is the new disk…

One of the key tenets of the Service-Oriented Architecture (SOA) approach to software system design is the idea of loose coupling. In some cases it is pragmatically obvious whether one service is loosely or tightly coupled to another, but in the general case it can be tricky to determine. With that in mind InfoQ have produced an article on the topic.

InfoQ: Loose Coupling in SOA Defined

This looks interesting, as much for the business model of establishing credibility through writing a blog, then monetising it in offering training. I have met Simon Brown and do think he knows what he is on about, though, so if you are in the market for software architect training, this should be worth a look.

Software architecture training for £500 – Coding the Architecture

An interview touching on problems with using UML to document software architecture and designs

InfoQ: Markus Voelter about Software Architecture Documentation