In the general architecture section of the Handbook, I've collected a set of references (a glossary, personal contacts, books, papers, presentations, sites, and so forth). Recently, a couple of readers pointed me to their work, which I'd like to highlight here.
First, check out the work of Jeff Garland and Richard Anthony on Large-Scale Software Architecture on their site. I'd overlooked the publication of this book, but thanks to Amazon, a corresponding set of atoms should be flying itself to Colorado. Second, Vaughn Vernon pointed me to his project to codify enterprise architectures, with chapters being posted on TheServerSide.com. Thanks to both Jeff and Vaughn pointing me to their work.
Amazingly, I'm not scheduled to be on an airplane for a least two weeks, so I hope to make a dent in the physical pile of notes I've collected for the Handbook.[Read More]
Software architecture, software engineering, and Renaissance Jazz
From archive: October 2004 X
gbooch 120000P81R 649 Views
I see that Microsoft is poised to make some announcements about their offerings for domain-specific languages next week. I'll keep an open mind, but as I've posted before, I'm skeptical.
First, while I agree that development is a team sport and that multiple stakeholders must collaborate in weaving together their diverse, interdependent views, one still needs to have a common semantic basis for all those languages. If you accept that not unreasonable position, you will end up covering the identical semantic ground as has the UML - albeit in an open manner, quite unlike Microsoft's historical record. Second, does one really need separate languages or is it sufficient to provide a common language with acceptable variaions, as is the UML? As witnessed by the very slow take-up of C#, one may design a solid language but then you have to support that language, provide sites/papers/books/courses to help people become fluent in it, and in general build up a community of interest and a community of practice. If you do otherwise, you end up with just another isolated language that adds to the babble that every development organization already has to speak. Development teams need greater simplicity, not greater complexity, in their programmming model. Third, will any such set of domain-specific languages be sufficiently long-lived that any reasonable development organization would be willing to commit its people and resources to that set? If otherwise, then such languages may be useful for writing totally disposable software only: remember that useful software tends to live on, although often retouched over time, and that means if the support for its expression evaporates, then your organization is, at worst, left hanging or, at best, forced to spend the overhead of porting that expression to yet another form.[Read More]
gbooch 120000P81R 695 Views
I'm currently in Austin, participating in the annual meeting of the IBM Academy of Technology.
In an organization as large, deep, and broad as IBM, one on-going challenge is the exploitation of cross-divisional and cross-discipline integration. The Academy is an essential mechanism for IBM to bring this kind of integration about, primarily by throwing many of IBM's best and brightest into one mix so that connections can be made at deep technical levels. I just finished listening to a fascinating presentation on nanotechnology - where else could a software geek like me hear about the latest developments in this space, and get a coverage of the points of pain therein? Very high cool factor.
On a more pragmatic level, I connected with some of the folks who have pioneered performance and timing analysis tools for IBM's chip business. This is a field that's not only mature, but is pretty much at the core of all contemporary chip development processes. It didn't always use to be that way, but as the complexity of chips has grown, such best practices have proven essential to managing that complexity. In contrast, performance and timing analysis is highly underserved in most software shops except in obvious domains such as time-sensitive embedded systems. By way of reference, check out the pioneering work of Lloyd Williams and Connie Smith on performance engineering.[Read More]
gbooch 120000P81R 680 Views
Just ahead of the latest typhoon I escaped from Japan, where I also survived a 5.7 earthquake as well as my keynote for the first IBM Rational Software Development Conference which drew around 1,500 attendees. I always enjoy my time in Tokyo: the city is quite electric (literally and figuratively), I can find the best uni, the Park Hyatt Tokyo is one of the classiest hotels in the world, and there are some very cool projects with which to work. Alas, at the moment, I'm attached to the web via a supremely inferior connection which makes it painful to even type, so I'll have to defer the juicy details until I find a fatter pipe.
I was asked a most interesting question by one of the Japanese press: do I see any differences in development styles around the world? Warning lights flashed in my head, telling me that this was a classic black hole and that crossing its Schwarzschild radius would permit me to offer a really stupid answer that in turn would shower me with hate mail and proffer a visit to the principal's office. Emboldened by terminal jet lag, I gave a politically correct response (i.e. one void of any identifiable useful information). In retrospect, however, I can make the following observations (which, I must add, are my own and not representative of any other person, living or dead, or of any large, multinational corporations whose intials are each one off that of HAL): moving from east to west, I find - very much on average - European developers to be more formal, US East coast developers to be more conservative, US West coast developers to be greater risk-takers, and Asian developers to be more methodical.
Please please PLEASE don't read too much into these broad generalizations, for the microclimate of each individual team is unique, and I mean nothing pejorative by any of these terms. In the end, software development has been, is, and will remain fundamentally hard, and each team has to face its own demons, wrestling them to the ground with all the best moves and practices and tools that they have at their disposal.[Read More]