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.


The language of SOA

23 October 2009

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.

Firstly, SOA used to, and still should, stand for an architecture that is service-oriented, with “architecture” being the noun. What I have found, though, is that more and more often people use “SOA” as an adjective and then add it to a more or less random noun, such as “approach” or “model” or even “architecture” again. Yes, I have heard people talk about an SOA Architecuture more than once.

This use of language highlights a problem. Sticking the three letters “SOA” onto a random noun, without pronouncing what the letters stand for, makes it easy to forget what this was all about in the first place. In fact, it seems that “SOA” is now put in front of words such as “approach” simply to make something sound contemporary; as in: “How’s your project?” — “Oh, we follow an SOA approach.” Given my experience, chances are that the project’s architecture is not service-oriented. It might use WS-* standards, though.

Secondly, there are people who are referred to as SOA professionals or similar. It usually sounds like it’s their job to build SOAs. But what does that really mean? Shouldn’t developers built software according to a service-oriented architecture? Are the SOA professionals merely advising teams on how to build service-oriented architectures correctly?

In my experience the SOA professionals have a different agenda, and that is to sell SOA. Unfortunately, in the words of my colleague Jim Webber, there are two things money can’t buy: love and an SOA. Again, using the three letters one might think “why not?” but spelled out, would anybody argue you can buy a service-oriented architecture? Or any architecture for that matter? So, what is really being sold is usually a set of products, software and/or hardware, that may or may not help a team implement a service-oriented architecture.

The key problem in this case is that when you “buy SOA” the success criteria shift. It seems that success is defined based on whether something that can be labelled “SOA” is in place, and not whether actual business value is delivered. What is often completely forgotten is an evaluation of the suitability of the architecture, but that’s a topic for another post.