My friend George Fairbanks is trying to make the case that the abstractions provided by ports, connectors, and components are the next escalation in the war against complexity and scale.
First, the good news…
Unfortunately (or maybe fortunately for you), many start Scrum without good engineering practices. I’m planning a talk with Noopur Davis at Agile2009 about this. Excerpt: “Simon, Struggling Agilist. Simon and his team have been using SCRUM and some agile practices for several iterations. They started out with great enthusiasm, but are now struggling as estimates are not improving, quality problems persist, and technical debt accumulates. Simon and his team want specific guidance on what they need to change.” We have data on a team that started with Scrum and added engineering practices of design, design review and code review. Their velocity went up and their defects/KLOC numbers improved significantly.
There is a tidal wave of folks who started Scrum without good engineering practices and now realize that they need them. You might try to ride that wave. Your best shot is with the Scrum folks who are now struggling. Lots of other folks are advocating more requirements and design work (iteration zero). You have another take on that.
Now the bad news…
Agilest will argue that feedback from actual running code is the best way to battle complexity and scale. Tighten the feedback loop with actual code. You can make more rapid progress by building something, even the wrong thing, and re-building it, than you can by wasting time modeling it and thinking about it because the assumptions you make when thinking about it always miss something important. You’ll call that something an insignificant detail. They’ll say, it’s the details that end up getting you.
I think you will lose the argument if someone comes up with a story about how Google’s (substitute, amazon web services, apache, or some other well known “big” system) massively scalable (although arguably not complex) system was created iteratively without any serious architecture work. Then, your approach to architecture is no longer design; it’s archeology, a concise way to document a system after a real engineer built it. I suspect that Eclipse was built with a more structured approach. Do you know if they followed an architecture approach?
Another way to lose the argument is by frameworks. I know architects whose job is mostly done once they decide what framework to use. Can you make the case that your approach could be used for them to make this decision? Be careful, most folks make the choice based upon things like how little boilerplate it makes you write, and the syntax of the templating language (Exhibit A). I see tons of discussion and thought go into the difference between SQLAlchemy and Hibernate’s approach to ORM versus RoR’s or Django’s. Can you address these things with your approach?
Alternatively, can you make the case that your approach could help in designing these frameworks? If that’s your goal, you limit your audience terribly and I’m still not convinced. Because for most design issues, I think most developers will prefer to use object-oriented terms and supplement that with OO design pattern terms when necessary. For instance, I recently worked on a team where we had to expand our system to support a remote service for storage (Amazon S3), whereas the system currently supported a local embedded storage. The conversation we had went something like this:
- Developer A: Let’s just put a remote proxy in front of the embedded storage interface with the same methods as the current embedded storage API. We can block on calls to S3.
- Developer B: Yeah, and if that’s too slow, we can add pre-fetch to the remote proxy.
- Developer C: I disagree. By doing that, any code calling this might not anticipate the delay. The more general model is the async one. Let’s bite the bullet now and implement a pub-sub “observer” eventing system and create our own internal async interface for storage. Let’s look at Dojo’s storage API for ideas on generality. Then when using the local storage, we’ll just immediately trigger the callback event.
We all agreed with Developer C and that’s what we did. How would you address this conversation with ports, connectors, and components? Is that approach any more concise or revealing? If your response is that you are really targeting higher level issues, then you’ve greatly limited your audience because (other than deciding what stack/framework to use) this scenario is and example of the highest level issues that most developers deal with.
What about massively parallel designs? Can you help there?
I’m not sure what the right answer is for you. I’ve never been much of a believer myself. I hate to say that without reading the other draft chapters. I’ll probably do that some time but I don’t have the time right now.
Maybe if you started with the patterns/styles and thought of the connectors, ports, and components as merely ways to express the styles, that would be more palatable to the average developer.
I don’t want to throw your own words back at you but do you remember writing this?
First, it had been assumed by many, including the architecture group,
that software architecture would be a readily teachable skill. This project
uncovered six competent, experienced developers who showed little aptitude
for creating architectural models.
Second, if this finding generalizes then it limits the way companies can use
software architects. The traditional approach to adopting a new technique is
simply to train people to use it, but this pilot shows that a software
architecture training program may be ineffective.
If you still believe what you wrote, then maybe you should be targeting architects not general developers. More bad news for you is that I think the use of the title “architect” is diminishing. Those folks still exist but they have new titles now. Or do you think you now have a better way to bring them along and make more “architects”?
Sorry to be so glum. I kept going because I was hoping to come up with a good angle for you. Instead, I just ended up with a long depressing discussion.