It's taken me a while to post, this apologies for that.
The most important thing I got out of Roger Sessions' presentation at the January IASA NE meeting in Boston is that modularity helps reduce complexity.
I'm not sure Roger would put it that way, but I think he'd agree it's part of the solution to reducing the complexity of IT systems. I think his main message was that everyone needs to take reducing complexity into account whenever they're designing or upgrading an IT system. Just as you would design in security or usability, you'd design out complexity. So he says...
I'm starting to think that finding the right methodology, or the approach to software development is more important than ever. Much more important than technology per se. For one thing, I think we have the basic technology we need - operating systems, languages, databases, middleware, Web servers, etc.
For another, this often comes up in the debate over enterprise OSGi. A key issue around adoption of the OSGi programming model for enteprise applications appears to be the learning curve, or the mindset. Constructing applications using services is very different from using APIs, especially when the services support dynamic deployment, dynamic activation, and dynamic update.
Modularity is not limited to the OSGi framework at all, its variations include SOA, Web services, CORBA, .NET, Java EE, Spring, and so on. The potential relationship of complexity to modularity (i.e. as in adopting modularity as a technique to reduce complexity) was therefore the most interesting part of the presentation.
(BTW I realize this list mentions SOA and a list of technologies - typically SOA is mentioned as the approach rather than the technology. And this is correct. The most successful SOA projects I know of succeeded because of their "governance" - and I mean this in the logical sense of how people and projects are governed, not anything to do with registry or repository products. I believe the same will be true for finding industrial methods and reducing complexity through modularity.)
6 years ago
Posts
Hi Eric,
ReplyDeleteI wouldn't say that modularity reduces complexity, but it offers an approach (indeed, the only approach that we have) to managing complexity. This is the case not just in software engineering but in all the other engineering disciplines.
There is irreducible complexity in, say, building a software platform that prices millions of financial instruments every second, just as there is in building an aeroplane that can fly 500 people half way around the world. The human race is capable of building incredibly complex machines, such that no single human brain can understand them in complete detail (there are 6 million part in a Boeing 747, and 50 million lines of code in Windows Vista). Modularity simply allows us to divide the problem up into manageable chunks.
Neil
Good point. Actually I asked Roger about this during the presentation. Some things are inherently complex, as you point out.
ReplyDeleteI suppose a better title would have been "Modularity Can Help Reduce Complexity" or maybe more to your point "Modularity Can Help Manage Complexity."
Roger's response to this was to day that IT systems tend to be much more complex than necessary, and reducing complexity should be a goal of every project (and isn't today).
Eric
One needs to be careful when using the word "complexity". Any system capable of doing meaningful work must have some degree of internal complexity. Indeed a whole area of Science has grown around Complex Adaptive System.
ReplyDeleteIn contrast - accidental complexity is avoidable and results from a non optimal System design.
There is a real danger that unnecessarily exposed modularity will lead to a further explosion in accidental complexity in the Enterprise. What was previously an "opaque" BLOB - is now in its new modular form - operationally very complex.
To avoid such "accidental complexity", in conjunction with modularization one must also define appropriate levels of runtime / operational abstraction.
In a highly modular world, dynamic provisioning / self-assembled, distribution and autonomic management capabilities are no longer "nice to have" - but fundamental & critical in providing this abstraction.
Cheers
Richard
>approach to software development is more >important than ever
ReplyDeleteThis, in my mind, is about the most important statement here! It appears to me that we still do not really manage to understand what users want, nor do they understand what we are asking.
Why is it that on social networking sites, lots of people manage to get all sorts of good thigns done but, when faced with "mundane" activities such as their daily work, e.g., general ledger, production control, supply, marketing, billing, are unable to use their intimate knowledge and put it to good use by bringing together the componenents they need; or helping IT develop or modify them.
>For one thing, I think we have the basic >technology we need - operating systems, >languages, databases, middleware, Web servers, >etc.
I would add to this that we also have many of the application "components" we need. The problems start when trying to identify them and include them in "new" or "modified" versions of applications. SOA, SOI and all the other good techniques are great, but we still seem to have a hard time building the "right" software to allow domain-knowledgable users to build their "own" applications.
I can only hope that with all the great software out there now, the technologies and new approaches (open source and social networking along with cloud) will allow us to build [workflow] and [rules] engines which enable users to adjust applications (or components thereof) to suit their needs.
Cheers, John