Поделиться через

Factory Authoring Approaches – the “Rogers” and the “Johns”

  • Статья

For some time now I have been analysing how the EFx factory runtime has been evolved (and why it evolved that way), and how that could be harvested and generalised for others that that could be used as a possible basis for defining some authoring tools for other factories. The EFx Factory is one of the few factories that has a runtime environment (Object Model, and runtime API) and runtime tools (Factory Product Explorer) that manipulate and view the underlying factory schema (albeit only part of a proper factory schema). We made a start on some authoring tooling for that in earlier posts.

The EFx factory did not start out life as a factory, or on any kind of software factory bandwagon, instead it evolved into a software factory from modest beginnings as an Application Framework (built upon Enterprise Library and other Application Blocks), then later an Architectural Guidance Package (AGP), and now a Software Factory. So, in effect, the factory has emerged from the pure requirement to automate and abstract a well-known domain of existing assets. The objective of building this factory, initially, was to provide a configured development environment (IDE) to simplify, visualise and automate the creation of solutions for a specific well solved domain, using a framework of assets tailored for that domain, see this article for a better, more detailed description of how that worked out.

A while ago, after the EFx AGP was graciously ordained a software factory, it was necessary to explore defining a formal factory schema for it. This started out as an experiment (along with a few of the forefathers of the Software Factory initiative) to help validate the factory meta-schema. The objective was to create a real factory schema instance from an existing factory – using the EFx Factory in this case, as there weren't many others at that time. That exercise yielded some valuable, interesting and contradicting results from what was expected. Since that time though, the thinking, the tooling and the schema for the factory schema have advanced and we have come a long way down the track of formalising the meta-schema for it. We are now on the brink of defining tools and processes for authoring the factory schema (and ultimately the whole factory). A lot of this work is proceeding rapidly in the Visual Studio team as we speak.

There are many challenges awaiting those individuals and organisations who will wish to embark down the track of authoring their own factories - new terminology, new paradigms, new tools and new processes –to mention only a few. One of the key challenges for factory authors, I believe, will be the toolset to make creation of factories straightforward for them.

Common Design Issues

What I mean here is this; I am sure you have experienced the 'Visual Studio Stare' a few times sat in your development saddle, possibly not with Visual Studio, but certainly with other primary authoring tools. Just to recap, this strange phenomenon usually occurs in the early stages of design, when you may have something in mind (a concept, a design, a technical challenge etc), and just don't know how to express it quickly and effectively. You want to get it off-loaded from your mind, express it loosely in informal terms and then manipulate it as you brainstorm and formulate the idea with more clarity and further levels of detail. It's a very creative period of time. - However, the challenge often is that, if you lack the right tools to express your thoughts you do resort to the tools you do know best – your favourite development tools. When you do open those development tools (Visual Studio in this case, since most of us are software professionals, and this is your tool of choice ) however, you either stare at the IDE blankly with no idea how to start expressing your ideas (this is the 'stare'), or, the tool just does not operate the way you expected it to capture your thoughts, according to how your thoughts are arranged in your mind (often UML based tools are an example of this). In either case you quickly get derailed and non-productive, and these initial thoughts and threads are easily lost, side-tracked or rat-holed. Some possible reasons why you get de-railed:

  • How the tools actually works is not the way you want it to (it talks in different paradigms, unfamiliar terms, etc.) – you get frustrated that you can't express the idea quickly or loosely enough without being forced to learn how the tool works first, it constraints, its definitions, or worse, you have to learn how to express your thoughts in a way the tool wants to capture them.
  • Maybe you're forced to define too much detail up front with this tool to be effective – (quite often the case if you chose to write source code to describe your idea) – you spend too much time writing pretty formatted verbose code, and structure, and little time expressing the problem effectively. And good luck changing a thought, approach or pattern!
  • You might get randomized by having to search for an appropriate tool (that does allow you to express yourself), and not finding one in the first 2 pages of search results of your favourite search engine, or even trying out different unfamiliar tools that you discover some time later and abandon because they won't work either for you. By then your ideas have dissipated, and maybe you even start to want to solve this particular problem by writing the tools yourself!
  • You might just quit, and tell yourself it wasn't such a good idea anyway – but you only did this because you couldn't express and explore it effectively.

I believe we are to face these challenges again with software factory authoring tools, and further, I believe that the level of success of the tools, and ultimately what they create, will depend upon the users they are targeted at, and how those users are motivated to create a factory.

Defining Factory Authoring Personas

In this article I'd like to explore perhaps two groups of people (personas) with different perspectives who feel motivated to create a factory – potential factory authors. Hopefully uncover what approaches would suit them best to define their factories.

Of course, I have to simplify and generalise these groups to be productive here, so I'll only address what I think are common perspectives at the two ends of the imaginary scale. I won't be trying to discover a single answer (a single process), as there won't be only one way to achieve this. I am simply exploring perhaps two differing perspectives in the hope that a common set of tooling could be used to satisfy the groups at both ends of the scale. Any one factory author could start the authoring process at either end of this spectrum, and I fully expect that their perspective might swing back and forth during the factory authoring process to suit their current thinking at the time.

[I believe this area will be most significant for most factory authors in smaller/medium organisations who don't have a well defined hierarchy of project team members with defined roles and skill levels. In other words - in organisations where no more than a few individuals (1-5) own both the roles: 1) of authoring the factory and 2) the role of defining the factory schema and its' usage. These two roles, I believe from experience, require quite differing skill sets, and deserve separate consideration. Having both roles covered comprehensively could be pivotal to the success of the factory.]

I've learned, through a few ventures in this industry (mostly failed ventures), that often a good idea requires two types of persons to be successful. One type of person to generate the vision, and market it, and the other type of person to realise that vision concretely – together they own the vision and its outcomes. Without either of these people the idea invariably goes nowhere. More importantly, if one of these people doesn't respect the requirement for the other, the idea generally flops too.

Let's start by defining two common groups of software professionals, each with differing perspectives on building a factory. Then we can see how they would want to do that, and what tools they might expect to be provided to help them do that.

In other words, what are the motivations for walking up to a factory authoring tool and desiring to build a software factory? The two groups of people I will address in this article will be:

The "Rogers"

These people wish to institute, in their organisation, an architectural pattern, practice, or tooling for building automating a well categorized family of applications for their customers. Traditionally, these would be the software architect types. The "Rogers" won't necessarily have anything tangible to start with, no assets, maybe no architecture, they have heard that factories are a great new solution to apply to software development and product line methodology, and have assessed they want to harness and realise that power in their organisation somehow. They have a holistic view of software solutions.

The "Johns"

The people that may already possess related assets (in some form) that, may well have the potential value to expedite the creation of larger family of products. These people may also have the know-how to create/improve more assets. Traditionally, this would the designer/developer types. The "Johns" will already have a fair idea how their assets could be automated, although they may not know or appreciate how to provide user abstraction of those, or the vision or direction of the organisation, or how to unify those assets into something useful to solve real world problems.

I am sure most software professionals in the industry reading this article could empathise with either or both of these groups, and maybe you even identify yourself with one or both of these groups. Of course, depending on your organisation, and the individuals present there, these two groups may well have varying degrees of overlap.

The point here though is, in considering the reasons why these two different groups would 'walk up to a factory authoring tool' in the hope of creating something useful. Once we consider that, we may see what they may expect the authoring tool to provide and how they expect that tool to work for them.

I believe that the two groups (the "Rogers" and the "Johns") see the factory they want to build in different terms, at least initially, and these terms will govern how they wish to define their factory, which in turn will govern their expectations of how the tools should work for them to get the job done, and of course govern the success of the factory they create. I say initially, because I do believe that once they become more familiar with the tools, they may interchangeably move from one perspective to the other during the authoring process as they swap hats during that process. Something most architects and developers do during a software lifecycle.

[In the following discussion, I want to avoid using the term 'view point' so not to confuse that term with the ViewPoints of the factory schema. Instead, for the purposes of this article, I'll use the term 'perspective' instead. However, indeed - these two groups see the factory schema from two different view points.]

It's a matter of perspective

So how do these two groups 'see' their factory in their minds eye?

The "Rogers" will want to define their factory from different views, and roles since they are focused on the 'concerns' the factory should address (or simply their worries) and how they are expressed to the end user. In factory terms, these are the factory View Points.

The "Johns" will want to view the things the factory is building, since they are focused on what the factory will build (the product) and how the factory will operate and on what, for the end user. In factory terms, these are the Work Products, Assets and Artefacts.

You could imagine that the "Rogers" may want to define their factory in a top-down approach -starting with high level concerns, and decomposing the concerns into finer levels of detail, narrowing the domain, and discovering the components they need to build.

The "Johns" on the other hand, may want to build the factory in a bottom-up fashion - defining the basic components and composing them into something more useful, expanding the domain, discovering how they should be viewed.

Of course, these different, almost diametric, perspectives will certainly require different sets of tools to suit these different groups of users. But, since there is a direct relationship between the things these two perspectives hold highest in their view of building a factory (View Points and Work Products), these toolsets would be viewing and authoring the same thing – the factory schema.

Let's re-visit a definition (from the factory meta-schema) 'A View Point contains Activities, each of which uses an Asset to create Work Product' . Therefore, you can either define a View Point and derive its' Work Products, or, you can define a Work Product, and then assign it to a View Point.

[Of course, we need to be aware that this is not a one-to-one relationship, and there can be exceptions to the rule, such as a View Point does not have to have any Work Products, and not all Work Products have different View Points (some have the same View Point).]

So what does this all mean? Well, the ultimate goal is to define (and implement) the factory schema. The question is how to do that considering the possibly different perspectives of the factory authors. If there are indeed differing perspectives?

The "Rogers" will be expecting tooling that enables them to define View Points of the factory and flesh those out, decomposing them further and further discovering the Assets and Work Products. They want a View Point centric view of the factory schema.

The "Johns" will be expecting tooling that enables them to define the Work Products for the factory (probably by deriving them from existing artefacts) and flesh those out, building them up into the product of the factory, discovering the Assets they need and defining the View Points needed to view them. They want a Work Product centric view of the factory schema.

However, neither set of tooling or views on its own will give the whole picture of the factory schema. Also, neither set of tooling together will be enough to define and implement the whole schema. Clearly, there needs to be other tooling to author in detail, for example: the Assets and the Activities.

I believe that we require at least two primary authoring toolsets (views) for the factory schema that complement each other, both top-down and bottom-up. A factory author could use either set of tools, depending on their orientation at the time. One that is View Point focused, and one that is Work Product focused. They both view and manipulate the same underlying factory schema from two different perspectives. These are supported by secondary authoring toolsets to flesh out the missing parts not covered by these tools (for example: tools for authoring the Assets, and Activities).

These tool sets don't conflict with each other, one is not more useful than the other, and neither stands on their own. They simply offer a different 'view' on the same factory schema. A factory author could get started with one toolset, and move freely to the other, or two different authors (say a Roger and a John, can work the same schema using the different toolsets).

Either way, there would be a toolset to suit each persona as they would expect (Top-Down and Bottom-Up - Process Focused, Product Focused), given the way they think about the factory in their minds eye. This then enables them to immediately express their thoughts and intentions clearly, concisely and efficiently, without shifting the paradigms they are thinking in.

Comments