Jezz Santos : Factory Building Basics

Building Software Factories - Factories 201

jezzsa — Tue, 06 Mar 2007 13:37:00 GMT

Factories 201 Series - Building Software Factories

Post authors: Edward Bakker and Jezz Santos.

Well, we have finally come to the end of this 201 series on ‘Building Software Factories’.

First time arriving here? - we have listed the entire series above – please have a look through those posts before ending it below.

If you are arriving here after reading (hopefully all) the posts in the series, we wanted to say, good on you, and thanks for sticking it out with us.

Series Wrap-Up

Well, we have spent quite a bit of time and thought in putting this series together for you. The motivation behind this effort has been that we’ve recognised that there is little practical information helping ordinary professional developers on getting started with building and understanding software factories. We have had quite a head start on this and wanted to share our knowledge and experiences with you and the community to promote the uptake of building factories, which in turn should promote the adoption of software factories and the industrialisation of software in general.

This series was created in a format that asks a logical sequence of questions that you might have when trying to figure out how to build software factories today. We have covered many such issues as they arose and shared much of the combined knowledge and experiences built up over the last few years in this space. We will be sharing more resources on this in future posts – so stay tuned to our blogs.

We hope that you can take the guidance represented in this series forward as a starting point for developing your own software factories further. We recognise openly and frankly in the series that this is not a trivial undertaking today, but hopefully we have shown you that it is very possible and how to successfully approach it. Hopefully we have also directed you to what’s most important, where you should direct your energies, and how to build factories practically and realistically.

Your Feedback

One of the primary objectives of this series was to connect with many more of you in the community and share ideas and innovations about everyone’s efforts at building factories today.

We have received a small number of comments to this series so far, which we have been keen to discuss at length, and hope we have done a good job at answering the questions appropriately. Hopefully, there are many more of you out there building factories, or at least considering building them, and so we hope to hear more from all of you on that. Please drop us a comment on the appropriate post and we will work hard to get you an answer you will find useful.

If we are doing a good job please let us know. If we are doing a poor job and you don’t like the guidance we are giving please let us know that also. This should shape any future guidance we give the community in this space, and at least we can start further discussions with those of you in this space. Hopefully, we will also get a feel for just how many of you are out there are in this space.

The Final Say

There should now be a little more information out there to help you build a software factory right now on the Microsoft platform with the current toolsets. This series was created exactly for that purpose to share with you the experiences we have had in building factories and give you insights into the issues we have faced on this road already.

As more and more people jump into this space we expect to see from the community more detailed, formal guidance on this subject, so that the community as a whole can learn from previous experiences and elevate the adoption and the application of software factories to real world projects.

After all we think that the act of building a software factory should leverage the tenants that software factories promote themselves, i.e.

“Package domain expertise and guidance in a form that others can re-use and manipulate to create solutions using simplified descriptions of the problem at hand.”

Hopefully we have done a good job of that for you, and hopefully you will consider the experiences we have shared in this series in your factory building efforts.

Come see us...

We are proud to announce that we will be presenting a session on ‘Building Your Own Software Factory’ (ARC303) at Tech-Ed 2007 in June this year.

The 300 level session will contain material from this series and demos and examples of other factories to explain the concepts. We would love to meet up with you there and answer your factory building questions.

Many Thanks, Jezz Santos and Edward Bakker

Factories 201 – What are the challenges?

jezzsa — Wed, 28 Feb 2007 12:14:03 GMT

Previous posts in the Factory 201 series:

Now that we have looked at what a factory is, when it is applicable to build one, 'what', 'why' and 'how' you do that, it's time to step back and look at what the major challenges to building software factories are and why we haven't seen a proliferation of software factories available yet today.

There are certainly challenges building factories today, even though these are not insurmountable and very doable - so, "What are these challenges?"

We are going to break this post into 3 sections, the first discussing the practical challenges to building factories today, the second discussing the organisational challenges present today controlling adoption of building factories, and finish with market place forces in place today.

Practical Challenges

Let's start off with looking at the practical issues with building software factories today.

If you missed it, we already looked at what you need to build a factory in "When would you build one?", then the actual iterative process for building factories in "How would you build it?", so we are not going to talk about that here either, nor are we looking at the technologies you use that you use to do that, we already discussed those in "With what would you build it?".

Here, we are more focused on the broader practical challenges of developing the automated parts of software factories and what issues we face today in doing that both in the platforms and tools available, and the other drivers and affecting wide-spread adoption of factories in the market place.

Toolsets & Platform

The primary challenges we face today with building automation assets and factories are that the tools, we have today, are still at the level that requires us to fully master these toolsets (and all their technical details and intricacies) to wield any of their capability. That's no easy feat for the toolsets we outlined in "With what would you build it?" (such as: GAT, the DSL toolkit).

That may have sounded strange to you, "of course you need to know how to use a tool, to use it – well duh!"

Well the fact is, with the toolsets we are talking about here, and in the context of using them in building software factories, you shouldn't have to know all those fine details about them to leverage their capability in defining a factory. You should be able to design the things for your factory from a higher level logical description, and have someone/something else figure out how to map that and drive a specific technology or toolkit to create the implementation. Sure, if I want to squeeze out every little feature and customization of these tools, then I need to know them in more depth, but not if I just want to use them for basic factory design purposes - as would be the general case.

We want to be able to use the principals of higher level abstraction and guided automation in the very process of building our factory too! (Wouldn't you?)

Well the reality today, is that it's not yet the case, and to wield and orchestrate these toolsets to bring a factory together requires the factory builder to jump over a very high bar to leverage the capabilities provided by these individual tools.

The second challenge is that these tools were not originally designed to work with each other, and are not currently aware of each other, since they were designed and built independently for different goals, before we had a concrete vision of software factories. Which means that even though you can build factories of today happily with them, they are not ideally integrated together yet for software factory design today. This particular issue is evidenced by the fact that some groups have had to create stop-gap solutions and supplementary toolkits to help bridge the gaps between the toolsets to specifically address software factory building scenarios. The experiences are improving though.

Finally, the current toolset is pretty minimal at present, simply because we have not yet had much experience in exploring this space of building software factories and fleshing out each aspect of that. It's pretty green fields out there right now, and we expect there to be many future tooling innovations in the sorts of factories that will emerge over time.

To evolve the capabilities of software factories in the future, we need to identify what these missing tools are, most likely by discovery. 'The Next Missing Technology' explores this requirement a little further.

Factory Authoring Platform

Clearly, if we are having trouble actually practically creating software factories, because it's hard to do, then not many folks are going to, or able to, built them. Only those with the right organisational structure, long term strategy, high domain skill sets, time and money will be able to afford to build them right now. In order for factories to be successful in helping industrialise software development however, building them must be accessible to a wider developer community, so they can be used as parts of ordinary development projects.

[That is not to say that building a factory is a necessary part of any development project!]

This last point is, of course, exactly one of the challenges factories themselves are trying to solve. (i.e. packaging domain expertise of one domain into automation and guidance assets that can be re-used by domain experts of another domain!)

Everyone trying to build factories today will have a different way of doing it, (different skills sets, different approaches, different interpretation of a factory, etc.) and the factories they create will come in many different shapes and forms as a result. This is great for developing new innovations to solving the problems that factories address, but in practice, as we all know, much of the work done by all those building factories today would share similar infrastructure and authoring assets. And that part is being re-done, and re-experienced by everyone over, and over again. (Sound Familiar?)

But that's not really the area we, as factory builders, should be wasting our time on when building individual factories – this should just be out-of-some-box for us to leverage as we see fit. This is another major challenge factories are trying to solve themselves. (i.e. packaging of domain specific automation assets and tools to create a specific solution).

Therefore, it's easy to see that those building factories themselves need to swallow their own medicine – as it were, and adopt the practices that they preach in the very act of design and building of them.

We can see clearly that to increase the proliferation of factories among the software development community there is a dire need for a consistent set of authoring tools to create factories in a consistent way, on a consistent infrastructure. So that those building them can focus on higher level tasks such as logical design, domain modelling, automation asset definition, factory orchestration and solution implementation of their chosen domain.

In short, what we need here is an authoring tool, very much like a factory, to help us build our own software factory – yes, you guessed it - a 'Factory-Factory' as it is informally known. Now, although this is an amusing term, this is precisely what is needed to solve the issues we face today with re-use of factory building tools. A tool, built by experts of building factories, that gives us (factory builders) authoring tools for building our own factories. These authoring tools should be a level above the tools we have today, using abstractions and automation, so that factory builders, like you, can simply 'visualise' a solution domain and attach certain automation assets to various parts of its' logical design, and define artefacts or configuration for creating the physical solution to that design. You, the factory builders, should be then able to package up your custom factory and deploy it to a factory user who can then install it, open it up and start creating a product using the automation assets defined by your factory.

Once we have this platform of runtime and design tools in place, as factory builders, we should be able to focus on the higher level design tasks of our domain, and simply configure the factory design tools to provide the right user experience and assets to provide a solution to our domain.

Authoring Approaches

The final point here is about the approach we take to building factories today. In "How would you build it?" we explored a common-sense, practical and logical process for building a factory from the starting point of product-based assets for a known domain we already know very well. Which requires from us that we know both the problem domain we are solving and the solution domain of the thing we are using to solve the problem. This is a very appropriate process for the types of factories we have now, and what can be achieved with the tools we have today. But you may have noticed that we don't even touch on some of the concepts prescribed by the practical vision of software factories, such as: ViewPoints , Activities and StakeHolders. Realistically, today we can only really achieve logical architectural design, with: Views, Work Products, Artefacts, and Assets.

Why is that? Simply, because to properly implement the other things like ViewPoints, Activities and Roles, as they were intended, concretely in factories of today requires the support of complex runtime tools and infrastructure that is simply out-of-reach for most ordinary factory builders today.

Once that infrastructure is available to us and we can leverage these new capabilities of the factory vision, and we can start to leverage their power over what we have now so we move towards the full intended picture of a software factory with many more benefits.

So how would these additional authoring tools change things from what we have now?

The Current Approach

Well consider that today; you first need to define your solution domain from what you know about in the solutions you already know that address the problem domain. You have to possess some solution assets as the starting point to build upon (an RI or frameworks perhaps). Then, building a factory is simply the process of automating these solution assets and adding abstractions and logical architecture around them to help to factory user configure and manipulate them. Perhaps you also add some runtime components to help maintain the state of the product the factory is building, and finally somehow orchestrate those automation assets together under one roof – your factory.

If you don't have the starting solution assets, then you can't begin to automate those assets because you have nothing to describe in your factory! Sure you can envision a logical architecture of the product you want to build, but you have no way of formalising that or persisting that in your factory as a starting point to build upon. That is exactly why you need starting solution assets - to scope and define what you are doing.

A New Approach

However, what if I gave you a tool that allowed you to define and progressively refine the logical architecture of your product. Then, define its' various concerns (ViewPoints), then let you slowly define the various components of it you need to build (Work Products), what you use to build them (Automation Assets). Then, you can define the steps to build each one, what the outcomes are, and which steps rely on outcome from other steps (Activities). Then, finally how those Work Products are transformed into physical solution pieces (Solution Artefacts). Finally, what about I let you declare which concerns and activities are applicable to which roles in your project team (StakeHolders), and define which Views these particular people want to see when using the factory?

Now this is sounding very much like the factory building design experience we want to envision in the future. Indeed, this tool I described here is what a software factory of the future will look like to a factory builder, and these higher level capabilities, like: ViewPoints, Activities and Roles etc, can only realistically be achieved with an infrastructure and design tools to support them.

Unification

The point is that this tool would open some opportunities for design that are not really available to most today, and further this tool would prescribe a formal definition and process of what a factory is and how to build one. Something we don't really have today.

Today's factory development process describes the very act of rendering a factory from solution-based assets, because that makes sense in this context given the pre-requisites and objectives you would have for building a factory today – it's just guidance, not formal, rigid process. The definition of a factory today is also pretty open and broad, and really a bit broader than just the automation piece, it also includes other forms of guidance including written guidance, patterns, philosophy and samples.

As tools and platforms emerge and evolve the very process to create your factory and the definition of what a factory is will slowly change, and eventually solidify and mature for the high percentage the factory building cases. Further we will have a concrete definition of what are the pieces and how they make up a factory by then.

Until the time we have the authoring parts, the question about how to build, what to build and what is a factory *exactly* will remain debatable and subjective.

Organisational Challenges

The other major area of challenges for factories today, is simply a result of the fact that they are an emerging technology today.

Assuming we step forward a few years, and assuming that we already possess the appropriate authoring tools for creating future factories. The next challenge will be getting adoption of those authoring tools in broader use in software development programs.

[Of course, that's not to say they should be used for general software development. What we mean here, is to get them out and available to a wider developer audience, so that they are used where there is a good case for a software factory.]

A Spread of Adoption

We firmly believe that it will be the skilled professional developers who govern the adoption of the tools initially, but we do hope that it is end-customers and market forces that will drive the long and medium term demand for these tools. Why? Let's look at that quickly:

From a customer's/market's perspective, a solution provider that can create high-quality solutions to their specific problems at a fraction of the cost that they can today - is likely always to win the deal.
- Of course this assumes that the company creating the solutions significantly reduces the sale price of the solution, because it should cost them considerably less to make the solution now!
From a solution provider's perspective, a tool that can expedite the creation of customer solutions whilst leveraging their in-house investment in resources and skills - offers a chance to increase profit and margins, and offers competitive advantages over competitors who don't have this capability.

As you can probably easily figure out, there is a dependency building here. As more customers benefit from more cost effective solutions, the market will start to demand that software development costs decrease, since they have witnessed the possibility of that already – that is the promise. This will put pressure on solution providers to make solutions cheaper than they are today. As we have seen, that's just very difficult to impossible today – something has to give, and solution development has to get cheaper. Factories offer a way out here, as you can see in more detail in the Vicious Software Development Cycle where the drivers and dependencies being built are described.

Now, to the practicalities of all that.

Mindset Changes

The major challenge solution providers' will face is a core change in the way (mind-set) they develop software and a move from one-off development approach to product line development approach, for all but the custom 'boutique' software solutions. This affects more than just how they do it. It changes the whole value network inside the organisation, their processes, their skills and their target markets.

Today, too few solution provider businesses are geared to this one-off development. Building re-use into their solutions is often a random afterthought, and even then, rarely receives appropriate investment and correct resources to execute properly. We are not just talking about physical asset reuse, but also domain expertise re-use. Since traditionally, the only place to store domain expertise was in the artefacts and documentation of one-off solutions (and individuals heads) - which then walks out the door with the solutions or individuals.

The game to play here is one of re-using value, and maximise the investment in solution domain expert resources by capturing their knowledge and experience in physical assets, and make those assets re-usable and automatable from a higher semantic level by those who don't possess those solution domain skills.

In short, the re-usable assets become a measure of the value of the organisation.

OK, so that being said, why wouldn't you want to do this?

Well good question!

Ground Up Adoption

We know that professional developers themselves have a very large part to play in the adoption of the tools they use to create solutions, regardless of what the business demands. Fair enough of course, they are the one who have to use those tools!

We explored the issue of software factory adoption from the perspective of several professional developer profiles in "Why do I need Software Factories?" What we found there is that there is a perception that software factories are somewhat of a threat (for several reasons) to some who don't fully buy that software factories can deliver its promise, over what the individuals can. This is largely based upon their own fears that they have of these kinds of automation tools and the impact on their current roles. This kind of fear will initially stifle bottom-up adoption of factories in an organisation.

The basic problem here is in comparing a tool's capabilities to a human being's. In this case, fearing that a factory will replace the role, skills and knowledge of a professional developer. The real issue here is of course recognising that some general tasks a developer performs at a low-level can in fact be captured, automated and largely replaced with higher level tools that do the job quicker and better. Whilst lower level tasks that should not be automated, require a professional's input to suit the specific objective at hand. In short it is about providing the right kind of tool for the job at hand, and directing and applying a professional developer's enthusiasm and design skills to more productive tasks.

Once this is better understood by those who are going to build and use the tools, adoption should be widespread.

Market Demand

The final point here is that today the awareness and markets for software factories are new and still emerging, and with that, the vision and execution of that vision are developing, being guided by that market demand.

The market will certainly shape what factories deliver in the future, and what tools are used to create and operate them. More importantly, the market will certainly apply forces to move to software industrialisation as solutions are proven, by initiatives like software factories, to be more financially viable to construct to satisfy growing customer demands.

It is simply not possible to guess precisely what new markets will demand or exactly how they will develop. So this will need to be discovered and addressed appropriately in a timely manner. This is a challenge in itself.

The good news though is that the whole philosophy and approaches around building software factories is iterative and progressive and should therefore be able to address this kind of change comfortably.

Summary

In this post we have had a look at the practical challenges around building software factories today. The biggest challenge today being the tools we have to get the job done. We hinted at a future where the tools supplemented by a runtime infrastructure step-up a notch and offer us the sort of logical design experience equivalent to what our factories are providing our factory users, but to us as factory builders.

We then had a look at some of the 'molasses' we see today with adoption of factories, and the attitudes many organisations and individuals have to this practice of domain knowledge re-use and automation – but this is transient.

Of course factories are new to the software development market, and although our customers have been wanting software development to advance at more than a snail's pace, to get the software they want quicker, the markets for software factories and customers demanding they be used, is still emerging.

Factories 201- How would you build it?

jezzsa — Sun, 18 Feb 2007 11:00:00 GMT

Previous posts in the Factory 201 series:

Now that we know what we are going to do, what automation assets to create and which technologies to use to build them, the next question is really: what process do we use to do that, and how to actually build the factory? In other words, “How would you build it?”

We covered a little bit of this process already in “What would you build?” where we outlined the basic process for automating your solution as a factory product. But for clarity, let’s run through that again here. (Although I recommend you read that post first for a bit broader context).

Lastly we look at getting started, and creating the first version of our factory.

[To clear up some nomenclature, we use the term ‘solution’ and ‘product’ apparently interchangeably in this post. A ‘solution’ is really the existing solution that you have before you had a factory, and the meaning of it is what developers fully understand as the physical solution to a problem. When we say ‘product’ we are referring to the thing that comes out of the factory; it is also a solution to the original problem, but with a slightly different semantic meaning, since it might not always be a complete physical solution.]

The Approach

If you have consumed the majority of ‘The Book’ on software factories by Jack and Keith, you might come away thinking that to build a software factory requires a heavy amount of engineering and pre-design before getting starting. One misconception arising from this definitive text is that building a software factory requires a kind of ‘big-bang’ type of approach; which could not be further from the truth for building factories today. It’s just a common perception of course, the book has very much ground to cover in teaching the principals of this space, and it’s extremely informational and a invaluable definitive resource on the subject. However, because the book is mostly focused on the ‘why’ and ‘what’ of software factories, much of the ‘how-to’ of realising a concrete software factory is pretty abstract.

Now, assuming you meet the pre-requisites as outlined in “When would you build one?” you should be in a good position to start right away transforming your solution based assets into automation assets for constructing your factory.

[If and when we have software factory authoring tools sometime in the future, they may well offer other alternative starting points and processes for building factories that require more careful upfront planning and design. But until then, the reality of building software factories today is quite different, since we are approaching it from ‘bottom-up’ approach of transforming available solution assets into automation assets for a known domain, and discovering the factory we need for that as we go.]

Common Practices

Before we get into any discussion about a process of any sort - hold on a second!

For many people today, building automation assets is very informal, more like, trial-and-error at the moment while they skill-up and explore the current toolsets, modelling and automation spaces – this is a pretty new and exciting domain to many who stumble across it. There isn’t a whole lot of guidance yet on the 'how-to' formulate anything like a software factory out there right now - which is of course, what we recognised, and why we are doing this series of posts for you!

With the power the current toolsets bring, many just simply want to ‘templatize’ some of their current solutions, some want to code generate some stuff, and others just want to model something, and of course any combination thereof. Many may not even start with a full reference implementation of their solution; instead they only have a few of the pieces to get started, expecting to discover the other pieces and fill in the blanks later. These are great drivers for building a factory of course.

If you are currently involved in this kind of discovery phase and not entirely sure if a factory is for you, you will probably be a little averse to being prescribed a process for doing what you need to do, or what you are already doing. However, what we have found is, that if you look at the process below carefully and reflect on the things you do yourself, the decisions you make, and why - you will probably notice that these process steps are almost exactly how you think about converting your solution assets into higher level automation assets.

The fact is that this process wasn’t dreamed-up from some academic theorem, or idealised notion of how to build factories - it is simply a description of the natural stages that you as a factory builder go through in evolving and developing your automation assets from existing solution assets to expand the productivity of your factory.

So, whether you already started creating your automation assets individually for fun, or you are considering embarking on a factory team-development project, the process of turning solution assets into automation assets should be very similar to the way you are doing it now.

Incremental, Agile Process

The basic overall process for factory construction today is to incrementally develop your factory from initial solution-based assets in bite-sized chunks following an agile development process.

That does not mean you need to follow agile development practices such as extreme programming and test driven development etc. But it does mean, not having to ‘go dark’ for months and do a whole bunch of heavy design and upfront engineering hoping to implement a finished factory in one go some time in the distant future.

Why? I think the answer is pretty clear when you consider the complexity of building any reusable asset or automation tool, such as a factory, which has to create products to suit many different end-user scenarios.

Keep in mind that a factory creates a product line (multiple related product variants) each variant different to another because of the configuration of a point of variability in the product, and further, that product variant from the factory addresses a specific scenario. Without sticking to the constraints of meeting specific scenarios, factory development would continue infinitely, decomposing, identifying and refining points of variability until the product is so finely variable as to warrant the factory productively useless. You would have basically rendered the factory back to a low level abstraction similar to source code again. So really, how far you go is a fine balance between creating a variable enough product to just suit all the scenarios you want in your domain, and no more. There are several challenges with predicting how much work to do to get to a point where the factory is good enough to fulfill all the necessary scenarios, and it's unlikely this will be known when you start factory development.

Let’s look at some of the reasons why an agile development process lends itself ideally to software factory development:

If you can’t predict all the scenarios you want to cater for with your factory, you’ll not be able to predict all the product variants you need to create, and hence all the variability you will need to address and calculate the automation assets you will need to create for that. This will all need to be discovered incrementally, addressing the simpler scenarios first and tackling the tougher ones later.
As you tackle each scenario, and design each product variant to suit that scenario, you’ll want your factory to configure, deliver and verify this complete functioning product variant at every stage.

Once you have reached a point where the factory addresses all its specific scenarios, applying more effort into automation may be in vain. Unless, perhaps you just want to increase usability and productivity of the factory with further refinements to the automation.

Evolution & Change

The key point with factory development is to always be in a position to create a predictable, stable set of product variants - so you can deploy them!. These 'products' can then be analysed ‘offline’ to see where they deviate between what is needed for a future scenario and what the factory actually creates (i.e. in user acceptance testing). The results of that analysis will be fed back into the factory identifying, most likely, another point of variability, and a new version of the factory can be developed further to address that new scenario.

It’s interesting to note that whilst the factory is developing and evolving, the actual product itself will evolve very little in terms of scope. All that will really change are the different variants within that scope that you can create, (i.e. the specific configuration of the products variants). It is also possible that the underlying reusable product-based assets, like frameworks and class libraries, are further refined as the product is generalised and refactored to tease-out the variability.

So, let’s have a look at the software factory development process in some depth.

Process Steps

What we describe here is a progressive, iterative, generative process for developing your factory. It does have several entry points for starting an iteration, depending on what is planned to be achieved in the next iteration.

Keep in mind that this process assumes you fulfil the assets pre-requisites laid out in “When would you build one?” (i.e. existing solution-based assets preferably a full reference implementation).

Let’s just state the basic process steps here, and then follow that with detailed explanations:

æ Define/redefine scope of the solution domain (the product)
Collate relevant product-based assets
- i.e. RI’s, frameworks, libraries, templates, patterns, etc.
æ Identify the logical components ‘work products’
- Use relevant architectures and patterns to guide you
æ Identify variability (how the work products vary)
- CV analysis. Generalise and refactor product-based assets
æ Build automation assets
- i.e. recipes, wizards, DSL’s, templates, runtime etc.
Re-generate product variants, then verify, and deploy

ãã Re-iterate

[æ indicates an optional entry point for each iteration.]

An initial iteration occurs when getting started building the factory, this iteration skips some of the process steps, and instead runs from (a) to (e) and then (f). Once that iteration is completed, the next iterations maybe started at any one of the entry points (a), (c), (d) or (e) depending on outcomes of previous iteration, and the next iterations follow in the same manner.

Steps (a) and (b) – Define Domain, Collate Assets

In step (a) you scope the domain your factory is addressing (i.e. the bounds of the product you are building – solution domain). In step (b) you collate together all the relevant product-based assets you already possess to address your domain.

Initially, the order of step (a) and (b) may depend on your objectives and motivations for building a factory. For example, if you are building a factory from a requirement to automate existing assets, such as would be the case if you already had a code-based framework, you are likely to start at step (b) before defining your domain at step (a). If your objective is more based around creating a factory from business requirements etc., you are likely to start at step (a) and collate together any assets before starting at step (b).

After the initial iteration, you will always execute (a) before (b).

Step (c) – Identify Work Products

The next step, after you collate together your product-based assets, step (c), is to identify the logical components of the solution – abstractions. These logical components are referred to as ‘work products’ of the factory, and the work products represent the ‘abstraction’ and variability of the physical components of your product.

You would identify the work products by leveraging existing architectures and patterns known and adopted in your domain. These should help indicate what the moving parts are (naming, structure, concerns etc.) and perhaps indicate some of the variability of them. If no patterns or architectures exist for your domain then you may need to derive them. The key here is to leverage what is commonly known about this domain and communicate that to those who will ultimately use those abstractions – the factory users. This helps guide those using your factory in understanding how to assemble the product in an expected and predictable manner.

What you are looking for at this step are logical abstractions (simplifications) of the physical components of the solution. This is not necessarily a one-to-one mapping, as your work products can describe many physical components grouped together as one logical unit. What you are aiming for is a logical architecture of your product with course-grained defined work products related in a hierarchical structure that can be easily assembled by your factory users.

Step (d) – Identify Variability

Step (d) is all about identifying how the work products vary. Here you are focused on separating the common parts from the variable parts of the solution components and then representing the variable parts in meta-data description (work product configuration).

You can use a process called ‘Commonality/Variability Analysis’ to factor out the common parts and identify how the remaining parts vary. Typically, the outcome of this analysis is to refactor your product-based assets and move the common parts into reusable framework/class libraries, and then describe the varying parts in your work products using meta-data (configuration). In some cases the varying parts might require additional or differing architecture, in which case, you will decompose and identify further child work products of the work product.

After this step, you should now have a complete picture of the logical architecture of your product (at least virtually, in-mind), with child work products, each with meta-data descriptions. In effect you have described a ‘meta-model’ of your factory’s product. This meta-model contains the relevant abstractions of your product.

[Incidentally, this meta-model is a representation of the ‘software factory schema’ for your particular factory.]

Step (e) – Build Automation Assets

Step (e) is all about building automation assets that represent, and manipulate, the abstractions of your product meta-model, and building these assets to operate on those abstractions (i.e building: recipes, wizards, DSL’s, automated actions, and runtime infrastructure etc.)

You may chose to 'infer' your meta-model within these assets (i.e. in a recipe). Or you may concretely declare the meta-model and persist it within the assets (i.e. within a DSL domain model). You may also decide to implement a runtime that persists and maintains the state of the meta-model (i.e. in-memory store) and provide runtime access to it, so other automation assets can integrate with it. Either way, your automation assets provide a UI representation of the work products in the meta-model that the user will use to manipulate the work products of the factory.

One thing to consider at this stage is how to persist your meta-model. Common options include: persist a representation of it in physical artefacts (i.e. source code). Or alternatively, persist it directly to a logical domain model (i.e. a DSL file, or other runtime data store).

How you persist your meta-model is likely to govern how your automation assets will operate. For example, if your meta-model is persisted in source artefacts, you would create recipes and wizards that can only manipulate and generate physical components in source artefacts. If your meta-model is persisted in a runtime domain model, then your recipes can manipulate and create work products directly to that domain model. Of course at some time later, you might create other recipes to map the work products to physical artefacts (or other representations) at a later stage.

Step (f) – Generate, Verify and Deploy

Once your automation assets for this iteration are complete, you need to ‘exercise’ them and create the various product variants from your factory for verification. Typically, these new product variants vary from those generated from the previous iteration, since they should be taking advantage of new variance provided by the automation assets of this iteration.

Creating new product variants verifies the operation of the factory. But the product variants themselves need to be verified against the scenarios they were designed for. This process may well occur alongside the development of the factory in UAT testing for example. The result of that testing is to provide feedback back into planning the next iteration of the factory.

Any defects in the factory's ability to create product variants to address the existing scenarios are fed back as 'defects' to subsequent iterations of the factory.

The factory itself can also be tested; particularly its installation and runtime operation.

If no defects in the product variants are found, and the factory operates as expected, a new version of the factory can be packaged up and deployed.

[This deployable package would be some kind of installer, and would also include other guidance assets and supporting materials as well, such as reference implementations, documentation, samples etc.]

At this point, new scenarios may arise or be introduced either from UAT testing, new deployments, or through customisations for a particular scenario.

Re-Iterate

A next iteration is planned based upon the feedback from testing the previous iteration, and from any new scenarios introduced. The choice of which step to iterate next basically comes down to the level of change required from the new iteration.

For example:

If there is a defect in previous product variants due to inaccurate or incomplete automation, then we probably iterate back to step (e) and fix something.
If there is a scenario that requires a change in variability of the product variants, then we probably need to iterate back to step (d) and accommodate the new variance.
If a scenario requires a change in architecture to accommodate new variance, then we probably need to iterate back to step (c) and refactor the logical architecture.
If the product variants need to expand domain scope to address a new scenario, then we iterate back to step (a) and change the scope of the factory (hopefully this doesn’t happen that often!).

The beauty of this process is that when you get to the end of each iteration, you should be able to deliver new product variants that addresses new scenarios. That way, your iterations can remain short, and you never lose sight of your target scenarios or their solutions, and you can quickly adapt to change in them. You can also generate revenue with these new product variants to support your next development iterations.

First Steps?

So how would we initially get started building our factory with this process? What are the first steps? You noticed the process declared an initial iteration, what is all that about?

Imagine you already had a solution and a domain in mind. You already possess mostly a reference implementation (RI) of your solution, and it already uses some re-usable assets like frameworks and class libraries. What’s the first step in turning that into a factory?

Just before we do that, let’s build an understanding of what we already have and what we want.

A 'reference implementation' is by definition an instance of the type of product you want to build – it is a product variant, albeit the first one. It addresses only a single well-defined scenario, since its solution is fixed. What you are aiming to do is provide automation of the configuration for the variable parts of the solution, using your factory, so your factory can generate a new solution that applies to more than one scenario.

A Concrete Example

Let’s take a concrete example - an enterprise level 'Web Service'.

You already have a solution for your web service in code as an sample (it’s the RI!). It uses some kind of recommended architecture and some patterns to implement its structure. But certain things are ‘fixed’ in it for this RI, for example the WSDL is fixed probably. In this domain, a WSDL is also known to describe a ‘Service Contract’. Which implies that things like the operations (known in this domain as ‘Service Operations’) are fixed, and the messages they use (known in this domain as 'Message Contracts' and 'Data Contracts') are already defined and encoded into the solution. Your solution will probably also perform some pre-defined business processing for these operations.

Now taking this example, you may want to allow someone to create a similar web service (similar in structure, architecture, patterns etc), and allow them to tweak the Service Operations, and the Data Contracts (and most likely the business logic of it too!). For that you want to create a factory that allows the factory user to define specific Service Operations, Data Contracts and associated Business Logic etc, but you want them to keep the architecture, structure and patterns, and underlying frameworks and class libraries etc., since that stuff is ‘common’ to all these types of web services you want to build.

OK, so you just identified the following things:

Your ‘Problem Domain’ – enterprise strength, layered, services
Your ‘Solution Domain’ – a web service
Your ‘Product’ – a web service
Your initial ‘Work Products’ – ‘Service Contract’, ‘Service Operation’, ‘Data Contract’, ‘Business Logic Component’ etc.
The ‘Variability’ in some of the Work Products:
- Service Contract – Operations Contract, Data Contract etc.
- Service Operation - name, return type, request type.
- Data Contract – Data Members etc.

The only thing missing at this point is what automation assets you are going to build to allow the factory user to define the variability you just discovered. This will lead to what artefacts you need to create for your solution, and then how to build them reusing your re-able assets underneath (frameworks, class libraries etc).

At this point you are basically at step (e) in the above process. At the very minimum you’ll want to use your factory to create a product that looks just like your reference implementation, in other words, your reference implementation. This new product variant will of course have had have no variability in it, but after this minimal release of the factory, we can start focus more on the automation side of configuring that variability. For now let’s just look at getting our first iteration complete.

Initial Factory Release

The first iteration of your factory development should really just deliver your RI - as is. You’ll want to do this, because you’ll want to get familiar with the overall process that you’re going to re-iterate many times over, and it is in this iteration that you want to iron-out all the physical processes and get all project members familiar with the process stuff before things start ramping up.

To do this today, taking the example from above, and what we know from With what would you build it?, you can simply complete the following steps:

Use GAT to create a recipe to unfold your RI into a solution template. Include in this template your entire working RI as is (files, references, frameworks etc). You won’t need to add a wizard at this point because you are not gathering any data from the user, however, you will probably want to name at least the solution file with the name the user will be prompted for in the ‘File | New Project’ dialog box when they select your solution template.
Compile and register your GAT package. Create an installer for it. This is now the basis of your factory (albeit just a Guidance Package at this stage).
Install the ‘Factory’ on your test environment and verify it installs your first ‘Product Variant’. Your product should now build and run as expected.
Verify that your product is good, through User Acceptance testing etc.
Identify new scenarios that you want to address with a new product.
Start the process at Step (c).

So very quickly, within a day probably, you have the first version of your concrete factory (in a sense). With little or no effort a factory user can create your solution using your factory. You shipped your first product, and now you can start to develop your factory further using the above process.

Summary

In this post we have looked at a simple process of building your software factory, and we learned that we can get started very quickly and easily with that process by releasing a factory that almost immediately delivers our first product. From there it’s just a case of planning further iterations that add more and more automation and productivity to assembling the target solution. All the while, expanding the target scenarios you need to address for the domain of the factory.

We also learned a little about building re-usable assets and how to move to higher levels of design using abstractions to describe our domain. This is a very important key concept in factories, since it is through this simplification (abstraction), described in familiar terms of the domain (common language), that we can allow a broader base of factory users to create complex solutions using the factory.

There are still many challenges in the actual implementation of your factory such as new tools and technologies to learn. There are also new patterns and new factory development practices that are emerging all the time – hopefully I can share some in later posts. However, without a common platform of tools to author factories, or a common runtime for them to operate in, we just have to ‘do the best we can with what we got’ for the time being. Building factories is fairly green pastures at the moment, and there is heaps of room to innovate and contribute in this space – I wish you the best of luck.

Factories 201 - What would you build?

jezzsa — Mon, 12 Feb 2007 20:00:00 GMT

Previous posts in the Factory 201 series:

We have seen what a factory is in concrete terms, we have seen what conditions warrant the pursuit of building a software factory for a specific domain, and some of the value proposition, considerations and costs associated with that decision. So far we have painted a pretty good picture of the context within which factory development should get started.

This is the first of several posts discussing the actual implementation of a factory. Now, "What would you build?”

We want to have a look conceptually at the types of things that you want to do to automate the assembly of our product, and how those things map to types of automation assets you can use to make your factory.

Asset Transformation

Building a factory is a progressive and iterative process. We can have a look at the steps in that process in more detail in a future post called "How would you build it?" but for the time being, it should be emphasised that building a factory is not an 'all or nothing effort' and certainly not an 'all upfront effort' where you meticulously plan the entire factory before getting started on building it. Although a popular myth, the 'big-bang' expectations of analysing and engineering a fully-blown factory in the first development iteration is simply not realistic - and not highly recommended as a successful approach.

What is called for is a more progressive, iterative development approach from initial product-based assets (ideally a reference implementation) and then gradual analysis, refactoring and application of automation to these initial assets. Each development iteration commits the factory builder to increasing levels of automation and automation asset creation, but also in each iteration, yielding a completed product from the factory.

[I wanted to use the word ‘agile’ in the previous paragraph to describe the iterative, progressive approach to building a factory. But in my experience, when people say the word agile, it tends to get misinterpreted to meaning agile development practices such as extreme programming and test driven development etc. That is not the intended meaning here at all. The intended meaning is agile development; i.e. developing software in iterations of short periods of time, releasing increments of new functionality. The development practices used to achieve that are not relevant for the purposes of this argument]

You have to keep in mind that a factory is a tool, and because it is a tool, it is in fact a development project in itself. You can expect many versions of your factory, and each release to have ever increasing functionality, and more reusable automation assets. Conversely perhaps, you can imagine that the product the factory creates will remain relatively the same (with respect to scope). All that will really change is the variation in the products the factory creates and the form of the product assets. That is, your product line grows to suit the scenarios you want to address.

Things you want to do

At some point you'll have to determine how far to go in moving from building a specific solution (reference implementation) to a fully automated tool (software factory) for building general solutions to your particular domain – a product. How far you go will be determined largely by the scenarios you'll want to address for the products you are creating; i.e. how much variability you want to automate, the level of usability you want to offer, the productivity you want to gain, and of course, realistically, how much resource you can commit in the construction of the factory.

So let’s have a look at some examples of the sorts of things you would want to do to automate the assembly of your products.

Generalise the Solution - in the simplest case you may just decide to generalise and refactor an existing solution (a reference implementation), identifying the variable parts and refactoring the invariable parts in preparation for automation. The common parts of this commonality/variability analysis might simply be a set of class libraries or ideally a framework tailored specifically to this domain, which will be delivered as part of the product from the factory. The variable parts will be configured by the factory user whilst using the factory and the patterns for those parts may also be harvested for automation at this stage, resulting in patterns, code templates or perhaps a description or meta-model of those variable parts. Your framework won't be highly generalised just yet because you might not know of many concrete scenarios to accommodate yet, but this is typically the first step. One could argue that this is indeed the minimal pre-requisite step before the application of automation. Many mature frameworks have already performed this generalisation and refactoring many times over and so those are most ideal to start with.

Define a Solution Structure – more than likely you will want to offer the user of your factory some guidance about what artefacts make up the product and how those artefacts are physically related for deployment purposes. Not only might you want to structure the physical product in the artefacts that represent it (i.e. projects, files, solution folders etc.), you will probably also want to make suggestions about the naming of those artefacts and possibly how they are namespaced by default. Your factory will be adding a specific set of artefacts and structure to represent each component of the product. Handling structure, name and namespace changes to artefacts could also be handled automatically by the factory.

Automate a Development/Design Task - you may want to automate a development or design task. These would typically be mundane tasks that need to be performed throughout the life cycle of the product you are building. The objective being either to remove mundane and manual processes, and/or increase the chance that the task is executed predictably, accurately and completely. Examples may include, changing the name of an artefact or class, namespace, running build commands, automating configuration tools, completing development processes etc.

Generate Artefacts or Configure a System - at some point in some factories you'll want to generate some artefacts or configure some other system. Generation of artefacts is not restricted to source code generation; it could just as well be generating configuration files, XML files, database records, intermediary data, documents etc. You may also want to configure another system (i.e. web server, or collaboration platform) as part of the product. Typically, what is generated or configured will be determined and controlled by the factory user's configuration by some means of interacting with the factory. Sometimes, this configuration is persisted by the factory (domain models), other times it is requested at generation time from the user or environment.

Model a Pattern, Process or Architecture - you may decide to model an architecture, process or pattern to simplify the problem domain and focus only upon the variable parts of it. You may also want to be explicit about a process or pattern to aid the user in designing the solution. For this you would typically create a domain model for either the whole or part of the solution. Typically, these models require associated editors or views (windows) with which the factory user can interact with them.

Things you want to build (Automation Assets)

Now that we know the sorts of things we want to do, let’s have a look at the types of automation assets we need to create our factory.

[Incidentally, each one of these assets requires an increasingly higher cost and larger commitment to automation level provided by the factory]

Solution or Project Templates – probably the first step to automating the construction of the product is to place the reference implementation or its non-variable parts in solution or project templates for easy installation to the developer’s environment. The templates provide the physical structure and naming for the artefacts of the product. Templates can also be easily used to add parts of the product as they are required by the factory user. Supplementing this mechanism with a means to define the specific naming of the artefacts (and various parts of their content) would very quickly gain productivity in the assembly of the physical product.

Artefact Templates – (code templates) these are often the result of refactoring and generalising an actual reference implementation, where it is pretty easy to see what parts of solution artefacts (i.e. source code) of the reference implementations vary and therefore needs to be provided by the factory user. Artefact templates are easily built and customized to suit specific naming and formatting practices. Furthermore, they are easily deployable in the solution or project templates and their content could be initialised by the mechanism that drives that.

Automated Action - there are many actions required to be performed in the assembly of any given product, and many of these can be automated to some degree. Some of these actions will require specific context and configuration, and this can either be gathered from the environment, the factory runtime, the state of the current product, or the user can be prompted to provide that context and state, using abstractions like wizards and models etc. Automated actions can be combined with templates to supplement the initialisation of the artefacts created.

Domain Specific Language – in some cases it’s beneficial to provide useful abstraction using a tailored, specific language to describe a part of the product you are automating – a specific domain. A custom language will define a logical domain model of that part and expose a meta-model which describes the configuration of the variability of those parts. Typically, there would be at least one view (representation) of that domain model with which the user manipulates the underlying domain model. In some cases there may be multiple views each manipulating a different aspect of the same model, or multiple models concerned with different aspects. These views maybe visual (diagram) or textual like a programming language, and typically the artefacts of the product parts are generated using automated actions, and artefact templates. Domain models are ideal for maintaining the state of a product and the basis of mapping from one abstraction to another, be that source artefacts or other domain models.

Integrated Logical Design Experience - if desirable, further automation and contextual guidance can achieved by defining an entire integrated logical design experience that the factory can use to control the entire state and automation of a whole product. Creating domain specific languages and automated actions are typically applicable to only parts of a product, and the factory user is relied upon to compose the final product according to some understanding of its overall architecture. By creating a domain model of the entire logical architecture of the product and providing views of that tailored to various aspects of its assembly, an enormous amount of productivity and quality can be achieved with this high level of automation. In such cases, the factory requires a much larger degree of integration and control of the product, and the abstractions it defines and generation of its physical parts. In most cases this requires a runtime to manage the processes of assembly, and invoke automated actions at appropriate times to orchestrate the construction of the product. In some cases, providing such a comprehensive, integrated design experience may require additional extensibility to allow other factories to provide the necessary parts, so the factory does not become too inflexible to variation, and over complicated.

Summary

In this post we have had a look at the conceptual types of things that we want to do to automate the assembly of our product for our factory. We have then had a look at what kinds of automation assets we would require to do that and how they are expected to work logically.

In the next post (“With what would you build it?”), we can see how the automation assets are provided by current tools and technologies, understand the terminology they use, and how to use them to create our automation assets.

Factories 201 - How long will it take?

jezzsa — Fri, 02 Feb 2007 12:00:00 GMT

Previous posts in the Factory 201 series:

In the previous posts we have set a good context for embarking on software factory development. Much of that depends on the support we get from management and what we have to start with (assets). One of the key questions from management to approve this kind of approach is "How long will it take?" which of course implies a similar hidden question "How much will it cost?".

Answering the hidden cost question above is not really what I want to give guidance on here since that clearly depends on so many different things. Better, I focus on the stated question about how long will it take.

[Before I do that, I want to make a BIG DISCLAIMER: The following guidance is based upon experience in this domain, and in no way represents absolute, verifiable estimates. I will give the reasons to the numbers I state and how they came about, (so you can derive your own specific calculations and factor in your own specific balances). Please use your common sense; this is not scientific proof, only best-guess estimates, and please comment if you see any errors that need to be corrected. Individual factory development cases may well deviate from those assumed here. When someone provides us a better means to make more accurate estimates, I’ll be sure to share that too]

I am going to split this post into the 3 areas to address answering this question. Firstly, the generation of assets, since that’s the core of what a factory is. Secondly the construction of the factory around those assets, and finally about the return on investment (ROI) you can expect from a factory development.

Generation of Assets

When we consider the time it takes to create the initial assets before you get started with building your factory, what we are really asking is "how long does it take before we can get started with building a factory?" This is because, as we saw in When would you build one?, you are strongly recommended to start with some initial assets before building the factory – typically, but not always a reference implementation.

Therefore the answer to this question is easy: You should have largely already made this investment in your initial assets!

You can probably skip this next bit, if you fulfilled the prerequisites as set out by When would you build one?

However, there may well be cases where your initial assets are in a state not quite ready for a factories approach, and require pre-work in further refinement - and this can be fine. Not all starting assets have been in the right re-use track from the get-go to be in the right state for re-use (i.e. fully generalised). For example you might just have a bunch of code templates or patterns to represent your product. However, the answer to this question is not so straightforward now.

Typically what is required for these assets is generalisation, refactoring and packaging into a reference implementation at the very least.

If your assets are just bare frameworks and class libraries then you can probably skip this refactoring step, and focus on building an initial reference implementation on that framework/library before you get started. The net result is that how much work you need to do there will depend very much on the following things: domain scope, technology availability, available best practices, asset maturity, domain skills, experience, knowledge and other factors that affect the quality of the assets.

[It's worth making a distinction at this point between the initial assets you have that make up your product (i.e. RI's, frameworks, libraries, code snippets etc), and the automation assets you build to make up your factory (i.e. recipes, templates, DSL's etc). Those factory assets you most certainly won’t have already created yet, and they are considered in the next section.]

Factory Construction

Once your starting product-based assets are ready to go, the next consideration is how long will it take to actually build the factory-based assets, and complete the factory around those assets?

The answers really depends on what level of factory automation you want to go to. The simplest case might just be: you may just package your RI as it is and deliver a simple recipe with solution template that installs the RI as the final product. A more complex case might be a fully automated, integrated factory with multiple views, editors, DSL's, logical architectural designers, workflows, role management etc. Obviously, the effort to complete the latter example will require more investment than the former. Your factory might lie somewhere between the two eventually, but hopefully towards the later-end rather than towards the former-end, since this is where factories are going to go in the future.

As we will see later in "How would you build it?" the approach to building your factory is an iterative one. Each iteration focuses on a particular variability point of the product, and builds the automation assets for that. The factory is then used to create a new fully implemented product which would have only varied from the previous product, (from the previous iteration), by some variance in the product. The whole factory development will consist of many of these incremental iterations, and each iteration usually entails the creation of/modification to a factory asset.

Clearly we are going to have to go beyond a calculable estimate here to a rule of thumb, since the answer depend on so many variables. Building a factory is, in principal, the same thing as building any other developer tool or re-usable asset. Therefore, you can expect it to take of the order ~2-3 times longer to build the factory than building a product from it, from scratch.

What we mean here is the total time period from start to finish of the factory development as a whole, not the time for a single development iteration of the factory. You must consider that, at each iteration, (which will be considerably much shorter), you can still deliver a fully functional product. So the point of this is to highlight, that you don't need to wait 2-3 times longer than usual to get a product, you'll be getting one at every iteration right from the start. The only difference will be the products, at each iteration, will that it will become more and more customized and hence suited to a particular product scenario.

[You can imagine in reality this time may take longer if the resources that build the factory have to learn new factory building tools, and develop factory building skills and experience. The above estimate assumes the people building the factory are experienced at it. ]

Return on Investment (ROI)

The above estimate begs the question of course, if it takes longer to build a factory than the product, then what do we have to do to get a return on that investment?

The logical answer to this question is simply, that you must create more than one instance of a product for the factory to be financially viable. This was one for the stated objectives for building a factory in When would you build one?

Just how many instances are we talking about though?

Using the logic expanded below, you can roughly expect ROI only after ~3rd – 5th product instance is sold.

The ROI values stated above come from the following assumptions and estimate calculations:

Initial Assumptions

The sale price of a factory-made product is the same as the sale price of one-off developed product
The sale price of product today is same as the sale price tomorrow
The resource cost to develop a factory is the same as the resource cost to develop a one-off developed product (i.e. same developer skillset)
It takes at least twice as long to create the factory, than to create a one-off product.
The time to generate a product from the factory, and complete the final product is negligible.

Lower Estimate

To get our lower estimate, your first factory-made product sold only covers half the original cost of building the factory, so you need to sell more than 2 products (i.e. at least 3) to get the initial investment cost back.

Upper Estimate

The upper estimate comes from the realities of software development today.

The sale price of a one-off developed product today will be higher than the sale price of a factory-made product tomorrow. (Perhaps 40%-70% cheaper tomorrow?)
The cost of software development today is lower than tomorrow. (Overheads increase, skills become harder to find, inflation etc.)
The cost of factory development resources is higher than ordinary one-off development resources. (Requirement for more specialised skills).
It takes time and cost to generate and complete the product using the factory.
There is potentially financial loss in not delivering product to market in the extra time it took to finish the factory.

All these considerations (and many others) contribute to the fact that more instances need to be sold to recover the cost. The actual upper estimate may well vary depending on many conditions affected by the variation of any of the above statements.

A Safer Estimate

For arguments sake, and to be on the safe side, considering the real world factors hinted at above, we should use a rough guide of requiring to creation of ‘many more than 5 instances of a product’ to recover costs. This is the estimate used in the other posts.

Conclusion

Hopefully we have given you some idea of how long it takes to develop factories (although not precisely scientific). Also that this type of development requires a larger initial investment with a deferred payback, which is typically quite different than normal product development for most, but nonetheless the same strategy as building reusable assets today.

This kind of monetisation strategy often conflicts with normal development projects (which normal generate profit after the first release of a product), and demands separate treatment from normal software developments. Another reason, why your management, and organisation needs to support a software factory approach.

Hopefully we have given you an idea of how to calculate the justification to move forward with a factories approach, and that you would not attempt a factory approach unless you were confident that you could return on your overall investment in one.

Factories 201 - When would you build one?

jezzsa — Sat, 27 Jan 2007 03:20:00 GMT

Read this post to find out what the context for these 'Factories 201' posts is.

Following on from Edward's post "Factories 201 - What are they (concretely)?", I am going to contribute what I think is the next question in the logical sequence hopefully going through your mind -> "So, when would you build one then?".

Here, we are going to explore the reasons you would look to building a software factory and the things you need to have in place to start that process. The process you need to take to achieve a factory, we can talk about later (perhaps a future post called "How would you build it?"). For now let's look at 'when' it's applicable to build one.

I am going to break this post into 3 sections, the first one is the pre-requisites you need to have in place to build one, the second section is the objectives you have driving you to build one. (It's a little 'back-asswards', but most developers think of the 'what' before they think of the 'why'). Then finally, the third section is a quick summary re-iterating basically 'when not to build one'.

Pre-Requisites

In order to start down the path of building a factory, for the most part, you need to have done a bit of work up front to get to a stage of considering building a software factory. You may not have done that consciously or indeed even with factories in mind. But nonetheless you need to have done that already. Starting from scratch in a new domain with no assets and no domain knowledge is not a recommended path for factory success.

This section lists the things you need in place to consider building a factory.

A Specific Domain

The very first thing is to have identified a specific problem domain and solution domain that your factory will address. That involves scoping the problem domain tightly enough that it is 'specific enough' to warrant investment in a factory. Without a specific enough domain, you are either 'biting off more than you can chew' and your factory will never be successful (relative to others that are more specific and specialised enough), or your domain is too generic that the value of your factory can provide to solving a particular problem well enough is too limited.

[Have a look at this article (in the 'Abuse' section) about some of those pitfalls.].

The right balance to achieve between 'specific enough' and 'too generic' is pretty hard to advise upon, but I think common sense prevails generally here. You might want to look at existing frameworks or tools already available for an indication of domain scope.

A Well-known Domain

The second step is to target a solution domain which you know very well. It's very important you choose one you have already solved successively and successfully many times over. This means that you already have the domain understanding and expertise in this domain to generalise the domain. You already know the problem domain and a solution domain intimately well, and know what to preserve of that knowledge and experience in a concrete tool that builds specialised products for that domain. The next steps of realising a factory from that should be reasonably straightforward enough from here.

Without this knowledge you are bringing too many ‘unknowns’ to the table. Unknown scope, assets, variability, concerns, roles, resources, technology, patterns etc. Since the process of building a software factory is the automation of existing assets and variability, and assembly of a product line of product variants (product ‘flavours’ if you like), you will not know how to do this the best way without the prior knowledge and experience of doing that at least for one 'flavour' of your product.

You would be poorly advised to attempt to build a factory for an unknown domain.

Existing Assets

To follow on from the previous section, having assets in some form before you start building a factory is absolutely a pre-requisite. Without them you have an arduous task of creating assets for you domain, which is both time consuming and risky. You don't need to create all your own assets, some of the best ones are done by other domain experts. Your job as a factory builder is to bring them together to address a specific domain.

So what do we mean by assets? Assets are physical things that are used to define and assemble the product of the factory.

We can look at the assets in more detail perhaps in a future post called "What would you build?"). But for now, the assets we are talking about are things like: Reference Implementations, Frameworks, Class Libraries, Code Templates, Patterns, and other guidance.

Skilled Resources

In order to have the above domain knowledge and assets, it goes without saying you must also have the time and skilled domain resources to build and support the development of a factory. These resources are absolutely required to have the domain experience and skills to follow that through. Software factory development demands the very best skilled resources to focus upon them. Since in building a factory you are codifying that domain knowledge and experience and onselling it.

Later we can look at how long that development may take based upon some rules of thumb (perhaps a future post called "How long will it take?"), but for now its suffice to say: You won't succeed without the domain skills, and time and resources to construct your factory.

Of course, in most organisations the distribution of resources, particularly skilled ones, is very much dependent on the organisational culture, values, middle-management support and customers. This is one aspect many organisations naively ignore. Software factory development, like application framework development, is often seen as an investment commitment separate from the core line of business. This means, that you see no immediate return on this investment, and unless the organisation ardently protects its skilled resources and lets them focus on this investment undisturbed for the duration - the development will fail. Perhaps we can explore this some more in a future post called "What do I tell my manager?"

Objectives

You need to have a clear picture of why you want to build a software factory. There has to be concrete business objectives driving for the construction of one. Building a factory is no trivial task, (especially today) so, to make it worthwhile you need to be clear why you are making an investment in one.

This section lists some of the more important objectives for wanting to build a software factory.

Economies of Scale and Scope

In order to justify the additional expense in building a software factory (compared to a one-off development project), you need to at least be required to want to build multiple instances of a ‘product variant’ from the factory.

[A 'product variant' is simply the same product created as before but with different characteristics - perhaps a different colour (in the simplest sense). So a factory creates product variants which each have similar structure for the most part but different characteristics.]

As a general rule, you will need to want to build of the order, no less than ~5 instances of a product from your factory (during its useful lifetime). And perhaps no less than 2 variant types. We can investigate more deeply how we came to this number, and the additional costs perhaps in a future post called "How long will it take?". But any less than this number and you will simply not be able to justify the additional cost it takes to automate the production of your products.

The number of product instances achieves economies of scale. The number of different product variants created by the same factory achieves economies of scope. You need to achieve one or other with your factory to be profitable.

Guidance and Re-use

You will want to build a factory to encapsulate your expert domain guidance, experiences and knowledge, your architectures and your patterns. You want to do this in a way that allows others to re-use that in their products. That way, no one will want to re-invent the wheel every time they approach this domain, instead they will use your factory to solve the problem.

Encapsulating your guidance in your assets represents your value in the re-use market for that domain. The factory that encapsulates the best guidance for re-use, ought to win the deal. (The truth of that remains to be seen of course).

Automation

The basic objective of building a software factory is to provide a tool to automate design and development tasks. There are many tasks that need to be performed in building a solution to a problem domain. Without automation, you are simply providing only written guidance for completing manual steps of a process.

This does not have to be full automation. In fact in most cases, most tasks will only ever be partially automated, and will require further modification either manually or by another process.

Automation can take many forms, but you'll want to use automation to remove the mundane, and predictable, whilst preserving the creative design experience for those using your factory. Don't underestimate how potent creative thinking is when trying to find people to program computers. The future users of factories tomorrow are the programmers of today, they want to be lazier, not less smart.

Usability & Productivity

In order to reach high levels of productivity, you need to increase the use of abstraction, and supplement that with high usability of your factory.

Increasing the level of abstraction, increases productivity through these mechanisms:

Addressing a larger, less-highly domain-skilled audience

More users are available, and able, to use your tool to get the job done

Providing simplified representations of the domain

The users can focus on what makes the product variants unique rather that what makes them the same.
The users can focus on the important aspects of the variable parts of the product (in terms of the generally understood problem domain)

Abstraction and Usability are key quality attributes of a software factory, and key to the adoption of any specific factory. Perhaps we can see how that is in more depth in a future post called "What should you strive for?"as a builder of a factory.

Summary - 'Don't build one when...'

So, a bit longer than intended, but I’m hoping to drive some points home, particularly emphasising when a software factory is appropriate based upon what you have and what you want to achieve.

To summarise here are some general guidelines when NOT to create a software factory.

When confronted with a new problem domain.
When the solution domain is unknown or untried.
When the solution domain is broad and generic.
When you don’t have the domain skills, knowledge and experience of this domain.
When you possess no existing assets.
When you don’t know the variability of the solution, or your desired product variants.
When there is nothing to automate.
Just because it sounds like, and looks like, a cool thing to do! - very, very bad idea - be shamed!

Factories 201

jezzsa — Thu, 25 Jan 2007 16:26:00 GMT

Edward has started a new series of posts about factory basics called 'Factories 201', and he has kicked that off with a post entitled "What are they (concretely)?" Which I think is such a fantastic idea to get back to grass roots, and addressing the wider community. I am going to have to participate, and pick up the gauntlet he dropped so squarely in my lap.

For some time I have been involved deep down in the guts of this stuff probably so much so that my posts have only reached a small minority of people in this space. Just the length of them is scaring people off I think, but also the level of some of them is right up there too - perhaps more at the 300-400 level (to using this US rating system). My real intended audience is the mainstream general architect/developers, because it is with these guys I spend most of my time sharing their pain, and it's these guys who are to champion and carry this burden in the future. (Although we are all hoping it is the helium-filled, carbon-fibre version of that burden).

I am hoping, with this new series, we are going to take a little step back and start from the top again, and focus upon the 'down to earth' issues and aid understanding of this approach at a more 'accessible' level.

Many more of you are entering this domain this year, and there is not that much around to help you out with general understanding of the practical processes and techniques needed to succeed in this domain. Most of the info right now is either highly-technical stuff or highly-academic and too abstract, and the communities are not really well established enough yet to accommodate the wider audiences.

Neither Edward nor myself are what they call 'white-collar' architects, we both work at the coal-face of this stuff, and we feel that most of you do too, so that's the level we aim to keep this stuff at. Although we do hope to progress your understanding and vocabulary in this domain. Hopefully we can plug the gap missing in the communities at present.

You might want to start with Edward's post "Software Factories- Where to start-" to get some basic background context, and then move to his starting post in the series "Factories 201 - What are they (concretely)?"

I will follow up shortly, and join Edward in the '201' series.