intentional simplicity

INTENTIONAL SIMPLICITY

I believe that in this time we live in more than any other that came before it we are dealing with exponentials.

EXPONENTIAL GROWTH, EXPONENTIAL CHALLENGES AND EXPONENTIAL SOLUTIONS.

This theme manifests into both daily life and our businesses, and since our businesses are technology driven into technology too.

EXPONENTIAL TRANSLATES TO THE SHEER NUMBER OF TECHNOLOGY CHOICES WE NOW HAVE WHEN SOLVING THE NEEDS OF OUR BUSINESSES.

While in principle I believe this is positive it also brings with it the potential for complexity. Complexity inherently is required in some cases, it’s the unnecessary complexity we need to guard against.

Another consideration is the way we approach problems. How is it that we find ourselves with “legacy solutions”?

For me it’s quite simply two things: firstly, we’ve allowed ourselves to reach that position and secondly we have not been consciously optimising for the right things.

WHAT DO I MEAN BY THIS? Simply put, life is about choices – if we consciously or unconsciously chose to allow legacy this was our doing. Often legacy is the unintended outcome of optimising for only a few dimensions such a delivery velocity, business functionality over sustainability.

THIS TALKS TO ORGANIZATIONAL CULTURE AND WHETHER A CULTURE OF REFACTORING EXISTS – THIS HOWEVER IS NOT THE ONLY CONSIDERATION.

SO THE META QUESTION FOR ME BECOMES:

since we have been building software for decades what can be done differently to achieve a different and more sustainable outcome. As it happens there is much research on the subject of it complexity.

My experience is that it complexity mirrors business complexity – this my interpretation of conway’s law.

I BELIEVE THAT WHILE THIS IS TRUE, HOW WE CONSCIOUSLY PROMOTE INTENTIONAL SIMPLICITY COMES DOWN TO HOW WE THINK, DESIGN, ARCHITECT AND ULTIMATELY BUILD.

The fundamental shift that one needs to make is to move away from viewing businesses as being supported by platforms towards a capability view of an organisation.

THE CAPABILITY ORGANISATIONAL APPROACH PRESCRIBES THAT YOU NEED TO BREAK DOWN YOUR BUSINESS INTO CAPABILITIES.

Capabilities are at a granularity where they describe related sets of business functions, for example: valuation and settlement are two capabilities in a bank. Once you have done your business architecture work we can start talking about how you apply a new architecture approach.

ENTER THE SNOWMAN OR SIMPLE ITERATIVE PARTITIONS (SIP) ARCHITECTURE:

The Snowman Architecture talks about creating “Snowmen” for each capability

– essentially a small system for each capability. Business functionality is achieved by linking the required capabilities together by means of a messaging bus in accordance with a defined business process.

THE HEAD of the snowman contains the Business Architecture - practically what this contains is business logic which itself is comprised of the capability business process and related business rules.

THE BELLY OF THE SNOWMAN HOLDS THE TECHNICAL ARCHITECTURE OR TECHNICAL IMPLEMENTATION OF THIS BUSINESS LOGIC AS IT PERTAINS TO THE CAPABILITY BUSINESS PROCESS.

THE ARMS of the snowman represent the Service Architecture or service endpoints by which bidirectional communication is achieved through well-defined interfaces and through which snowmen interact.

THE BASE of the snowman encapsulates the Data Architecture which contains the data itself as well as the mechanism through which the belly of the snowman interacts.

It must be noted that the head of the snowman must only interact with the belly which in turn interacts with the base – IN THIS WAY WE ENSURE DESIGN CONSISTENCY.

Right so we’ve been through the theory, lets walk through a practical example of a snowman built for a valuation capability – A SIMPLE EXAMPLE. THE CAPABILITY IS REQUIRED TO PROVIDED VALUATIONS OF PRODUCTS GIVEN PRODUCT CHARACTERISTICS AND MARKET DATA.

Given this need the service endpoints (arms) of the snowman have a method that describes the interface that allows products to be valued given characteristics C and market data M. This method is implemented in the belly of the snowman, in the implementation the belly queries the head of the snowman for the valuation algorithm given C and M.

The head applies the relevant business logic to return the correct algorithm. Once returned this algorithm is executed and both the method input and outputs stored in the data layer (base) of the snowman before the valuation result is returned by means of the service endpoint.

So I understand the approach, can you articulate some of the benefits?

Sure, following the example above we can easily test our valuation capability. We understand its interfaces and expected outputs for a given data set. When we change our mind on how valuation will be done we simply build a new valuation snowman with the same interfaces and plug it in alongside the existing one for parallel run before we ultimately switch off the old snowman.

We understand dependencies as these are articulated in the service data contract. Capabilities are highly re-usable.

The most powerful value proposition for the snowman approach is that we can achieve true composition – in other words solutions can be composed for business by linking capabilities. The outcome of this composition ability is that it allows us to move product to market at great velocity.

IS THE SNOWMAN THE END, CERTAINLY NOT, ADOPTION OF THIS APPROACH TALKS TO THE CONSCIOUS MIND SHIFT THAT WE’VE MADE TOWARDS INTENTIONAL SIMPLICITY.

JASON SUTTIE www.jasonsuttie.net


intentional simplicity

Technology