I enjoyed Harry Piereson’s well thought-out response to David Chappel’s entry on SOA and the Reality of Reuse. I couldn't have said it better myself, though that won’t stop me from trying. The way I see it, David brings to light the fact that the emperor has no clothes and then Harry tells you why the emperor is naked. The focus on business context in Harry’s entry really caused me to think about why business logic reuse fails.

The use of the word “context” stirred up in my mind the classic black box, gray box, white box argument. We can expect Java buttons or .NET Windows objects to behave in a low context, black box manner. From contextual business objects, we can at best expect gray box behavior; although white box is much more realistic. I guess in the box world, the opacity of the box is tantamount to the amount of context that can get through.

This said, in business object environments that demand high opacity/context, can and should we strive for reuse? I think the answer is still a resounding “yes”. We just need to do it in a realistic manner. So what does this mean? If our experience has shown that neither objects nor Web services are the appropriate level of abstraction for business logic reuse, where do we turn?

In my mind, analysis patterns provide the answer to this question. Analysis patterns are the long lost stepbrother of the popular design patterns. Martin Fowler does a great job of categorizing common analysis patterns in his book of the same name. However, it is Eric Evan’s Domain Driven Design book that provides the real insight into the process that will lead to analysis pattern identification.

The true beauty of analysis patterns is that they not only work within their target domain; they have the uncanny ability to shed new light on similar situations across domains. I can well imagine that the case transfer pattlet we created applies not only to the state government business domain for which it was intended, but also fairly well to the transfer of cases in the legal system domain.

In such high context, business rule driven transactions such as case transfers, I would never aspire to build a reusable object or service. Letting the analysis pattern speak for itself, I feel as if I’ve gotten all of the reuse capability I need to at that level. Attempting to create a standard programmatic solution that incorporates all the complexities of the pattlet’s context is likely to cause more problems than it solves. As caretakers of the business logic we need to understand the negative impacts of overengineering a solution and learn to use the right colored box for the job.

Programming Atlas, by Christopher Wentz, has not yet officially been released but I’ve had the chance to read it and keep up with progress through the O’Reilly Rough Cuts program. With its last update happening over a month ago, I anticipate that its now press ready and that a review of the book would be appropriate at this time.

Even though Atlas has not yet been officially released, this book is already a late comer to the market. It’s been beaten to market by a variety of AJAX texts that included some coverage of Atlas and at least one dedicated Atlas book from Apress. With all the press around Ajax and the huge Microsoft ASP.NET programmers market, putting out a book in the Atlas category is an opportunity that won’t be ignored by the major publishing houses. After trying out Atlas for a while during its Community Technology Preview (CTP) release and seeing the fairly extensive documentation and examples released by both Microsoft and the community, I tend to think that it’s an opportunity that they might best have chosen to ignore just the same.

Working through Christopher’s book, things appeared to be clustered into several sections. Although this is not officially the way the book is broken down, it makes the most sense from a reviewing standpoint:

• Introductory Chapters – Introduction to Atlas, AJAX, JavaScript, and client-side controls. This material takes up the first eight chapters (i.e. half) of the book and the information contained within can largely be garnered elsewhere including articles, books, and the Atlas documentation. If you’re not entirely new to AJAX, this section of materials is skimmable or skippable entirely.
• Server-Side Chapters – These chapters cover using server data, custom data sources, Web services, and cross-domain calls using a server proxy. This is by far the best original material in the book and is well worth a read.
• Atlas Implementation Chapters – This section covers the broadest array of topics. Some of it, such as extending controls and using Atlas with Web parts, is very interesting material. Other sections, such as Map mashups (using MapPoint, blah!), and the Atlas control toolkit (great tools, no value added above and beyond MS materials).
• “Other” Chapters – Certainly not what I bought the book for. Using Atlas with PHP, other AJAX tool coverage, although interesting, was put at the tail end of the book for a reason. This material could just have well been made into appendixes or omitted entirely.

All in all, Christopher’s writing style is good and he gives adequate coverage to the breadth of Atlas topics. This book might make for a good desk reference but is a tedious end-to-end read. Stick to the documentation or go for more pragmatic materials such as O’Reilly’s other offering in this area, Getting Started with Atlas, from their shortcuts series.

Following up on a long-standing desire to get domain knowledge out of our heads and onto paper, a colleague and I engaged in writing our first state government pattlet. We spent about two weeks of our spare time putting together an abstract approach to case transfer based upon our varied experiences. We finally have a draft version which we feel comfortable sharing online.

As far as I know, this is a first-of-its-kind endeavor for state government. We drew heavily on Fowler’s Analysis Patterns: Reusable Object Models as background material for documenting the patterns. The underlying analysis, design, and approach are all original, though. Please understand that the pattlet is not perfect. We’ve marked it as a 0.1 version to reflect its state and we intend to update it over the next couple of weeks.

We would really appreciate your feedback on the pattlet. Specifically, we’re looking to understand if there are important case transfer nuances which we missed, flaws in the analysis and design, or significant domain details which might shed new light on how to approach this problem. I know that most people feel very comfortable with email but I ask you to please consider using the comments section on this page. That way, everyone can benefit from your insights.

Note that the pattlet is licensed under the Creative Commons “Attribution Share-Alike” license. This license falls along the lines of common open source software licenses, allowing you to modify and re-disseminate this as you see fit, so long as you attribute the original work to us and any new work goes out under the same license as the original. We plan on distributing future pattlets under the same license. It seems to be a happy compromise between rights and reuse.

Right now, we are only giving access to the final product in PDF format but we have kicked around the idea of hosting sample code, pattern documents, and design models on a Subversion share. Let us know if this would be interesting or if we’d just be wasting our time in this endeavor. Finally, you can find the pattlet by clicking on the link below.

The nominations for the 2006 NASCIO state government recognition awards are now available online. There is some really interesting and innovative stuff in here. 

The article summary “Microsoft vs. Open Source: Who Will Win?” from the Harvard Business School (HBS) Working Knowledge magazine bubbled up on the del.icio.us most popular list this morning. Being that this is one of the “classic debates”, I felt compelled to give it a read. As one might expect of an economic publication from HBS, the material is relatively academic in nature. Some of the suggestions for folks in Redmond to remain competitive with the open source community sound great in theory but are unlikely to ever cut it outside the ivory towers. Price discrimination on Windows software is one repeated suggestion. At first glance, this appears very logical, since the marginal costs of distributing additional copies of Windows are near nil. However, this would lead to a very rapid deterioration in pricing structure  leaving little or no pricing transparency. People are agreeable with paying $300 for an iPod because they know that everyone else is in the same boat. People hate contracting for packaged software and buying cars because they always feel like they are getting screwed by the salesman who uses some secret formula to determine the price of the goods. Is this a perception that would increase Microsoft’s ability to remain competitive? I highly doubt it.

Aside from the purely academic nature of the write up, what irked me more was the choice of protagonists in this story. Microsoft versus Linux, Java versus .NET, scale up or scale out. These debates are just so passé. Large organizations don’t care about Microsoft versus open source – they buy software to minimize switching costs; reduce staff retraining, retention, and hiring costs; and to have a vendor to hold their hands when times get tough. Average PC buyers like my parents don’t care about Microsoft versus open source either – they want something that is easy, that meets their simple needs, and that runs. If the cost of this is bundled into the cost of the PC itself, they are blissfully ignorant of this fact. Most importantly, perhaps, is that Microsoft and the open source community are increasingly ambivalent.

Microsoft, despite its insistence to the contrary, is spending money hand over fist to catch up to Google and Yahoo. Yeah, these two competitors might run on open source software but that’s not what’s worrying Microsoft. It’s their business services and advertising revenues that has Microsoft concerned enough to plow money (to the tune of $500 million in FY ’06) from its cash cows, Windows and Office, into the risky venture they refer to as Windows Live. Linux, and its open source brethren, are taking on lives of their own in a world where the PC is likely to be marginalized in the not so distant future. Internet appliances, consumer devices, dedicated control systems and other “embedded applications” is one area where Linux shines.

Apparently someone cares about Microsoft versus open source though – those who funded the research. I couldn’t derive who that might be from the brief interview with the study’s authors but I’d be interested in finding out.

If you haven’t seen the materials yet on the Destiny USA project, it’s worth giving them a look. The official site is a masterpiece of Flash animation and in the Wikipedia entry, as always, you can find all of the details. The goal of the Destiny project is to create a one-of-a-kind eco-tourism complex encompassing shopping, entertainment, dining, and hotel accommodations in Syracuse, New York. The shopping complex would surpass the Mall of America as the country’s largest mall. The “green” touches included everything from a 100% fossil fuel free / sustainable energy operating goal and organically grown food in the restaurants to a glass-enclosed indoor park and 20 acre artificial lake. In addition, there are plans to create a research laboratory near Destiny for research into renewable energy, security, sustainable design, and more.

Destiny has received limited press outside of the upstate New York area but it deserves a whole lot more exposure, in my opinion. I found out about the project originally during my interviews with ThoughtWorks, which had been awarded the system integration contract for the Destiny project. Even after I decided not to accept the job offer from TW, I couldn’t get Destiny off of my mind. Now almost two years hence, I still find the time almost every week to see what’s up with Destiny.

Unfortunately, the Destiny project has been mired in red tape and controversy since it was first announced. Over the long term, financing has been the project’s biggest woe. At least one component of the combined Federal “Green Bonds”, state and local tax breaks and creative financing mix seems to be in question at a particular point in time. The biggest challenge that Destiny has faced since I’ve been following the project revolved around their rather unique attempt to buy out, at a fixed rate, the existing businesses that occupied land Destiny was claiming under eminent domain. Lots of fodder for an interesting legal and economic debate that’s done nothing but further impediment any progress.

What befuddles me most is that the people of Syracuse and the nearby communities are not breaking down walls to make this happen. I understand how one could have reservations about this project. It’s risky, capitalistic, would increase traffic in and around Syracuse, and could redefine the entire upstate New York economy. So why would anyone support this. Well, it’s risky, capitalistic, would increase traffic in and around Syracuse, and could redefine the entire upstate New York economy. Did I mention lots of high paying jobs and a mew source of tax revenue? Did I mention the cutting edge research laboratory that could make upstate New York the Silicon Valley of renewable energy? Did I mention that all of these new facilities are replacing an old brownfield that no one else wants to touch?

The SEP is based roughly upon the Rational Unified Process (RUP) and Microsoft Solutions Framework (MSF). Those looking at the sample assets will notice the similarities with the standard RUP templates. The process component of the SEP is specifically vague, leaving decisions such as formality versus agility, process activities, and roles to the projects employing the SEP. In particular, projects have several options for SEP customization including document-driven (RUP-style development case), local modifications to the process, or modifications with intent to contribute back changes to BSCoE for inclusion in the master SEP distribution. The SEP is conceptually similar in some ways to Ivar Jacobson’s new Essential Unified Process (EssUP). However, whereas the EssUP variability comes through the selection of practices, SEP’s variability comes through the selection of artifacts. 

For those of you thinking of creating your own software processes, I can only recommend the experience. Using the RUP and the Rational Method Composer or the MSF and the new Team System templates, although educational, is not an easy process. This is especially true if you intend to employ lightweight, agile processes on your projects. In this case, modifying the base processes from the RUP or MSF is tantamount to carving a chess piece from a sculpture sized block of marble.

Fortunately, as always, there are many that have gone before us in this endeavor. The sources highlighted below were of great help to us in the creation of our process and are highly recommended whether you require guidance or are just looking to better understand software engineering processes in general:

• Scott Ambler’s Writings – This guy is truly the best place to start when you’re looking for anything process related. All roads will eventually lead through his work. Particularly interesting are Scott’s Agile Unified Process and his Enterprise Unified Process. The former is a lightweight version of the RUP focusing on test driven development, agile modeling, agile database techniques, and refactoring. The latter is an extension to the RUP covering enterprise disciplines not mentioned in conjunction with many software processes such as portfolio management, enterprise architecture, strategic reuse, and software process improvement. In addition, it adds two new phases to the RUP, production and retirement.
• Philippe Kruchten’s Books – The two Addison-Wesley Professional books Rational Unified Process Made Easy and Rational Unified Process: An Introduction are seminal works on the RUP. Often overlooked is Software Engineering Processes: With the UPEDU, a book that runs through an educational version of the Unified Process with some pretty decent explanations and online examples.
• Craig Larman’s Books – Craig’s books, although not focused on process engineering or the intricacies of processes, convey an awful lot of information in real world contexts. Agile and Iterative Development: A Manager’s Guides is one of the best ways for non-techie types to get their arms around lower ceremony development processes. Applying UML and Patterns focuses on modeling and design patterns but does so in the context of a process using the Unified Process infused with Agile methods, making it a source of great contextual information.

In addition, we have been picking up reference artifacts along the way to illustrate best practices and real world examples. One of the artifacts that I fell in love with was the Yummy SAD, available online as HTML and downloadable in document format via FTP. This is one of the most generic, understandable, and widely-applicable examples of a software architecture document (SAD) that I have come across. One of the big selling points of the Yummy SAD is that aside from just being an artifact, it also comes with an approach to architectural decomposition. In particular, it espouses an architecturally significant use case / quality attributes based approach to documenting and realizing your architecture. Explaining software architecture in this fashion has helped me clarify the relevance and importance of the SAD on more than one occasion.

Please feel free to share any best practice artifact references or software process tips that you might help accumulated over the years in the comments section below.