Occasionally, I get asked by others internally at Microsoft, what role software factories are going play in their space, ‘their space’ as it were are server products we ship, such as: SharePoint, Exchange, BizTalk etc.
Perhaps I’ll start with a problem first and hopefully this will tease out an answer.
One of the issues our industry still faces is the acceleration of technology, and the effects that has on people who have to use it and build useful stuff from it. This is especially challenging for those of us who consult on this new technology.
I outline some of these chronic issues and their relationship to each other in the Vicious Software Development Cycle, which has been derived from what we see sitting here in the field between the products and the customers.
The key issue in this context, is that it takes considerable time to develop best practices for a new technology. And most people won’t feel comfortable in the real world using a new technology unless it has proven practices.
Developing best practices involve numerous poor experiences, expensive mistakes, wastage of resources, and the development of supporting guidance to make using the new technology efficient. The only people who become masters of new technologies are those that experience this and create the best practices. So this implies you have to master it before you can use it?!? Well, certainly this is a common approach today for most organisations.
So what’s the answer? Well, none that will solve any of that, BUT what if the new technology shipped with its own best practices? So that only a few had to learn the hard and expensive way, and the many can benefit from those learnings more rapidly?
An ideal vehicle to ship ‘best practices’ is a software factory. So what would these factories look like?
I predict that in the near future, due to customer demand, each server product from Microsoft will ship with one or more software factories tailored to the people who need to configure, deploy, develop against and maintain these products. Maybe some factories are tailored towards the users of the product too depending on the product scope.
These factories will employ domain specific languages to model infrastructures, usage scenarios, logical architectures, deployments, components etc and encapsulate best practices and learnings developed during product development, field testing phases and learnings from early adopter programs.They will offer higher level of abstraction from the technology itself to address the business problems the people using them understand – devoid of the technology constraints they use to solve them.
The factories will then enable new customers to pick up the new technology right away, and start configuring, using and deploying it without having to learn, and correct, all the poor experiences themselves. They won’t have to read and understand all the technical articles and best practice guides, consume the books, read the newsgroups etc. because the factories will encapsulate that knowledge and best practices within its models.
These factories will be regularly updated, and maintained as first class products, to accommodate the bug fixes, patches and workarounds, these people have to consider every time they make a deployment or configuration of the product.
So this sounds all good, but lets illustrate with an example to make it more concrete.
Lets take a product like SharePoint. I chose this product because its both a server product and a developer product, so many different people (IT Pros, and Developers) use it to solve real business problems (Search, Collaboration, Publishing, Content (web parts) etc), and it solves very directly many business related problems for the users.
You can imagine that in order to ‘use’ this product – deploy it – requires quite a bit of planning, that you as IT Pros should do before installing it in a production environment. That would include things like: Capacity Planning, Architectural Design, Security Design etc. You can see the size of the suggested planning here. So typically, as an IT Pro I need to consume all this guidance and possible hire a few experts who have done this before, and create an action plan to work out how to get started. Before I can start using this product!!!!
So how would a factory help here?
Firstly, you would not create one factory to do all these things. You may have several factories focused upon different domains.
[An assumption you might have at this point, is that a factory only creates source artefacts like source code, assemblies etc. Well, that’s just not a valid assumption for factories. A factory can automate any given task. That would include things like creating configuration, configuring a server, generating accounts, etc. A factory doesn’t actually have to create anything, it might just configure something.]
In this case, one factory could be built to automate the configuration of a server product. SharePoint specifically supports configuration by web services. So this would seem like an ideal way to interface to it. (SharePoint actually supports several different configuration and content interfaces).
Our factory, might require you to install SharePoint on a box first, before configuring it, or it may in fact automate the installation of the product too. Assuming the former, the factory would then provide you a logical model of a SharePoint installation that may include logical deployment nodes, each with their own configuration. The factory might provide a visual DSL model of that deployment environment, upon which you configure different aspects, like security, and capacity etc. Once the models were configured, the factory might then automate the deployment or configuration of the installation (as a whole) or individual nodes within in.
The models used and abstractions made, and how the configuration is done are where the best practices are encapsulated in the factory. The practices are then directly enacted by the factory for the user. The factory provides abstractions that are defined in terms of the business problem domain, and maps those to the technology underpinning it.
So as you can see, a software factory becomes a valuable first class asset to be shipped along with a product to enable our customers to get started using it right away. It also promotes best practices in the abstractions it provides focusing the users on the important business related aspects that the technology delivers.
I would expect that a product without software factories shipped with it, will remain to delay projects and raise the costs of deployment of them, not to mention the reduced adoption of them due to missing best practices and availability of those practices.