Decomposing systems with – The Method

The method

is the name of a service orientated software design methodology. It’s primary value proposition is that demonstrates a mechanical approach to software design leading to repeatable outcomes. The artifact of this process is a system decomposition, that maximizes operational flexibility, satisfies the runtime constraints and contains change at the component boundary. 

Invented by Juval Lowy and practiced today by IDesign it is indeed a remarkable system design methodology. It resolves many of the issues we face with modern software production. After completing the courses from IDesign (his company) you are left asking yourself how you ever built software without this knowledge.

Some of the practical highlights include:

  • Notation specification for showing all constraints of a modern SOA.
  • Calling out your components based on a method of seeking out business volatility, but at the same time preserving a good level of granularity.
  • Strict rules to categorize your components into, Resouce Access, Managers, Engines and Utilities.
  • Strict set of interaction rules between component categories. (Layered Architecture)
  • Strict set of rules for the responsibility of each component.
  • Deliniate the encapsulation of the primary sequence or use case orchestration from other activities.

On the downside for people like myself in Africa, his courses will cost the same price as a small house, once airfares and accommodation is taken into account.

That said, it is worth every cent and will probably save you loads money in the long run. In my view you cannot put a price tag on his courses it is priceless in my opinion.

I have had the privilege of working with Juval and spending some time with him both in Johannesburg and San Jose. Activities included a trip to the cradle of human kind, the lion park however the subject was always software 🙂

When I was attending the Project Design Master class in California he invited me to his farm.

The clarrity of his thoughts resonate practically with every aspect of his life. His farm is a system. It is off grid and there are designated components that manage every aspect. At heart he is an engineer, his passionate about technology and truly gifted.

If you can get onto one of his courses it will be an experience.

 

 

 

Why developers should not write features.

At least not in the context of the system …

Now I know this is going to create many comments and many will not agree with me, but allow me to explain why.

The reasons for my statement are many, but the one that comes to mind first is that feature specifications tends to be incorrect. They are also changing constantly as in reality they try to capture a dynamic real world problem in a static snapshot . The feature specification only presents a synopsis of the user interaction and the desired outcome. The user will do x in some way using y to achieve z.

Let’s suppose the outcome of our solution architecture was a system that resembled a car. The car had components like seats, wheels, engine and gearbox.

Your feature specification would come in the form of a user story that looks something like this:

Some <persona> will do some <action>  so that they can achieve some <goal>.

<Johnny> needs a vehicle he can <commute> to <get to work>.

<Sandra> needs a vehicle so that she can <transport goods> to <deliver the goods to the market>

<Bronwyn> must be able to <Park> the vehicle so that it <is not obstructing traffic>

… and so your feature specifications continue forever …

Given 3 developers and a sprint you would land up with the following components:

Commute

Parking

Goods Transport

 

In the physical world, one will not design a car, based on the feature spec that says the user needs to travel from home to work. In fact if there was a feature spec for a car, based on user stories, and we built each story, we would have a huge amount of components. Many of these components would be variations of the same thing. In the context of feature driven development methodologies how is it ever possible to call out the  gear box and engine components? Can you imagine how many variations of engine and gearbox you will have if each developer creates similar components for , parking, reversing, driving ….

A feature specification also lacks the detail of the non-functional characteristics of the system. What are the transaction boundaries, security contexts, process boundaries,  machine boundaries, error handling, availability / durability / scaling strategies?

Sadly in most cases system plumbing runs on a one to one implementation ratio with the feature of the day. This means your system begins to explode with components, as each developer derives there own strategy to support there particular feature in isolation. When the feature changes, the change tends to resonate with the entire system, often injecting loads of risk into the production pipe line.

Scrum (which I have nothing against) unfortunately tends to put features on a story board as opposed to components. Developers tend to sit around the table and pick which features they would like to build. This act substitutes the the action of architecture and system design  for the act of “give me the spec” and I will build “parking”. The problem is this code stays in the system and adds to technical debt of the project life cycle.

Much like anything we build in the physical world, a feature ONLY surfaces as the product of integrating the underlying components together.  An architect will compile the list of required components, based on the natureof the over arching problem and not the feature specifications.  The developers should be building the components, and then finally integrate the parts, into working software meeting specification, under the guidance of the architect.

It is for this reason that I say, developers should not build features in the context of the system, they should focus on building the gear boxes and the engines and forget about driving, parking and reversing. It is the job of the architect to ensure that the composition of components, can meet all requirements based on the nature of the business. The composition should also capture the business volatility as to contain change at the component level.

All of this is much easier said than done, and it is for this reason that so many software systems, become non-maintainable and are due for that inevitable re-write. The fact is is that the act of writing a user story or feature, is easier than considering the real nature of the problem, and encapsulating that which changes. The skilled software architect if supported by the business can literally save the business millions of R&D dollars.

It is for the very nature of change, that system design is so important. A well designed system, is easy to maintain, lower in risk and cost of ownership is radically reduced.

More on architecture to follow soon …

Please be sure to leave your rant below. Thanks for reading 🙂