Tag Archives: Consumable Solutions

A product it is … not a product.

What does MVP really mean…? (MVP – Minimal Viable Product)

That is a very interesting question. A first idea is to thing to the customer business needs: what are the minimal set of features that are needed and have relevance to be deployed first.
In fact, with this first delivery, we are initiating an ecosystem, where:

  • a business relationship with the customer(s) it is born, where the development side mus be able to follow the customer needs on short, medium and long term with good enough cost, quality, responsiveness and other possible attributes
  • the economics of this business relationship must be good enough for both sides
  • the development side must be able to find continuously effective and efficient technical solutions
  • the development side must form and maintain a product team with enough skills, maturity and availability to serve the customer needs
  • the process approach must make sure that enough business side feedback it is included in the product in order to make this product fit for the target business. Also the product must have such properties and included support in order to be  a consumable solution (DAD – Disciplined Agile Delivery concept)
  • the initiated approach must produce repeatable results (DAD principle)


A Minimum Viable Product it is in fact a Minimum Viable Product Ecosystem that could include:

  • Minimum Viable Consumable Product
  • Minimum Viable Product Economics
  • Minimum Viable Product Architecture / Design approach
  • Minimum Viable Team
  • Minimum Viable Process

It is not a product …. it is an endeavor, an enterprise, an initiated path to follow, a vision.

… yes, you first need some opportunities in the market, but you can blow up any opportunity without  considering above mentioned aspects.

A product is not …. (just) a product, it is an ecosystem that need to born, adapt and survive.

Reactive & Adaptive Products: built-in feedback

Reactive Manifesto

The Reactive Manifesto, initiated by Jonas Bonér, want to respond to the new context with “with multicore and cloud computing architectures […] with tighter SLAs in terms of lower latency, higher throughput, availability and close to linear scalability”

See more at: https://typesafe.com/blog/why_do_we_need_a_reactive_manifesto%3F#sthash.gP9WznCO.dpuf

Some default (software) systems requirements should be in such case these ones (quote, from below mentioned source):

  • react to events: the event-driven nature enables the following qualities
  • react to load: focus on scalability rather than single-user performance
  • react to failure: build resilient systems with the ability to recover at all levels
  • react to users: combine the above traits for an interactive user experience

See more at: https://typesafe.com/blog/why_do_we_need_a_reactive_manifesto%3F#sthash.gP9WznCO.dpuf


Requirements to be reactive

Well, that sound very interesting, but when it is transformed in the Manifesto (http://www.reactivemanifesto.org/), the resulted thing is a combination of requirements and solutions, because “message-driven”, async messages it is a solution, for example. My personal taste is to keep first the requirements, that seems to be more generic:

  • react to events, react to load, react to failure, react to users



I have some start questions

  • Before production: how could I know that I will build a system that will “enough reactive”, that will react enough to the load?
  • During production: how could I know that the real loading it is not bigger than estimated loading, for example, and what are the exact numbers in case of incidents?


 Traditional answers and beyond

The “traditional answer” is : “ok…we will do the needed performance tests“. Right! What about second type of questions, real loading and incident (or needed) analysis ? The next answer is that we will need also data gathering tools  built-in in the product, not (only) in offline tests.


 Adaptive products: built-in feedback

If we need to follow REACT types of requirement or similar, in an adaptive context (read Agile), we need to follow the principles of Adaptive Products and make sure that will not miss the link related to the early and continuous feedback from business/production back to the products. In such cases, the product itself should have the above mentioned data gathering tools  built-in in the product, not (only) in offline tests  (with a possible smarter option of self assessment).


Consumable Solutions: Measurable!

Reactive and similar properties of the software systems cannot be claimed if are not measurable in production and in tests. Using this feedback, the system could be configured or adapted by adequate changes.  Such capabilities of the products must be part of of the criteria for consumable solutions (concept used and introduced by DAD – Disciplined Agile Delivery). If the real capability of the system is not known, if there are incidents and if the needed information to adjust according to the needs  it is not available just-in-time, then it is not a consumable solution.

Some simple examples:

  • Events most be registered with occurring timestamp , start and end processing timestamps,  type of response
  • Details sub-processing data must be gathered if are significant
  • Number of events/processings should be registered if are bigger then and estimated threshold
  • System internal availability of various resources should be available for monitoring
  • More info should be “dumped” on incidents and fails


Update – Critical versus Important

(After a discussion thread with Martin Thompson on Reactive Systems Google group)

There are 2 kind of cases:

  • Systems where REACT capability is critical (such some financial systems) – the “elite
  • Systems where REACT capability it is important, but not critical – the “majority

The critical cases (the “elite“) need a complex approach with external and internal measurements, with specific care for high amount of non-linear data/events and accuracy of measurements in such context. In many cases, these are domains with specific regulation that request a mature approach for measurement.

The “majority” instead have rather an insufficient support for measurement. Also, in such cases, the cost of measurements could be important.  The best approach should consider smart, opportunistic  solutions, that will maximize the return of investment with less effort.  The built-in support for feedback could offer such solutions because have access to the “intimate knowledge” of the system, that mean most effective/efficient measurements..

The lesson is: Even if you know exactly what is going on in your system, measure performance, don’t speculate. You’ll learn something, and nine times out of ten, it won’t be that you were right!” – Ron Jeffries – “It Takes Awhile to Create Nothing” (from <Refactoring: Improving the Design of Existing Code>)

%d bloggers like this: