Monthly Archives: September 2010

The Limits of Software Patterns

There has been a discussion going on Readify Tech (and internal mailing list at Readify) for the last day or so about how business logic is driven/affected by the user interface. One of the interesting points to come out of it is the extent to which software patterns such as MVP/MVC can be used to build truly UI agnostic Presenters or Controllers.

There are a number of software patterns out there that say that they can effectively provide that separation so that logic is reusable, but do they really deliver on that promise?

Personally I think that the reality is that your View, Model and Controller/Presenter are going to be highly optimised for the specific screen that you are delivering on, and in fact it may not be possible to reuse the source anyway. Your ASP.NET Controller isn’t really going to be able to run on your Windows Phone device so why pretend that you can? And even if it did the implementation of the controller is going to make assumptions about the locality of the data that it can access.

Patterns such as MVC and MVP are completely valid, but I wish the proponents wouldn’t make assertions that can’t be backed up.

The Tyranny of .NET Namespaces (cont’d)

A few moments ago I through up a post about when and were to use the namespacing convention for project names inside a Visual Studio solution. I am definitely for naming a project (and the outputted assembly) something which patches the common root within the classes contained within the assembly. So if I had an assembly with the following structure:

  • Company.Product (namespace/assembly root)
    • DomainModel (namespace)
      • Customer (class)
      • Order (class)
      • Opportunity (class)
    • Mailer (namespace)
      • IMailer (interface)
      • SmtpMailer (interface)

I’d probably name the project and assembly Company.Product, if for some reason I split the mailer up from the domain model (a deployment consideration) I’d probably case the two assemblies like this:

  • Company.Product.DomainModel (namespace/assembly root)
    • Customer (class)
    • Order (class)
    • Opportunity (class)

All in the Company.Product.DomainModel assembly, and the mailer as follows:

  • Company.Product.Mailer (namespace/assembly root)
    • IMailer (interface)
    • SmtpMailer (class)

Obviously sitting in the Company.Product.Mailer assembly. There naming your namespaces gets interesting is when you start really plugging into the user facing frameworks. For example, in my earlier post I mentioned that I might name a PowerShell automation library Company.Product.Management.Automation.

I think what I was getting at with that is that it sometimes makes sense to mimic the structure of the .NET framework with some assembly names because it allows people familiar with that technology instantly recognise what might be contained within.

The Tyranny of .NET Namespaces

This is not a rant about the .NET framework, in fact for the most part I think the .NE framework is a very well structured set of libraries for building a variety of different solutions. This is a rant about how namespaces have been inappropriately applied to other project types (projects that don’t contain .NET code) within Visual Studio.

Backstory

I’ve always been a little bit obsessive compulsive about naming conventions myself. In fact over the years I’ve adopted, junked and re-adopted a number of different conventions for naming the projects within a Visual Studio solution. I’m not 100% sure why, but I think that it may be down to the number of times I’ve played the build master role on a team and had to get other peoples code building and understand what they are actually expecting as outputs.

A Scenario

Given the following problem, how would you lay out your solution structure? A web-based application, a common library that it uses containing injected dependencies, a silverlight component, embedded within the web-site, a set of PowerShell automation libraries for system administrators managing the site, a setup package to deploy the site onto a customer server, and a desktop client, probably using Windows Presentation Foundation.

If I asked ten different people to describe their solution in terms of project names I’d probably get ten different answers, a lot would be similar, but none would be exactly the same.

My Approach (before today)

As I said earlier, in the past I’ve adopted, junked and re-adopted various conventions. The one that I’ve been using for the last year or so is as follows:

  • Product (solution)
    • Company.Product (common library)
    • Company.Product.Management.Automation (PowerShell snap-in)
    • ProductWeb (ASP.NET web-project)
    • ProductClient (WPF application)
    • ProductWebMedia (example of a Silverlight component)
    • ProductClientSetup (WiX setup project)
    • ProductWebSetup (WiX setup project)

That is pretty much it, a very minimal structure. But why did I switch from a namespace type notation for projects and then to a non namespace type notation (e.g. ProductWeb vs. Company.Product).

I’ve never had a really good answer but my general response was that the non-namespaced projects really represented discrete entry points for a user experience for the software (as if that was a good enough justification).

My Approach (post today)

I’m on the cusp of changing my approach, but not massively, it is a subtle refinement. This is probably how I’d do that same project today.

  • Product (solution)
    • Company.Product (common library)
    • Company.Product.Management.Automation (PowerShell snap-in)
    • Company.Product.Web (ASP.NET web-project)
    • Company.Product.DesktopClient (WPF application)
    • Company.Product.MediaComponent (example of a Silverlight component)
    • ProductClientSetup (WiX setup project)
    • ProductWebSetup(WiX setup project)

All I’ve done is made sure anytime my project contains predominantly .NET code then I’m going to use a namespaced approach. This falls into line with what a lot of people do already (yay) but I’ve stopped short of renaming the setup packages. And this is where I get onto the topic of the post – The Tyranny of .NET Namespaces.

What should you namespace?

Well in .NET terms naming the project inside Visual Studio doesn’t necessarily mean that the output of that project aligns with the project name, it just does by convention – that’s all!

You should consider using a namespace-style project name when your project really does produce an assembly as output. For example an ASP.NET project does ultimately produce an assembly (and a bunch of loose files). A WiX setup does not produce a .NET assembly – it produces an MSI and in general there is no convention around naming setup projects (with perhaps the exception of appending the word Setup to the end of the name).

So my convention is that if the project really contains .NET code then use the namespacing convention for projects – if not, use whatever convention makes sense for that particular project time.

My 2c Smile

Enterprise & Systems Architecture with Agile Development

I was catching up on some e-mail this evening and noticed a thread started by Steve Godbold about any possible trade-offs between agile software development methods and enterprise and systems architecting/modelling. It is an interesting question and probably deserves a bit of discussion.

What is agile software development?

Most developers would these days say they practise some kind of agile software development. There are quite a few different methods out there but the common thread amongst them is the incremental delivery of value within an iterative development model (although some methods have iterations so small that it could be considered a steady flow of value).

In a lot of ways, the definition of agile software development is fairly well understood whereas the implementation details are often argued about.

What is enterprise architecture?

Enterprise architecture could be defined as the relationship between the various supporting information systems within an organisation and an understanding of how they integrate with business processes and the overall business strategy for an organisation. Anyone who talks about a specific system without an overall picture of how that system fits within the organisation is practising systems architecture at best, but certainly not enterprise architecture.

What is systems/application architecture?

Systems, or application architecture is a more local focus for architectural efforts. It defines the ideal design of a piece of software given the functional and non functional requirements. For example an application that required immediate consistency on all transactions might need to avoid a number of the NoSQL persistence options out there – its all about the application specific trade-offs that you need to make.

It’s all about value!

Agile methods, enterprise architecture, systems/application architecture all exist to deliver value to the business. Agile methods deliver value by reducing the risk of project failure by delivering value in small incremental pieces.

Systems/application architecture define the overall picture of how the application will come together and is good at “taming” the emergent design that you often get in agile development projects. I wouldn’t go into a project without a reasonable idea of how the pieces of the system are going to integrate together and identify which technical aspects of the system are risky and need to be spiked out.

Enterprise architecture is really playing at a different layer of an organisation. A good enterprise architect is going to be deeply integrated with the business units and know what their current challenges are and have a plan for how those issues are going to get resolved over time. It pushes some design constraints onto agile projects by defining what kind of interactions that new system needs to support – the value it provides is that longer term vision.

Muddy waters of enterprise and systems architecture.

In my experience a lot of organisations confuse enterprise and systems architecture and tend to collapse it into a single role. If you are in this kind of role you need to work hard to not turn each system into a microcosm of the overall enterprise architecture and in the process completely overcomplicate the problem at hand. This threatens the ability of both disciplines to deliver value and can completely derail an agile team.

Enterprise architects are chickens, systems architects are pigs!

Is everyone sick of the chickens and pigs analogy yet? Systems architects really need to be involved to the bitter end of a software development project. Along the way the architecture will be challenged and it may need to evolve rapidly on the spot. Enterprise architects don’t necessarily need to do this because their influence is really exerted on the functional requirements of the system being developed.

Final Thoughts

I’ve seen heavy handed architectural approaches fail with agile development teams where they couldn’t effectively manage their technical debt because of an inappropriate architecture (just because you call it an architecture doesn’t mean it is correct, and the best way to test an architecture is to start to test it by building against it). Conversely I’ve seen agile development teams produce steaming piles of crap simply because they didn’t have a high level overview of how the system would come together.

The best agile development teams treat systems architecture as an evolving item where you know roughly which direction you are heading but keep your implementation open for change and it is this that delivers value to the organisation and allows enterprise architects to evolve the overall systems of the enterprise more easily.

E-mail in an attention deficient world.

More and more I find myself quickly reading e-mails and trying to figure out the one place where I can add value to the conversation. Rather than replying to the whole e-mail I just reply with the critical bit of knowledge I can provide and let the other conversation topics just lay on the floor.

The problem is that in order to do that I need to frame that response to make it clear that I am just responding to a specific part of that original e-mail. One of the things that I am a proponent of is “one thought per e-mail” where you spin off a thread of conversation for each discrete topic rather than layering on additional concepts.

I believe that this helps readers of e-mails because:

  1. They can check-out of the thread early as soon as it drops below a certain level of relevance.
  2. You can be more targeted with the thread in the first place.
  3. Helps keep the thread on topic, if the thread is very focused it isn’t going to ramble on into something that is less relevant.

Windows Azure & BPOS: New challenges, and opportunities for systems integrators.

Last week I attended some of the Australian Partner Conference where we were lucky enough to win the Microsoft Partner Network MAPA award for Software Application Partner of the Year for the work that we did on the Grays Online web-site. There was quite a bit of buzz on Twitter about it.

The two big themes at both TechEd 2010 and APC 2010 were both Cloud and Mobile. Microsoft has been in this space for a while now with Windows Azure (from a developer perspective) getting close to being a few years old, and the re-developed Windows Phone platform is certainly going to make waves.

Readify as usual tends to get involved pretty early with these technologies and we’ve worked behind the scenes on what is probably the largest single SQL Azure deal in the world and we are starting to approach customers about building Windows Phone 7 applications, particularly in the financial services market.

We’ve also got our first internal line of business application running on Windows Azure (Compute & Storage Services) which authenticates via WIF/ADFS to an Active Directory instance that we have running in a Texas data centre, pulling data from our CRM instance in another data centre in Melbourne, and the application itself is hosted in the Singapore availability region for Windows Azure. We’ve also moved our e-mail hosting to Microsoft Online (BPOS) so I think it is safe to say we’ve embraced the cloud.

But it was at the APC that I made an interesting observation that systems integrators are going to have to start talking to software solution development organisations like Readify to strike up partnering arrangements. The traditional profit domain of the systems integrator (hardware, licensing and associated services) are not going away, but it will be getting squeezed and they are going to need partners to provide value add services.

By the same token software solution partners are going to be enabled to provide more complete solutions because they can purchase off the shelf hosting services such as BPOS & Windows Azure to get the job done without the need for a major IT staff, or even needing to consider things such as storage and compute redundancy.

Its a brave new world that we are entering and I’m excited about the possibilities.