Design for Business Agility: Can Mathematical Models be developed?

Sometimes, if you multi-task two different activities, your mind finds connections between them that would not be otherwise obvious.  I’m listening to a podcast on Design for Six Sigma and Design for Innovation in Manufacturing.  At the same time, I’m writing out e-mail on an integrated systems design that I’m working through with my internal organization.

So what occurs to me?  There are about a dozen different possible system designs that I could consider. I have built one design, but how do I know that it is right?  I can use principles and practices, but in reality, those principles are based on the experiences of other people, not science or math.  Just empirical observation.  My principles are based on good guesswork.

In a manufacturing environment, I could create a mathematical model, in software, that shows how changes to processes would impact the speed and quality of manufactured products.  I can consider different designs, and then introduce disruptive events, and watch the results.  But I cannot really do that in a software system design.

Here’s what I want to do.

I want to model a set of software services, with responsibilities and message composition built up, in a reasonable model of a solution.  I’d like to create four or five different models of the same solution, using different services (different responsibilities, different message composition).  Then I’d like to turn on simulation of each model to make sure that it performs reasonably well.  I can tell you now that all of these designs will probably work.

Then I want to introduce disruptive events like business change. I’d like to know which system designs are most able to stand up to changes in business strategies.  That means, which system designs will necessitate patterns of deployment behavior that creates an obstacle to agility.

In other words: Which designs, once implemented, drive people to make slow changes when fast changes are needed?

Principles and Patterns are based on experience.  That’s great.  But science and math should be considered as well.  Any ideas?

Comments

• Anonymous
  June 16, 2010
  Excellent idea. The framework could then provide approximations for the changing of services to se what each change would amount to. It is very common to only describe requirements for the functionality that should be delivered but not the change the solution should be able to handle. So in that regard it is a requirements issue, dont you think? I mean, it is all very well that we can provide a framework to test different designs (Im still for the idea) but the requirement should be defined upfront as a Time To Market for Product where both are clearly defined. Interesting idea and one I would really like to see come true

• Anonymous
  June 16, 2010
  Hi Nick, I did some training at the SEI at Carnegie Mellon a few years back and they demonstrated a tool called ArchE that you might want to have a look at.  I recall that the tool has some ability to quantify the sensitivity of a model to changes (i.e. if X changes Y and Z change at a cost of C).  I don't think the tool reasons at the business strategy level but the their technique may be a useful starting point. Mike

• Anonymous
  June 18, 2010
  It's possible that you could come up with such mathematical models, but I wonder how much external validity they would have outside of the setting of the organization from which they were developed.  Information technology is all about automating or enabling business processes.  A process is better measured by qualitative methods than quantitative because of the subjective nature of human action while carrying out these processes.  It is a fascinating idea but it makes me wonder if it were pulled off, if it would drive an even more deterministic approach to technology management by using it to justify bending the organizational structure and/or processes around to conform to the technologies.  

• Anonymous
  June 22, 2010
  Researchers have extensively studied manufacturing agility. You should look at the "Journal of Intelligent and Robotic Systems"  in a Springer publication where Nikos Tsourveloudis wrote "On the Measurement of Enterprise Agility". I wrote about this a number of years back (www.tomdebevoise.com/blog) Tom

• Anonymous
  June 22, 2010
  Researchers have extensively studied manufacturing agility. You should look at the "Journal of Intelligent and Robotic Systems"  in a Springer publication where Nikos Tsourveloudis wrote "On the Measurement of Enterprise Agility". I wrote about this a number of years back (www.tomdebevoise.com/blog) Tom

• Anonymous
  June 29, 2010
  One does not see very often this kind of trip to academic sphere, I must say, unfortunatelly:) I can honestly say that I would like to see such a model, or a tool or something. Nevertheless, I am not really convinced, that this is what we really need to make things agile. This is why I think so based on experience from 10000+ employees company and some 100+ systems/apps, where we've got some pretty agile and reasonably architected systems, but, what we very often face is and what makes us slow:

• in this (one might say big) environment there are only 2 functional releases yearly, which means huge integration, regression, UAT and other testing, planning releases looong ahead what will be in which release, which makes almost any change to take a year or more
• each architecture originates in a small scale within a project not focusing very much on highly parallel development and development models. This means really thought through who can do and change what, how integration of sources gets done among multiple teams, how layers are decoupled and linked together, how is the application package, deployed and so on. This is for many developers on a second track and it results always in a new fancy framework serving one huge application which sooones or later scales and maintaines badly.
• Architectural decision depend often not on appropriate placement of a certain functionality or appropriate design, but on current infrastructure and server/application availability. If higher availability is required from the application that's the most suitable to adopt the change, this is rather sacrificed and the piece of functionality is implemented in an application, which can fulfill the non functional requirements (availability, performance, backup).
• Vendor fights, dumping prices and muuuch more... ...are the reasons that I feel make the business not agile at the and, despite the fact that tools the business or developers want are cool and agile in presentations. They cease to be such the minute they go live in the whole environment and sooner or later there's another beast to feed. So my answer to agility would be much more simplicity (avoid complex and creative solutions to problems we probably do not even have), transparency (architect and design things so everybody can understand it), independence (our in our language decoupling), and proper placement of responsibility (place functionality/responsibility for a certain action where it belongs, not where one's got fancier tools to do it). These few principles are to my feeling paying off pretty much as far as I can say from my experience, and most importantly, the business and also project managers are those who can see it and realize the value. cheers Ondrej