Wow, has it really been another year since my last blog post?

I travelled up to Birmingham Science Park today and attended my first Open Space Coding Day, with the focus of the day being on Windows Azure. The format of the day was a new experience and completely different to what I have typically found at user-group sessions or a training course. The aim of the day is for everyone to learn from each other, rather than sitting through a rehearsed presentation of slides and demo code. Essentially, once the attendees have suggested, voted and scheduled a collection of topics for the day, they split up into groups who then collectively research that topic, or undertake a hands-on coding exercise together.

In all, there were around 40 attendees, and I think that with exception to a few, most of us were all Azure newbies. Microsoft was well represented, and in particular Eric Nelson and David Gristwood were available throughout the day to help out with the groups, and for answering everyone’s questions.

SQL Azure appeared to be the most popular topic, but for my part I wanted to remain more focused on the compute aspects of Azure. After deploying my first WebRole into the cloud (via the free service instances that were arranged for the attendees by Microsoft), I started developing a Distributed Grep solution made up of Worker Roles, WCF services and Queues. Obviously I hadn’t completed this by the end of the day – after all, I was there to learn, but I am planning on finishing this little pet-project, and I’ll hopefully contribute the code to the OpenSpaceCode Repository as soon as I can. In the meantime I’ll be frequently checking out the UK Azure Platform online-community (available on Ning) for future events, and to keep up to date with what others are learning and discovering and what they are building on the Azure platform.

To all those who have subscribed to, or regularly read my blog (there's not many I know but one can hope):
 
I have decided to abandon my attempt in building a Software Factory for 3-tier Enterprise solutions. I have decided to do this because of two principal reasons: The adventure was always supposed to be about getting exposure to the tools used in building Software Factories. I have realized that the sheer size and scope of 3-tier Enterprise applications will most likely interfere with that focus. I had intended to try and conceptualize the underlying Enterprise Framework, but this will be very difficult to do, plus it would detract from the product-line paradigm.
 
One day I may also want to begin talking about and presenting material on what I have learnt during the adventure. This will typically be with my own clients, but as the topic becomes more prominent, I may also look into public speaking. Again, the size and scope of 3-tier Enterprise applications would make this much more difficult.
 
Despite this, I am not abandoning my adventure with Software Factories. Instead I am going to select a domain that is much smaller and self-contained, and continue the adventure with that. I already have a few ideas and I'll post more over the next few days. I hope that you will agree that by adopting a smaller domain, the focus will remain on the tools themselves, and more importantly, the value that they may bring to the process.
 
While pondering my decision, I came across the NMVP Enterprise Factory that has been started on CodePlex. I will take a look at this project soon and possibly even try and contribute to it (if the project owner is willing). I will post more on that if it happens too.

Please note: I have removed some of the posts in the Software Factories category because they are no longer relevant. I will continue to add information about my adventures with Software Factories to the same area on the wiki. I really hope you continue following my adventure, albeit a slighty new one.

If you want to place a Guidance Automation recipe virtually anywhere within Visual Studio's menu structure, then here's a great tip for finding those menu Guids and Id's.

Jezz Santos has announced a mini-series of articles that will discuss the packaging and building of Software Factories. The first article discusses how the various assets of a Software Factory, such as the DSL's and Guidance Automation Packages, can be combined into a single MSI installer.

I found this useful article on MSDN regarding scenarios for integrating DSL's and Guidance Automation Packages:

Guidance Automation Toolkit and Domain-Specific Language Tools for Visual Studio 2005: Integration Scenarios

This will most likely come in handy later on.

Updated November 15, 2007

This post represents the first, in what I hope, will become a series based on my adventure in developing a Software Factory. I have been very keen on the concept of Model Driven Development ever since I first started reading up on UML 2.0, and kept encountering this other acronym - MDA. I was then fortunate enough to get involved in an MDA pilot project, securing some valuable experience and exposure with the concepts, and also convincing myself that this approach to software development was well worth looking into.

Shortly after, I came across Microsoft's Software Factory initiative (which is essentially a form of Software Product Line Engineering). I read, what is fast becoming, the seminal book on Software Factories, and have also pre-ordered the next book from Jack Greenfield which I'm hoping will be more concrete and less theoretical. I can rate the prior book very highly considering the number of times I have taken a highlighter pen to its paragraphs, and the number of Post It notes sticking out of its covers.

I think all Developers, Architects and Software Development Managers should keep a close eye on these methods. For me however, I think it's about time I started getting practical with Software Factories. I think the tools and technologies are mature enough to begin developing with - don't get me wrong, they still have a long way to go, but like the MDA pilot project - getting some experience and exposure with the concepts and tools can only be a good thing.

I came across this old post on Tad Anderson's Real World Software Architecture blog that provides a perspective on Guidance Automation and its potential impact on architecture. I think it shares the same sentiment that I had in one of my earlier posts, in that Guidance Automation allows Architects and Developers to capture and share knowledge explicitly rather than implicitly. The implementation of a Guidance Package takes knowledge and makes it a reusable intellectual asset that is directly executable. Furthermore, a Guidance Package can encapsulate the architectural decisions that have been made, and enforce their consistent implementation throughout the entire project.

Tad's post also talks about the cost of implementing Guidance Packages. They are after all, just pieces of software, and like other pieces of software, they need to go through a development lifecycle. That won't be cheap. Currently most Guidance Packages are bundled as part of a Software Factory, and Tad's post comments on their obvious suitability for software product lines. They will offer some value to developers working in the project space (especially when the GAT becomes more usable), however, the most value will be obtained when they're applied across the horizontal space - above all projects. To get there, organisations will need to focus more closely on frameworks and patterns.

I came to the end of a twelve month contract with a client recently, and as part of the exit strategy I spent an absolute age performing the hand-over process, and documenting my knowledge of the solutions that I touched during my time with them. The client recently introduced an internal Wiki allowing all project stakeholders to be kept more easily informed, and also to contribute to the solution knowledge-pool. I have to say that this was an excellent idea.

As part of my final weeks, I began writing some text on the Wiki that documented the processes that other developers could follow if they were required to make changes, or extend a particular piece of functionality within one of the solutions. It became clear to me that what I was ultimately documenting was a collection of recipes - something that other developers could follow if changes were to be made, or new functionality added. These recipes were documents that implicitly captured my knowledge of how to perform some technical implementation.
Read More...