On this page.... RSS 2.0 | Atom 1.0 | CDF
# Friday, January 11, 2008

This thought occurred to me the other day.  Maybe the right approach to managing complexity in business software is something akin to creating a biological ecosystem.  By this, I mean designing correcting mechanisms to address chaos as it emerges and, ultimately, (the dream) would be designing systems that are biologically aggressive, that is, they look for niches to fill and also take steps to preserve themselves.

I don't know.  I'm sure I'm not the first person to think about this.  It just hit me the other day as I was walking into work.  It seems like the more common approach we take is to try to create a mechanical system as if the complexities of human interactions (i.e., business) can be specified and accounted for in a closed system.

I attended a session on managing complexity at the ITARC in San Diego last October, and the presenter was, if I recall correctly, advocating the usage of more precise specification of business rules through the use of Object Role Modeling (and in fact Dr. Terry Halpin was in attendance at that session and was a active participant).  I had attended another session the previous day by a fellow from Fair Isaacs on business rule management software.

All of these folks struck me as very intelligent and knowledgeable, and yet it seems to me that they are going in exactly the wrong direction.  In fact, I left that conference feeling very whelmed.  I felt as if I were living in a separate universe; at least I got the sense that there is a software multiverse, parallel software development universes, with me living in one and a lot of those guys in another.  All this talk of "governance" and highfalutin systems (e.g., grid SOA) leaves one feeling so disconnected from the everyday experience of being a software professional.

It seems to me that the solution to complexity in IT is not to create ever more complex mechanical systems, policies, and infrastructure to "govern" the problem.  It seems like that's throwing gasoline on the fire.  Not only that, it seems fundamentally opposed to the reality that is business, which is essentially a human enterprise based on humans interacting with other humans, usually trying to convince other humans to give them money instead of giving it to some other humans that want their money.

Because humans are intelligent and adaptable, particularly humans driven by, dare I say, greed (or at least self-preservation), these humans are constantly tweaking how they convince other humans to give them money.  The point is, business is fundamentally a human and an aggressively biological, enterprise.  It consists of humans who are constantly on the lookout to fill new niches and aggressively defending their territories.  So it seems to me that business software should be modeled, at a fundamental level, on this paradigm rather than on the mechanical paradigm. 

Of course, the problem is that the materials we're working with are not exactly conducive to that, but therein lies the challenge.  I tend to think that the efforts and direction being made by the agile community and approaches like domain-driven design are headed in the right direction.  At least they're focusing on the human aspects of software development and focusing in on the core business domains.  That's the right perspective to take.

Extend that to IT governance, and that means giving various IT departments within an enterprise the freedom to function in the best way that meets the needs of their local business units rather than trying to establish a monolithic, central architecture that attempts to handle all needs (think local government versus federal government).  It means developing with a focus on correction rather than anticipation, building leaner so that when change is needed, it is less costly (in a retrospective sense as well as in total cost of ownership).

I'm not advocating giving ourselves over to the chaos; I'm just thinking that this is a better way to manage the chaos.  And as we learn the best patterns to manage complexity in this way, it seems not too far a stretch to think that we could start automating mechanisms that help software systems be ever more agile and ultimately even anticipate the change that is needed by the business, either automatically making the adjustments needed or at the very least suggesting them.  That would be true business intelligence in software.

Maybe it's a pipe dream, but I think that without such dreams, we don't improve.  At the very least, I think it suggests that the agile approach to software is the right one, and that this approach should be extended and improved, not only in software development but also in architecture and IT in general.

What do you think?

Friday, January 11, 2008 12:01:33 AM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [2]  | 
Wednesday, January 16, 2008 1:06:13 AM (Eastern Standard Time, UTC-05:00)
Some have said the future of software is Lego blocks. Buy the components you want, slap them together and wala you have your custom system to suit your business/personal needs.

Is it difficult to achieve that? Looking at the current (Sorry) state of the software industry, I think it is incredibly difficult. Perhaps not our generation but the next few who will attain the maturity of thought to produce such architectures and ecosystems.

For now, we all have to content with Change Request and Management :-D
Wednesday, January 16, 2008 10:34:21 AM (Eastern Standard Time, UTC-05:00)
Hi Aaron,

Thanks for the thoughts.

I don't buy the Lego blocks idea. They tried that in physical architecture, and it didn't really work that well (some would say it was a travesty). The problem is partially that we humans don't like that kind of monotony, and part of it is simply that the solutions just really didn't fit the problem well. This would be exacerbated in software due precisely to what I'm driving at in this blog--more than physical architecture, we're talking about building something based on the ever-morphing needs of human enterprise.
Comments are closed.

Disclaimer
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.

Thanks to the good folks at dasBlog!

Copyright © 2014 J. Ambrose Little