Pattern Automation – Some Examples

In the previous post I introduced this notion called Pattern Automation and outlined some of the things we expect it to deliver.  In this post I wanted to give you some concrete examples of what Pattern Automation looks like in practice, and hopefully stimulate your imagination to think of your own examples. You’ll see that with these examples that the results of Pattern Automation is a familiar idea, it is just that realizing it yourself has been just out of reach for some time.

Probably a really good starter example of pattern automation would be the patterns that are automated in the one of the patterns & practices software factories, such as the Web Service Software Factory. This custom toolset in Visual Studio gives you all the patterns, tools and guidance for building your own web services, any web service in fact, and even using a variety of web service technologies like WCF, ASMX. You simply define key artifacts such as a service contract and data contracts, and security policies, and the factory writes most of the code for you. It includes simplified abstractions (models) of key web service concepts (and architectures), that identify variability of choice in the service implementation, and then forward engineers transformations from those abstractions into working code. Factories like this also include vital guidance in various forms (custom tooling, models, templates, documentation, recipes etc.), that guide and focus the developer on configuring what is unique about the solution the developer wants to build. The great thing about these kinds of factories is that you can demonstrate them easily building any arbitrary web service.

Another, more common, technology focused example of pattern automation could be the ASP .NET MVC tools shipped with Visual Studio 2010. In this case, integrated custom tooling in Solution Explorer guides the developer in creating architecturally sound MVC implementations for a common design pattern in a specific technology (ASP.NET).

There are many examples out there, these are just two common ones for illustration, many are familiar to you, some not. All of these toolkits help you the developer be more productive creating a certain kind of solution (a WCF.ASMX web service, a ASP.NET MVC web application, etc.).

Both example toolsets, and others like them, provide custom generic tooling integrated with Visual Studio geared to producing (forward engineering using automation and code generation) working software that can be used to build an instance of a specific application or solution. But ironically, this strength is also their ultimate weakness.

One important point fact that is often overlooked is that in the case of both these examples is that a) they come from a renowned technology platform vendor (Microsoft) and b) they produce custom solutions implemented in a very prescribed and constrained format that this vendor pre-determined for you on their platform solely. If your organization wholly subscribes first to this platform and second to these specific patterns of implementation down to every line of code (i.e. the code they produce is wholly acceptable to your organization - as is) AND you don’t have any other technical constraints or requirements that they didn’t consider in their design; then these toolsets become invaluable productivity enhancing assets for you.

But what if your organization is not a platform or technology vendor. What if your solution implementations tend to have differing (non-ideal ) technical requirements and constraints the solutions you build? Then these kinds of toolsets at some point will need to be tweaked or tuned, or extended or constrained to ‘learn’ how to suit your organizational needs.

The truth however is that in general it is rare that these toolsets can do this for you. It also turns out that for most toolsets for example, the ASP.NET MVC toolset, that you are unlikely to need to tweak or modify the MVC pattern itself – it has intrinsic value. But more likely, you would want it to build MVC applications the way your organizations prescribes (i.e. writing the code your way, using your styles, templates, including your cross cutting concerns, to use your frameworks and libraries and  integrating with your architectures etc.). For toolsets like the Web Service Factory for example, it turns out that you will likely want to build specific kinds of business web services, not just any generic web service, using an arbitrary data contract, but ones that are constrained or standardized to the kind your organization or business domain requires. Perhaps your organization has specific technology requirements, or specific custom implementation patterns, specific standards of compliance, and you don’t want your developers re-making those kinds of decisions every time they need to build a web service. You just want things like that ‘built-in’ for every web service they create.

And it not just about providing templates created by your organization to apply to one of these toolsets. What you really want is the toolset to learn how your organization builds these kinds and solutions, and do it right for your organization every time freeing up developers in your organization worrying about that themselves. You want to rest in peace that if the solution was built with this toolset that understood your organizational needs, then that solution was created right for your organization.

The vendor of the Web Service Software Factory can’t possibly foresee and design in, all the possible constraints, requirements and coding practices every organizations on the planet may have. The vendor has to analyze and settle on what they think is best for the majority of organizations they know about who may want to build this kind of solution. You could call this best practice in itself because they are to a large extent harvesting the most common cases and finding robust resolutions for them. But there will always be areas that individual organizations will want done differently for a whole universe of different and uncompromising reasons – and they will find a way to do that way rather than conform to the standard.

Pattern Automation is all about letting you (the individual organization) make decisions about what it is precisely you want to build and more importantly how you want it built. Giving you the tools to build your own custom toolsets the way you want them to work for the patterns that you have found work for you. By exposing the variance you need for building your kinds of solutions, and fixing/constraining the parts that are given/standard in your project or organization, by your standards. Toolkits from  vendors like Microsoft are just ‘one way’ to build solutions - some might say just a ‘suggestion’, or even a ‘suggested direction’, a starting point or a ‘recommended practice’. Despite what those suggestions are, and how credible they may seem, a development organization like yours is going to find out the hard way what works for building solution for them in their business, with their capabilities, skills and experience, and with their constraints and choices. And unless custom toolsets can be built to build solutions your organizations way, vendor-built toolsets will always have limited productivity and consistency value.

Pattern Automation and the tools that enable Pattern Automation like VSPAT, aim to resolve that very problem; by letting individual organizations define and capture their own proven patterns of implementation harvested from tried-and-true solutions that have worked for them. On their platforms, with their technology choices/constraints, built by their own people. It is likely that those solutions will have had a fair amount of best practice injected into their foundation, but in all but a few cases have had to at some point break the mold of the vendor’s standardized and recommended implementation to deal with differences in organizational technical/business: ability, capability and efficiencies.

By way of an example above. Pattern Automation is truly all about the ability to build your own Web Service Software Factory/Toolkit specific to your organization or your business customers, so that the solutions that are created from it meet your own standards and best practices and are tailored and constrained to your needs. Being able to select the best breed of recommended practices from different vendors and partners, and supplement those with institutionalized knowledge and business domain experience, to deliver custom tooling that is tailored to the organization needs.

It’s a marked evolution from relying on generic (platform/vendor provided) tooling ,to building your own domain specific tooling. And utilizing all the efficiencies, consistencies and productivity benefits that go along with that.