Sessions on Architectural Complexity

May 20

Books and Resources, Reviews, Software Process

Earlier this week, I attended a colloquium hosted by the Minnesota chapter of the IASA. The presenter was Roger Sessions, CTO of ObjectWatch, and the topic was “The IT Complexity Crisis”. The presentation was well-received by most of the audience, but I found myself somewhat at odds with the material.

The primary aim of the presentation was to outline a new approach to creating software architecture, which he says simplifies the architecture and reduces costs. Roger has written several books, the latest of which addresses the same topic (or so I would assume by the title, as I’ve not yet read it); and the presentation followed the same basic outline as a whitepaper that Roger authored, “The IT Complexity Crisis: Danger and Opportunity”. When it was published in November 2009, the paper drew much discussion and criticism; and I think it speaks highly of Mr. Sessions’s integrity that the download site for the paper lists many of the discussions; giving equal prominence to the critical ones as to those which are in agreement.

To cut to the chase, I do not take issue with the failure rates that were presented. I know that failure rates are high; and I’m not so much concerned with precise numbers, as with the relationship between project size and failure rates. I take him at his word on this; it corresponds closely enough with my own thoughts. I don’t take issue with the numbers used to illustrate the costs of these failures. The precise costs may or may not be estimable. Many companies simply don’t have the metrics to make decent estimates; but perhaps they can be inferred. Either way, I believe the costs are high, and while that waste contributes to IT employment, it also contributes to higher costs to taxpayers and consumers… which is a bad thing.

Where I have a problem is with the proposed solution. It’s not that I think it doesn’t work; it just seems like it’s been done before, only perhaps better… at least in some respects.

I mean no disrespect to Mr. Sessions. He is well-known and respected in the industry, he has substantial experience in business and IT architecture, and he clearly has done a great deal of study on the topic of IT Complexity. Despite his qualifications, however, it was my impression that the solutions he proposed were analogous, though somewhat inferior to, solutions that already exist. I am not the first to arrive at a similar conclusion ( see “David Sprott’s Blog”).

One of the first issues that Mr. Sessions brought up as a contributor to project failure, is mid-stream requirements changes. This is certainly an issue, and his methodology may do a little to alleviate that simply in forcing the originating organization to more closely analyze business requirements. That in itself is a tried and true method of reducing costs that is too often overlooked. However, other than that, his approach offered no real solution, just an assertion that any change would have a smaller impact due to a better defined division of responsibility. If we look at his Inter-library loan example, however, he gives us no requirements; only business functions. So let’s look at a possible requirement… “A borrower will receive a response from the lender within 30 seconds of making a request.” This requirement obviously affects at least the borrower and lender components; so I’m not sure that his approach offers any real advantage in this respect.

The first thing I noticed was that Mr. Sessions’s SIP process looks an awful lot like common use case analysis, with scenarios elaborated. In the example, his synergistic analysis really just groups the use case with its scenario dependencies. He uses this to establish the equivalent of “Knowledge Domains”, in MDA fashion. However he doesn’t continue the decomposition, instead he seems to consider the architecture to be only the top level domains. This is the first place where the approach falls down — it doesn’t decompose far enough.

Perhaps it was an ill-considered example; but the simplified “architecture” he proposed for inter-library loan was problematic. The white-paper doesn’t illustrate this as well as the slides he presented. Mr. Sessions’s SIP Generated Architecture for the Inter-library loan system resulted in three “synergy groups”, each one representing a discrete subsystem. The three components are the Borrower, the Lender, and the Inter-Library Loan Agency (ILLA). He asserts that each of these subsystems is self-contained, including a business function layer, a technical/code layer, and a data layer; and that each subsystem could be outsourced to a different vendor; and that vendor would have full latitude for all technical decisions, so long as the interfaces were met; and he stated that each vendor could select a different DBMS if they desired. In the white paper, the great simplification of his process is that the ILLA is no longer involved in the coordination of borrowing and lending; but now only maintains the catalog of available books. The presentation showed it a bit differently, in that the simplification was that it moved from a monolithic structure to a modular system of subsystems.

The first problem in the above example is that the end users aren’t Borrowers and Lenders; they are Libraries; and at any given time a library may borrow from or lend to any number of other libraries. This means that if the vendors select different database systems, as Mr. Sessions suggested they might; the Borrower and Lender subsystems will both be house in a single library using completely different codebases and completely different database systems. This is going to greatly increase operational and support costs for each of the using libraries.

The next issue I see is deployment issues. The SIP Generated architecture fails to consider that, at some point, changes will be required, and if each library has point-to-point connections with all other libraries, then interface versions must always be in sync among all sites. The design is much more robust when the ILLA brokers all transactions. The ILLA is kept up to date with any changes and can act as a communication bridge should versions get out of sync. I don’t see keeping the ILLA as a broker as being a significant contributor to complexity. Even without the point-to-point considerations, it effectively serves as a queueing mechanism, which may or may not be of value, and the added complexity is linear.

When I questioned Mr. Sessions about how his approach was superior to the use-case driven, domain oriented approach of Model-Driven Architecture, he said that MDA did not account for complexity, and in-fact had no concept of complexity. While complexity determination is not inherently required in MDA; reducing complexity is a best practice in all forms and at all levels of software development. The two most important design principles from the structured methods of the 70′s was coupling and cohesion; which are all about reducing complexity. Similarly, in the Agile/OO age, we have S.O.L.I.D. principles, several of which are about complexity reduction. As such, I don’t think it’s valid to say there is no concept of it in MDA; it’s just that the concept is assumed. Calculating or estimating complexity is something I tend to do in all of my larger modeled projects; and I do partition my designs accordingly, as I was educated to do. Most folks measure complexity less formally than Sessions suggests, but any relative measure should be equally valid. Another formalized approach is Function Point Analysis (FPA); which is widely used. There are also others, including more than a few variants of FPA; typically simplifications.

When another attendee asked Mr. Sessions about the duplication of code among systems, his response was that code re-use was not a consideration because nobody had found a way to make code re-use work anyway. While this statement at least rings of truth; it does not really address the question. I have worked on a large number of symmetric systems (as in the symmetry between borrow and lend); and almost always, both sides of the system are able to share much of the same “plumbing code” and structure. Data structure sharing is even more common. This is a form of complexity reduction. I find it difficult to accept that Mr. Sessions methodology actually creates enough efficiencies to overcome the loss of these reductions.

MDA is based upon the Shlaer-Mellor method of the early 90′s. In Shlaer-Mellor and MDA, the application is decomposed into many domains. While MDA is targetted directly for automated generation; Shlaer-Mellor was algorithmic, but automation was the pinnacle. The method embraced the concept that a domain could be produced externally or within the method, provided the interfaces and dependencies were fully defined. In Shlaer-Mellor, the first iteration looks much like SIP. The difference is that the initial domains would then be analyzed for their dependencies, which would be also organized into cohesive domains, and those domains for their dependencies, and so on, until the platform level is reached. Once the dependencies have been discovered then the interfaces are defined. At this point, each domain can be farmed out to a different group or vendor; and they can implement by any method, so long as they adhere to the interface specification. This maps well to Mr. Sessions view, except that it requires even more up front definition, and results in even smaller, but much more cohesive subsystems.

Mr. Sessions has a background in enterprise IT, while my background is primarily on the engineering side; which may account for our differing perspectives. I know that what he says is true; that large IT project fail at a rate that is functionally proportional to their size; but I don’t believe the cause of that is entirely due to complexity.

I suspect that much of the blame for IT large project failures tends to lay in the knowledge level of the average software developer. I will concede that this is not much more than conjecture on my part; and I can’t back it with numbers. It seems to me that large projects are implemented by large teams, and quite often such teams tend to be staffed with a higher concentration of less experienced developers. In addition to that, developers on the enterprise side tend to be graduates of CIS programs, where the emphasis on software design principles is less than in traditional CS programs. Hence, their designs may not scale well. The analogy that comes to mind is that of putting a home builder to work building a sky-scraper.

Embedded and process control applications, despite smaller typical sizes, can be extraordinarily complex when compared to business applications; performing complex calculations and brokering communications among several devices simultaneously, with very tight timing tolerances. Yet in my world it seems to me that the lowest success rates tend toward applications of moderate complexity. Why? My guess is that because codebase is much smaller, the highly complex projects are more often recognized as such, and the teams can be more easily staffed with more qualified personnel.

As a final point, I say again: I’m not saying Mr. Sessions’s methodology won’t work; I just believe that better methodologies exist. So why do we still have a problem? It seems that the more discipline and up-front planning a methodology requires, the less likely it is to go mainstream. It’s easier to let the planning work slip downstream for perceived short-term gains in schedule. If there is one advantage to Sessions’s approach, it is that it seems to make a clean break between the business-function allocation phase and the rest of development; and places that responsibility squarely in the hands of the customer. This means that the business analysis and high-level requirements will likely more complete than they might otherwise be.

If you wish to learn more about Roger Sessions ideas here are some more of his publications:
WhitePaper: “The IT Complexity Crisis: Danger and Opportunity”
WhitePaper: SIP Briefing: Part 1
WhitePaper: SIP Briefing: Part 2
WhitePaper: SIP Briefing: Part 3
Book: “Simple Architectures for Complex Enterprises”

So there you have it. A seasoned expert makes a well-reasoned argument with hard numbers and facts, and I challenge his conclusions with hubris, conjecture, and gut feel. It’s not rocket science, just My2Cents.

By the way — for those who are not in the know about S.O.L.I.D. design principals, I stumbled across this excellent tutorial by their creator, Robert Martin.

Books and Resources, links, model-driven-architecture, shlaer-mellor, Software Architecture, systems-architecture

Thanks for your response, Roger.

As I said, our professional practices are in vastly different arenas, and I would expect our perspectives to be very different. I also must apologize that I mixed some of what was offered in the presentation with items from the whitepaper; and I suspect that contributed to some misunderstandings on my part. I did not have the benefit of the presentation slides to re-visit some of the presentation topics, so I used the whitepaper as a poor substitute.

It appears that at least part of our disagreement is due to terminology. I was reacting in part to terminology I heard during your presentation; some of which may have been raised in addressing audience questions. Your papers do a good job of clarifying your position on some of these issues. For example, Part 1 of your SIP briefing states: “SIP is not intended to replace existing enterprise architecture methodologies. It is intended to provide a meta-methodology on top of them.” If that was stated in the meeting, I missed it.

The “business requirements” statement was again, in response to what I recall being said in the presentation. You opened the presentation with a statement about the contribution of moving requirements to the cost of projects. This lead me to believe that you were in some way addressing that issue. The term “business requirement” was used at least a few times, apparently in reference to the business functions; and this lead to some confusion.

As to my assertion about multiple database systems, this answered a response you gave to an audience question. You stated that the various subsystems could be contracted to different vendors, and that if they shared a common underlying database system, that would be coincidental. I also spoke with at least a few audience members who had trouble with that idea; as well as each sub-project having to originate duplicative “plumbing code”. These were probably the two biggest objections to the whole concept. If your claim is that EVERY partition, can and/or should be outsourced to a unique development group, that’s where I think the method falls down.

As to simplification, I don’t know what common practice is, but I don’t consider it to be only with code. Design simplification typically yields much greater benefit than code simplification. I spend a great deal of effort ensuring that the architecture is as simple as I can get it. I will suggest again that this has been a best practice for decades. This is exemplified by the following passage from “The Practical Guide to Structured Systems Design, 2nd ed.”, 1988 (Mielir Page-Jones): “Reducing the coupling between modules means, in effect, reducing the complexity of the connection(s) between the modules as much as possible. To paraphrase Einstein, we seek to make such connections as simple as the application will allow, and no simpler.” In the chapter on cohesion, the book goes on to say: “Cohesion is the measure of the strength of functional relatedness of elements within a module.”; similar information about reducing design complexity has been present in every design book I’ve ever bothered to look at. Unfortunately, I suspect that your perspective may be correct, that design level simplification may not be done as it should be in general practice.

I disagree with your assessment that there is a correlation between re-use and complexity. My experience indicates that the biggest barrier to re-use is the lack of effective repositories and indexing tools. Methods such as Shlaer-Mellor and MDA encourage coarse code re-use at the domain (architectural element) level; and that has seen success in some companies, but few are willing to share details of their gains. On the other hand, I think code sharing among cooperating subsystems is very common practice, and tends to lead to better designs. It sounds as if we are in agreement on this; but my argument was that your approach seems to discount the potential value.

As you’ve made your claims explicit, I’d like to address them directly;

“Synergistic partitioning is based on the mathematics of partitions. No other IT methodology is based on a mathematical foundation.”
ALL of IT is based on mathematical foundations, from relational database theory to language semantics; and there have been other numerous attempts to apply a mathematical approach to software development (for example, see this 1998 paper). Still, we tend to take an informal approach to all levels of software development.

In safety-critical domains there is a well known methodology to verification, called “Formal Methods” by which you can prove many of the operational and safety aspects of software mathematically with lower costs and greater efficacy than testing; yet organizations don’t do it because they perceive the formalism and discipline required as a productivity hindrance, rather seeing the benefit of reduced testing. I think that development methodologies tend to be informal because formal algorithmic approaches don’t get adopted. The advantage that your approach appears to have is that it yields some reasonably good partitions with relatively small effort. This improves the chance of adoption.
“Synergistic partitioning drives a unique solution. For a given universe of functionality, there is only one possible solution. No other IT methodology has a unique solution.”
I am inclined to accept this claim at face value, though I suspect that differences may arise due to how and to what level of detail the business functions are elaborated; and perhaps also due to assumptions and pre-conceptions about the architecture.
“The resulting partition is the simplest possible partition. There is no other approach that can discover a better configuration.”
It may be unique, and functional cohesion and communications coupling are certainly large factors; but I am still skeptical that this unique solution is necessarily an optimal one. I don’t disagree with the partitioning as a useful tool, but I’m not as certain that for the universe of all possible projects, the partitions provided are neccessarily the best divisions, or that they can be always farmed out as stand-alone projects. On the other hand, they are almost certainly excellent starting points.
“The resulting reduction in complexity can be measured and translated into actual business dollars.”
I agree that cost variability is probably reduced; only because I’ve seen some absolutely attrocious designs. That the reduction in complexity can be translated to actual business dollars is dependent on knowing how the alternative approach will address complexity. In terms of outsourced projects, I think that your approach, applied by the customer, would reduce opportunism by vendors; even if the entire project was still given to a single vendor.

Since my initial post, I’ve had a bit more time to review your papers. Your SIP(tm) approach certainly has some interesting and useful properties. I will be on the lookout for opportunities to put it to the test.

There are some aspects about your approach that I really do like. As I stated in my post, there have been attempts to quantify complexity, particularly as an aspect of difficulty. I believe your quantification method does provide a good measure. Furthermore I believe that an algorithmic and deterministic approach to partitioning may be of benefit, particularly when pushed up to the business analysis level.

It appears to me that your method may lend itself to automation tools which can simplify the production of the top level architecture. I can also imagine that within each partition a number of partition functions could be elaborated as a decomposition excercise; and that this would permit recursive decomposition of a more complete architecture.

Best of Luck! I look forward to seeing what the future has in store for your methodology.

– Max

Bookstore

Comments

Roger Sessions

May 22nd, 2010 at 3:22 PM

Thanks for blogging about my talk! You have raised some interesting points. Let me tackle them one at a time.

You say I have outlined a new approach to creating software architecture. I don’t think this is right. I have outlined a new approach for partitioning projects so their complexity is minimized, thus removing the main barrier to creating good software architectures. Creating a software architecture is something that occurs much later. I would agree, though, that the process partitioning that I recommend puts some constraints on the eventual software architectures that can be created.

You say that the solutions I propose are analogous but inferior to solutions that already exist. I disagree. I haven’t seen anybody proposing system simplification through partitioning of functionality through use of synergy analysis. So we can discuss whether my methods are better or worse than others, but they are clearly unique. Here are four claims I make for my methodology that I haven’t heard anybody else make (and I don’t believe anybody else can make):
- Synergistic partitioning is based on the mathematics of partitions. No other IT methodology is based on a mathematical foundation.
- Synergistic partitioning drives a unique solution. For a given universe of functionality, there is only one possible solution. No other IT methodology has a unique solution.
- The resulting partition is the simplest possible partition. There is no other approach that can discover a better configuration.
- The resulting reduction in complexity can be measured and translated into actual business dollars.

You say my approach forces an organization to more closely analyze business requirements. Actually, my approach doesn’t deal with business requirements at all. Only business functions. In other words, I look at what the system does, not how it does it or what specific requirements it must satisfy in doing what it does. It isn’t that I don’t think business requirements are important, just that they come much later, after we have partitioned the business functionality.

You say I don’t decompose far enough. I disagree. I decompose exactly as far as necessary to identify the atomic business functions. And then I stop. I don’t care how they will be implemented, either at the business architecture or technical architectural level. Not that these things aren’t important. Just that they are a different problem than what I am addressing. And just to be sure we are on the same page, my problem is Complexity. I am assuming that once you have addressed complexity, the other problems (like business requirements) are much easier to address.

You say that a problem with my example, inter-library loans, is that we could end up with multiple database systems and that this will “increase operational and support costs for each of the using libraries.” I disagree. Not only does the system I proposed have no need for multiple databases, it has no need for ANY databases. The inter-library coordinator can do its work on a simple spreadsheet or file system. The Borrower system doesn’t need to store anything, it just refers to the recent catalog the coordinator sent out. And the Lender is unlikely to have its own database, it will most likely just use whatever the library is using to maintain its book collection.

You say “complexity reduction is a best practice in all forms and all levels of software development.” I agree. But when we are reducing complexity in software development, we are generally talking about simplifying our code. This is quite a different issue than reducing our overall project complexity. I assume that we are trying to do the best possible implementation job. But this does nothing to address the complexity I am looking at: the complexity of how the project is organized.

You imply that I am against code reuse. Guilty. Well, almost guilty. I believe that any attempt to reuse code must be balanced against resulting complexity. Almost all attempts to reuse code result in more complexity, and thus create more problems than they solve. By the way, the example you give of reuse is more of what I think of moving functionality into the infrastructure, which is another issue and which I endorse.

So let me summarize where I stand. I am addressing one issue only: Complexity. I am trying to understand how to best split up a project into subprojects such that
- the overall complexity of the subprojects is as low as possible
- the suprojects can be tackled as autonomously as possible
- there are as few dependencies as possible between the subprojects.

That is all I am trying to do. But in doing this, you can reduce the cost of a $10M project by 50% and increase the chances of that project being successful by 100%. Which makes this effort worth undertaking, the methodology important, and the approach unique.

That’s my two cents!

- Roger Sessions
Max H
May 24th, 2010 at 6:04 PM
Thanks for your response, Roger.

As I said, our professional practices are in vastly different arenas, and I would expect our perspectives to be very different. I also must apologize that I mixed some of what was offered in the presentation with items from the whitepaper; and I suspect that contributed to some misunderstandings on my part. I did not have the benefit of the presentation slides to re-visit some of the presentation topics, so I used the whitepaper as a poor substitute.

It appears that at least part of our disagreement is due to terminology. I was reacting in part to terminology I heard during your presentation; some of which may have been raised in addressing audience questions. Your papers do a good job of clarifying your position on some of these issues. For example, Part 1 of your SIP briefing states: “SIP is not intended to replace existing enterprise architecture methodologies. It is intended to provide a meta-methodology on top of them.” If that was stated in the meeting, I missed it.

The “business requirements” statement was again, in response to what I recall being said in the presentation. You opened the presentation with a statement about the contribution of moving requirements to the cost of projects. This lead me to believe that you were in some way addressing that issue. The term “business requirement” was used at least a few times, apparently in reference to the business functions; and this lead to some confusion.

As to my assertion about multiple database systems, this answered a response you gave to an audience question. You stated that the various subsystems could be contracted to different vendors, and that if they shared a common underlying database system, that would be coincidental. I also spoke with at least a few audience members who had trouble with that idea; as well as each sub-project having to originate duplicative “plumbing code”. These were probably the two biggest objections to the whole concept. If your claim is that EVERY partition, can and/or should be outsourced to a unique development group, that’s where I think the method falls down.

As to simplification, I don’t know what common practice is, but I don’t consider it to be only with code. Design simplification typically yields much greater benefit than code simplification. I spend a great deal of effort ensuring that the architecture is as simple as I can get it. I will suggest again that this has been a best practice for decades. This is exemplified by the following passage from “The Practical Guide to Structured Systems Design, 2nd ed.”, 1988 (Mielir Page-Jones): “Reducing the coupling between modules means, in effect, reducing the complexity of the connection(s) between the modules as much as possible. To paraphrase Einstein, we seek to make such connections as simple as the application will allow, and no simpler.” In the chapter on cohesion, the book goes on to say: “Cohesion is the measure of the strength of functional relatedness of elements within a module.”; similar information about reducing design complexity has been present in every design book I’ve ever bothered to look at. Unfortunately, I suspect that your perspective may be correct, that design level simplification may not be done as it should be in general practice.

I disagree with your assessment that there is a correlation between re-use and complexity. My experience indicates that the biggest barrier to re-use is the lack of effective repositories and indexing tools. Methods such as Shlaer-Mellor and MDA encourage coarse code re-use at the domain (architectural element) level; and that has seen success in some companies, but few are willing to share details of their gains. On the other hand, I think code sharing among cooperating subsystems is very common practice, and tends to lead to better designs. It sounds as if we are in agreement on this; but my argument was that your approach seems to discount the potential value.

As you’ve made your claims explicit, I’d like to address them directly;
- “Synergistic partitioning is based on the mathematics of partitions. No other IT methodology is based on a mathematical foundation.”
  ALL of IT is based on mathematical foundations, from relational database theory to language semantics; and there have been other numerous attempts to apply a mathematical approach to software development (for example, see this 1998 paper). Still, we tend to take an informal approach to all levels of software development.
  
  In safety-critical domains there is a well known methodology to verification, called “Formal Methods” by which you can prove many of the operational and safety aspects of software mathematically with lower costs and greater efficacy than testing; yet organizations don’t do it because they perceive the formalism and discipline required as a productivity hindrance, rather seeing the benefit of reduced testing. I think that development methodologies tend to be informal because formal algorithmic approaches don’t get adopted. The advantage that your approach appears to have is that it yields some reasonably good partitions with relatively small effort. This improves the chance of adoption.
- “Synergistic partitioning drives a unique solution. For a given universe of functionality, there is only one possible solution. No other IT methodology has a unique solution.”
  I am inclined to accept this claim at face value, though I suspect that differences may arise due to how and to what level of detail the business functions are elaborated; and perhaps also due to assumptions and pre-conceptions about the architecture.
- “The resulting partition is the simplest possible partition. There is no other approach that can discover a better configuration.”
  It may be unique, and functional cohesion and communications coupling are certainly large factors; but I am still skeptical that this unique solution is necessarily an optimal one. I don’t disagree with the partitioning as a useful tool, but I’m not as certain that for the universe of all possible projects, the partitions provided are neccessarily the best divisions, or that they can be always farmed out as stand-alone projects. On the other hand, they are almost certainly excellent starting points.
- “The resulting reduction in complexity can be measured and translated into actual business dollars.”
  I agree that cost variability is probably reduced; only because I’ve seen some absolutely attrocious designs. That the reduction in complexity can be translated to actual business dollars is dependent on knowing how the alternative approach will address complexity. In terms of outsourced projects, I think that your approach, applied by the customer, would reduce opportunism by vendors; even if the entire project was still given to a single vendor.
Since my initial post, I’ve had a bit more time to review your papers. Your SIP(tm) approach certainly has some interesting and useful properties. I will be on the lookout for opportunities to put it to the test.

There are some aspects about your approach that I really do like. As I stated in my post, there have been attempts to quantify complexity, particularly as an aspect of difficulty. I believe your quantification method does provide a good measure. Furthermore I believe that an algorithmic and deterministic approach to partitioning may be of benefit, particularly when pushed up to the business analysis level.

It appears to me that your method may lend itself to automation tools which can simplify the production of the top level architecture. I can also imagine that within each partition a number of partition functions could be elaborated as a decomposition excercise; and that this would permit recursive decomposition of a more complete architecture.

Best of Luck! I look forward to seeing what the future has in store for your methodology.

– Max
xtranguru

September 19th, 2010 at 6:03 PM

Hmm. For a long time, both as a software engineer and as an architect, I’ve been using what I call the “cocktail shaker” method of designing and implementing software systems. This combines top-down functional decomposition of the requirements problem domain with bottom-up identification of the common primitives that will be needed, both domain-specific and domain-independent. If done right, the process meets in the middle, with the functional decomposition being implemented in terms of the primitives. This also maximizes reuse, because the primitives, by their nature, are almost always candidates for reuse. (I assume a “primitive librarian” to oversee all of this — a critical position, to be filled by the best person who can be found and afforded.)

With this “cocktail-shaker” approach, the functional decomposition and the primitive identification are intimately related; they are done on concert and cannot be separated. In fact, the primitives ID usually shapes the functional decomposition as it progress, and vice versa. Furthermore, both aspects of the design need to be done by very experienced and skilled people, and as few as possible of them. Brooks’ law applies with a vengeance…

A key to all of this, IMHO, is doing a comprehensive ERD as a first step; it will clarify the relationships among the data of the problem, which in turn begins to suggest the design architecture, leading to the implementation architecture. Of course, the data schema will change, but not as much as functional requirements usually do, so maintaining the ERD, once created, shouldn’t be unduly burdensome. The ERD also serves as an “anchor” as functional requirements change — sometimes a proposed requirements change will, upon being related to the ERD, be discovered to be not such a good idea, or a better way to achieve the change’s objective is discovered.

I also think that this “cocktail-shaker” approach is orthogonal to competing methodologies such as waterfall vs. Agile.

BTW, Capers Jones’s stats show that reuse is far and away the most effective approach to reducing software defects; nothing else even comes close. And I have made reuse a part of my professional practice for a very long time. I have created, and currently babysit, 1/2 million lines of C that are rife with reuse at just about every conceivable level.

In fact, IMHO identifying reusable components (resulting in run libraries and OO classes) is an inherent part of a software architect’s or engineer’s skill set. I do agree that it’s really difficult to get many enterprises to make the necessary skills investments to achieve it, which is very sad.

You must be logged in to post a comment.

M	T	W	T	F	S	S
« Oct				Jun »
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31

My2Cents