Model-Driven Software Development Teams

(1)

Soft

Model-Driven Software

Development Teams

Building a Software Supply Chain

for Distributed Global Teams

Author: Jorn Bettin Version 0.2

June 2004

(2)

Revision History

Version

Author

Description

0.1 Jorn Bettin Initial version, April 2004

0.2 Jorn Bettin

Update June 2004.

Added section on Team Structure, Roles, and People.

Added references.

REVISION HISTORY...2

1 INTRODUCTION ...4

1.1 THE MOTIVATION FOR SOFTWARE SUPPLY CHAINS...4

1.2 FUNDAMENTALS OF SOFTWARE PRODUCT FAMILY DEVELOPMENT...5

1.3 TERMINOLOGY...6

2 SOFTWARE PRODUCT DEVELOPMENT MODELS ...8

2.1 IN-HOUSE...8

Costs and Benefits...9

Risks...9

Applicability...9

2.2 CLASSICAL OUTSOURCING...10

Risks...11

Applicability...11

2.3 RADICAL OFF-SHORING...12

Risks...12

Applicability...13

2.4 CONTROLLED OFF-SHORING...14

Risks...15

(3)

Page 3 MDSD Teams

2.5 ADDITIONAL PARAMETERS...16

3 CATEGORIZING YOUR SOFTWARE INVENTORY...18

3.1 SELECT FROM BUY, BUILD, OR OPEN SOURCE...19

4 DESIGNING A SOFTWARE SUPPLY CHAIN ...21

4.1 THE IMPORTANCE OF OPEN SOURCE INFRASTRUCTURE...24

5 TEAM STRUCTURE, ROLES, AND PEOPLE...26

5.1 DEVELOPMENT OF A PRODUCT PLATFORM...26

Domain Experts ...26

Domain Engineer...27

Language Designer...27

Domain Analysis Facilitator...27

Domain Architecture Developer (Product Platform Developer)...27

Product Architect...27

Prototype Developer...27

Technology Specialist ...27

Transformation Developers ...28

Further Roles...28

5.2 PRODUCT/APPLICATION DEVELOPMENT...28

5.3 EFFECTIVE COMMUNICATION ACROSS TEAMS...30

5.4 THE ROLE OF THE ARCHITECTURE GROUP...30

5.5 THE FIRST MDSD PROJECT...30

(4)

1 Introduction

In a world where software development costs are becoming a growth-limiting factor, off-shoring software development activities to low-cost locations is a necessity, and distributed software product development is becoming the norm. As those who have been involved in software projects that span not only time zones but also culture and language barriers know, off-shoring is not risk-free, and even though savings on software development costs are achievable, time-to-market and development of the "right" product is far from guaranteed. To avoid the pitfalls, outsourcing service providers now offer configurations that include a mix of onshore and offshore resources of the service provider. This can help to reduce many of the basic communication challenges, but the efficiency of the end-to-end product development process is still determined by the quality of the software development process used. The industry has learnt – the hard way – that big design up-front is not practical for fast-paced development high quality software. A collocated team that includes user representatives can use a highly agile process, and can benefit from an on-site customer. What risk-reduction techniques do you need to compensate for the lack of a collocated team that has direct access to the customer? Your off-shoring partner may have provided you with a number of on-shore resources that provide the link between your product managers, your domain experts and the offshore development resources. To be effective, at least some of the on-shore resources need to shuttle back and forth between locations. What impact does this have on costs, and more importantly, on time-to-market, and the ability to drive an iterative development cycle that includes regular validation of software-under-construction by customers?

In this article we examine different software product development models from the perspective of a software vendor, i.e. from the perspective of a company building and selling software product lines, and we evaluate the limitations and the applicable scenarios of each model.

1.1 The Motivation for Software Supply Chains

The software industry needs to follow in the footsteps of other more mature industries and move towards product development models that are highly flexible, where critical knowledge is embedded in highly automated processes, and where the switching costs involved in moving to different suppliers of commodity inputs are minimized. Even the ideal scenario, where all these issues sketched above have been satisfactorily addressed, still contains risks that can not be ignored. Distributed software product development that relies on external suppliers – whether onshore or offshore – creates dependencies on external organizations and on external technologies/components. The trend towards Open Source infrastructure software shows that the industry only grudgingly accepts dependencies on software from external sources. Indeed, the Open Source paradigm offers a lot of advantages by spreading the costs of infrastructure development and by counter-acting the forces that lead to quasi-monopolies in the software infrastructure space.

(5)

The typical business software vendor who is forced to consider off-shoring of product development faces the big challenge of finding offshore partners who can be entrusted with intellectual property that is at the heart of a product line that needs to be built. Tacit knowledge built up over time in the offshore organization creates a truly monopoly-like dependency unless measures are taken that go well beyond the scope of established off-shoring techniques. Big vendors can solve this problem by buying the offshore organization or by building an offshore organization, but where does that leave financially weaker new incumbents? Even the big players can't control all risks. How stable is the political situation in the offshore location? Countries that seem politically stable today may not be stable in two years, not to mention potential changes in tax legislation and other legislation impacting foreign investors. Issues like these demand the construction of an agile organization, where critical intellectual property is not tied up in a specific geographical location or in the heads of individuals.

1.2 Fundamentals of software product family development

In developing software products and software product families it is important to distinguish between the development of products and the development of the underlying product platform, which may be shared across a number of products in a product family. This distinction is necessary for very practical reasons.

Firstly, concrete projects, such as the development of a specific product release must be completed by specific target dates. Release milestones are best kept immutable in order to avoid being perceived as one of the average software vendors that is not even able to manage a regular release cycle.

Secondly, the quality of the underlying product platform is of critical importance to the success of a highly automated model-driven approach, and it is not advisable to force compromises in the design of the product platform as a result of pressure exerted by fixed milestones in the product release cycle. It is better to make compromises in the development stream of a concrete product, and then to ensure that an upgraded product platform is retrofitted in a subsequent release. This is of course something that is only viable in a model-driven approach, where changes in framework interfaces and changes in the design patterns used in the implementation can be automatically propagated through the code base.

Thirdly, the necessary skills for product platform development differ significantly from the skills required to build product instances, which leads to a natural division of work. The goal of a well-designed software supply chain is to create an organizational model that implements a sensible partitioning of the end-to-end product development process. The parties involved usually extend beyond the boundaries of a single product vendor. External organizations may supply specific components, in the form of off-the-shelf products, and in the form of components custom-built according to specifications by the product vendor. Beyond that we also have to consider the use of Open Source components, which can substantially reduce the initial cost of providing a basic technology infrastructure on top of which product families can be built.

Proper implementation of an iterative approach in both product platform development and product development is a prerequisite for a smooth release cycle. It is a non-trivial task to ensure that the product development teams obtain real value from the product platform, i.e. to ensure that product platform development does not create an

(6)

ivory tower of frameworks and components that is of little practical use. Carefully crafted and implemented feedback loops between both development streams are required for the purpose of coordinating the work and for iteratively validating the output of product platform development.

A characteristic feature of model-driven software development is scalability – in terms of numbers of project team members, and also in terms of geographical distribution of a project. The aspect of distribution is not limited to very large projects with hundreds of team members, and it applies to all software development models involving an offshore component.

1.3 Terminology

Multiple organizations may be involved in developing a product, with "customer-supplier" relationships existing between the parties involved. Because the term "customer" is also used to refer to the target market of a product, the following terminology is used to avoid potential confusion about the meaning of customer:

Your organization is the software vendor, which is in the business of selling a product line to specific markets.

Service providers are organizations that your organization collaborates with in the process of product development. As required we will qualify the term service provider with prefixes such as onshore, offshore, external, etc.

Customers are organizations/consumers within the target market(s) for your products. We use customers to refer not only your current customers, but also to all your prospective customers.

In terms of valuable assets, it is no longer appropriate for a software vendor to only think of components as assets.

Software assets can be anything from models, components, frameworks,

generators, to languages and techniques (software methodology building blocks). Your organization may be involved in building a single product, or may be involved in building a product family or product line. A single product consists of one code base that is made available to customers in one standard configuration, which may or may not be changeable by the customer at the time of installation, or later at run-time.

A product family is a set of related products for a specific market where the members of the family share at least one common software asset. The elements of a product family are referred to as family members.

A product line consists of a number of products or one or more product families to serve a target market. An economically maintainable product line usually consists of one product family. The realities of mergers and acquisitions mean that product lines are not necessarily always structured in the form of a product family. The elements of a product line are referred to as product line members.

Product rationalization is the process of consolidating and refactoring a product line into a product family.

We use the term product to refer to single products, product families, and product lines. Where the characteristics of the product are relevant, we use the appropriate qualified terms.

(7)

We speak of software mass-customization if product family members are produced based on customer specifications in a largely automated process with near mass production efficiency – think of the automated production process of modern cars that are built to the specifications of individual consumers.

We define software supply chain consistently with the nature of software development as a design activity, i.e. a software supply chain is closely aligned with the processes that in other industries would be labeled design chain rather than supply chain.

(8)

2 Software Product Development Models

2.1 In-House

In-house software product development used to be the typical scenario for start-ups and small software companies. In recent years economic pressures and a high degree of competition from established players have meant that this model is becoming less and less viable.

Your Organisation

Customer

(from Business Actors)

evolve Product develop Product

integrate Product

research Prototype

«extend» «extend»

Figure 1 - In-House Product Development1

1_{In this paper we describe business process and interactions with external parties using the} Unified Modeling Language (http://www.uml.org/) notation and the concept of business use cases and business actors.

(9)

Costs and Benefits

If your organization is located in North America, Japan, or in Western Europe, then this model is very expensive. It is justifiable if time-to-market requirements leave no other option and if you can keep software design and development costs at bay through the use of MDSD and automation of the repetitive parts of software design and software development process.

Undoubtedly this model is ideally suited for use of highly agile software development methods, and for involving the customer on-site on a daily basis.

Risks

The biggest risk factor to consider is the high software design and development costs of this model. However, MDSD can significantly lower these costs, an in some cases may eliminate the need to offshore software development.

Applicability

This approach is applicable in situations where the target market is highly localized, and where the closeness to that market can be leveraged to obtain a significant competitive advantage through short time-to-market that compensates for significant local software development costs.

This approach is not suitable in case the target market is global, and the advantage of closeness to the customer is no longer given.

(10)

2.2 Classical Outsourcing

This model is well established and is for example attractive to large non-software companies such telecommunication service providers who need complex software products to support their services. In this case software product development may be outsourced to an external [onshore] service provider. The development model initially is identical to building a one-of-a-kind application. The contractual arrangement may allow the external service provider to sell the software to further parties as a product, where part of the revenue flows back to the original customer of the product (your organization). Besides serving your organization, this creates some incentive to create a product of wider applicability, which may be sold to a large number of customers. The service provider may be involved in the development of a first prototype product, or may only be brought in once a prototype has been developed. Typical providers in this context are large multi-national service providers such as IBM, EDS, CSC and others, who may operate these services under headings such as "strategic outsourcing".

Your Organisation

Customer

evolve Product develop Product integrate Product research Prototype Onshore Serv ice Prov ider

Figure 2 - Classical Outsourcing

Costs and Benefits

Your organization benefits in this model from the contractually agreed cost limits for development of specific software products, and it reduces the permanent staffing costs of the client organization. Because the service providers are typically large and

(11)

financially secure companies, this model serves as an insurance policy to highly risk-averse clients.

Because of the physical co-location of client and service provider (sometimes within the same building), proven risk reduction strategies such as "on-site customer" can easily be applied.

Risks

Often the external service provider takes over staff (typically entire departments) from your organization to acquire necessary domain expertise to build the product. This means that domain expertise permanently leaves your organization. To reduce the impact of this risk, usually the period of the outsourcing contract extends over a period of three years or longer.

Applicability

The risks of this approach mean that it is only an advisable option to consider for software products that are not at the core of the business of your organization, because the products developed may end up being sold to your competitors. If you have a dominant position in a regional market and are not interested in expanding your business to other geographies, then this model provides a way to gain export revenue without needing to expand internationally.

(12)

2.3 Radical Off-shoring

In this approach as much as possible of the end-to-end software product development process is shifted to low-cost locations. Typically, for reasons explained below, in this model the offshore service provider tends to be owned by your organization. In a way this model equates to starting up a an offshore company or to searching for an offshore software development organization that can be bought for the purpose of using it for offshore product development. Significant domain expertise needs to be transferred to the offshore development center to make this model work.

Your Organisation

Customer

evolve Product develop Product integrate Product research Prototype Your Organisation - Offshore Dev elopment Centre

Figure 3 - Radical Off-shoring

Costs and Benefits

This approach requires extensive travel to the offshore location by domain experts and product managers to set up the software product development team. This model tries to maximize the benefits of a low cost co-located offshore team. However the benefits have to be balanced against high travel costs and reduced time-to-market.

Risks

The main risk in radically off-shoring as much as possible of the end-to-end software product development process lies in the significant transfer of domain expertise that needs to take place. In contrast to onshore outsourcing, transferring domain experts permanently into the offshore development center is not an option, and there is no opportunity to simply transplant working teams. The offshore team has to be built

(13)

from scratch or it has to be designed from an unfamiliar pool of resources from an offshore organization.

Once the necessary domain expertise is in place, your organization critically depends on the offshore site, which is the reason why typically the client (your organization) takes a significant financial stake in the offshore organization.

Depending on where the target market of the product is located, time-to-market can become an issue, especially if the product management and marketing teams are not located in the offshore development center.

The customers are typically not located in the same geography as the offshore development center. If the target market is not geographically close to the offshore development center, implementing a risk reduction strategy in the spirit of "on-site customer" is very difficult.

Applicability

This model is applicable if time-to-market considerations are not critical, and especially if your organization already owns an offshore development center. However the lack of technical resources in your organization caused by the radical approach, means that the amount of travel required between locations will remain significant over the entire product life cycle.

The idea of radical off-shoring is an attempt to reuse the simple setup of classical outsourcing, in ignorance of the difficulties that are caused by physical separation between product management and software development, and between software development and the customer.

(14)

2.4 Controlled Off-shoring

In this approach only a subset of the end-to-end software product development process is shifted to low-cost locations. We speak of "controlled" off-shoring not because other types of shoring are uncontrollable, but because the controlled off-shoring model leaves significant domain expertise and technical expertise within the onshore client organization. This model opens up the possibility of using external offshore development partners without incurring the risk of a monopoly-like dependency.

Your Organisation

Customer

evolve Product develop Product

integrate Product research Prototype

Offshore Serv ice Prov ider

Figure 4 - Controlled Off-shoring

Costs and Benefits

In this approach the onshore team works closely with on-site customers to specify products and to develop product prototypes and it requires a set of highly technically competent onshore resources. This may seem to result in significant onshore costs, however experience shows that theoretical cost advantages of fully off-shored prototype development are eroded by the communication inefficiencies with the offshore service provider. Additionally the technical skills in the onshore organization partially preserve a high degree of co-location between product management, on-site customers, and key development team staff members, leading to a reduction in the overall risk compared to more radical approaches to off-shoring. With the right processes and tools, this model avoids creating a critical dependency on a specific offshore service provider, and production of prototypes can be automated to a high degree.

(15)

If MDSD is used, this approach minimizes extensive travel for the purpose of requirements elicitation, and provides the offshore team not only with software requirements specification, but also with a template product that implements a standardized technical architecture. The offshore team is able to code from formal component specifications, and the implementation can be verified against the formal specifications prior to delivery.

The high degree of control over technical quality of the delivered product that can be exerted with MDSD in this approach, reduces the dependency on the specific offshore service provider, and require a lesser degree of deep domain expertise in the offshore location.

Risks

This approach incurs higher onshore costs than more radical forms of off-shoring – at least the proportion of onshore costs to offshore costs is higher. Appropriate tooling and a high degree of automation is required to ensure that costs are significantly lower than in a traditional in-house scenario. The savings in the number of staff required when using MDSD translate to a reduction in size of the required offshore team, and a corresponding reduction in the project management overhead inherent in distributed software development.

Once an organization is committed to off-shoring there is a risk of overestimating the benefits of off-shoring. In particular if controlled off-shoring is the preferred model, and MDSD has been used to automate the software development process to a high degree, the economics of off-shoring the remaining development work needs to be re-estimated, to ensure that the best decision is made.

Applicability

This approach is particularly well suited if the target market and customer based is located in the geography of the onshore organization. It scales particularly well to the development of entire product families and product lines, where different offshore service providers can concentrate on building and assembling certain types of software assets, and the coordination and the definition of architectural standards and quality criteria resides within the onshore client organization.

In this context a model-driven approach is the only option that enables your (onshore) organization to retain control of product architecture and quality standards. For example the entire product platform development and generator development may be kept in-house, and only product development may be off-shored. If the goal is to off-shore product platform development as well, then the model shifts towards radical off-shoring, and incurs the risks associated with radical off-shoring. Controlled off-shoring is certainly the better starting point.

Once off-shore software product development has become a well-established process, it is possible to think about incrementally increasing the proportion of off-shored work – if it can be shown that time-to-market is not negatively impacted. The MDSD approach at least ensures that critical domain knowledge and product design knowledge resides in formal models and model transformations.

(16)

2.5 Additional Parameters

Well-designed software products consist of fairly loosely coupled components. Building new products or rationalizing/consolidating several existing products creates a unique opportunity to implement a proper component architecture that avoids the mistakes that have often been made in the past.

Why is componentization so important? Firstly it allows applying a divide-and-conquer technique to break down the work of building a large system into manageable chunks that can be parallelized. Secondly it enables informed build/buy/Open Source decisions based on economical and strategic considerations at the level of components that are not available in monolithic product architectures.

Supplier Infrastructure Supplier Your Organisation - Offshore Dev elopment Centre Offshore Serv ice Prov ider Onshore Serv ice Prov ider External Serv ice Prov ider Infrastructure Vendor Open Source Proj ect

Figure 5 - Suppliers of Software Components2

Figure 5 illustrates the potential range of suppliers for software components.

2_{The arrows in the diagram are UML generalization/specialization links between the different} types of suppliers. I.e. an Infrastructure Supplier is a specialization of a Supplier etc.

(17)

When designing a product line architecture, it is important not to fall into the trap of thinking that it is sufficient to select one of the basic software product development models (in-house, classical outsourcing, radical off-shoring, controlled off-shoring), but to recognize that decisions about the software product development model need to be made for each major component in the product architecture.

In reality most software products today are not that well-designed and consist of a tightly coupled set of components that are difficult to disentangle. By implication this means that most software products are tied to a certain set of implementation technologies and that changes in these underlying technologies can result in significant maintenance costs. Thus, for the majority of current software products the fundamental idea of easily replaceable components remains fiction. The incentive to implement a proper component architecture comes once an organization understands the full potential inherent in refactoring a product set into a product family.

This article is not the place to discuss the detailed reasons why the principles of component-based development techniques alone are insufficient to achieve the goal of low coupling between components. Suffice to say that there are two main reasons:

Many products don't start out as large systems, and are rather the result of evolution over a period of five or more years. During the period of growth, the point at which informal methods for software development in-the-small are adequate to deliver the features demanded by the target market is passed unnoticeably, and productivity as well as quality slowly starts to decline. Initially the software development organization goes through a "denial phase" lasting usually several years, where the decrease in productivity and quality is blamed on the complexity "inherent" in the requirements and in the product. Thus the organization may pride itself on being able to manually maintain a very large code base rather than questioning the necessity of such a code base. At the point where the realization sinks in that a proper component architecture is the only way to get complexity under control, some parts of the code base have usually turned into unquestionable liabilities (see next section).

The – partially spurious – complexity inherent in some of today's popular implementation technologies requires the use of advanced tools to ensure that software developers don't inadvertently create dependencies that conflict with the envisaged product architecture. More often than not, software vendors are ignorant of the tools needed to effectively manage complexity.

(18)

3 Categorizing Your Software Inventory

If software maintenance and enhancements are performed purely in the context of working towards short-term results, then the quality of the original software design degrades significantly over time. Unfortunately treating software as a depreciating asset, where maintenance only delays obsolescence of the asset value encourages this trend. This traditional accounting perspective is incompatible with the idea of incrementally building and nurturing a domain-specific product platform and reusing software assets across a number of products within a product family.

By leveraging domain-specific knowledge to refactor parts of the existing software into strategic software assets (models, components, frameworks, generators, languages, techniques), the value of the software actually increases, rather than decreases, in sharp contrast to traditional software maintenance. Thus, maximizing return on investment in strategic software assets requires a long-term investment strategy to avoid compromises in product platform quality – that is in addition to the general requirement for agility in the software development process.

Agility and long-term investment strategy are two conflicting perspectives that can only be consolidated if product platform development is consciously separated from product development. In product development, short-term tactical decisions can be made to satisfy time-to-market requirements, and product platform development can develop clean and solutions that are factored into the product family at a later point in a highly automated, MDSD-enabled process..

Of course not all software that goes into a product is worth to developing into a strategic asset. The following classification scheme is useful for planning investments in software:

strategic software assets—the heart of your business, assets that grow into an active human- and machine-usable knowledge base about your products and processes,

non-strategic software assets—necessary infrastructure that is prone to technology churn and should be depreciated over two to three years, and

(19)

Stategic Assets

Non-Strategic Assets

Liabilities

Figure 6 - Categorisation of Software

The identification of strategic software assets is closely associated with having a clear business strategy, knowing which money-making business processes are at the core of your organization, and being able to articulate the software requirements relating to these core processes. Strategic software assets are those that define your competitive edge. Off-the-shelf components are non-strategic software assets because the functionality provided is not unique and could be supplied from a number of vendors. In contrast, a unique component that encapsulates functionality that gives your product a competitive edge is an example of a strategic asset that is worthwhile to refine and evolve, so that it remains a strategic asset, and does not degenerate into a liability over time. However, your strategic assets will rely on non-strategic infrastructure assets. These and need to be identified and treated as such!

Model-Driven Software Development provides the tools to manage strategic software assets.

Model-driven integration allows the use of off-the-shelf products as the main source for economical provisioning of non-strategic software assets. The use of established Open Source infrastructure as a public asset can be leveraged to reduce the cost of building and maintaining strategic software assets.

3.1 Select from Buy, Build, or Open Source

Don't be blinded and ignore the potential of well-proven off-the-shelf products and robust Open Source infrastructure that is used by thousands of organizations. Software development organizations are famous for not-invented-here syndrome. The selection between buying, building, and using Open Source needs to be driven by sustainable economics. I.e. don't compare costs over the short term, take into

(20)

account the longer-term picture, and factor the cost of capital into your calculations. Considering the maintenance burden, is it really worth developing infrastructure and applications that don't constitute the unique core of your business? However don't compromise hard-earned domain knowledge that has gone into your domain-specific frameworks and generators (strategic assets) by replacing them with unrefined and blunt off-the shelf tools.

Strive to evolve your core products into strategic assets that increase in value over time through (re)use and refinement. Widely used and respectable Open Source software should also be treated as a strategic asset—in this case a public asset. Commercial 3rd party software largely falls into the category of non-strategic assets: usually the software is not built entirely on open standards, and you also cannot assume that the product will be supported indefinitely. Hence investments in commercial software should be treated as capital investments affected by depreciation.

Be honest and don't portray all your legacy components as strategic assets in the sense described above, identify the liabilities and strive to replace them by a combination of strategic assets and non-strategic assets.

Unless continuous attention is being paid to the quality of strategic software assets, these can quickly degenerate into liabilities, hence refactor [your product architecture] mercilessly [Beck 2000].

As appropriate, use Open Source infrastructure to reduce risk exposure in terms of vendor dependence. When evaluating Open Source software, carefully consider the Open Source licensing model attached to the software: some licenses allow Open Source software to be built into non-Open Source commercial products, whereas others only allow usage in products bound to the same Open Source license.

A healthy mix of strategic and non-strategic assets may sometimes only include a fairly small core of strategic software assets. Non-strategic assets have a permanent role, in some respects they can be considered as necessary consumables.

(21)

4 Designing a Software Supply Chain

Once you have categorized your software, and once you have identified the strategic assets and the non-strategic assets, you can start to design the software supply chain for your product line. The potential software supply chain may include the following actors:

Your Organisation

Customer

evolve Product develop Product integrate Product research Prototype Offshore Serv ice Prov ider

Open Source Proj ect

Infrastructure Vendor

Your Organisation -

Offshore Dev elopment

Centre

Figure 7 - Potential Actors in the Software Supply Chain

We need to explicitly reflect the categorization of software in the software development process to see the next level of detail.

(22)

Your Organisation develop Product research Prototype dev elop Infrastructure dev elop Product

Platform

dev elop Product Family Members

«include» «include»

«include»

Figure 8 - Ingredients of a Product Line

In figure 8 we differentiate between product development and product platform development, which both are concerned with the development of strategic software assets. All non-strategic assets are summarized under the heading of infrastructure, which is the area that has the highest potential for reducing software development effort through the use of Open Source components. The dependencies as illustrated in figure 8 are also relevant from a technical perspective, as it shows that your products should ideally only have direct dependencies on your product platform and not on external infrastructure. This leads to a very pragmatic definition of the boundary between product platform and infrastructure. It should be noted that the concepts of platform and infrastructure are not absolute, components that constitute a product built by one vendor (for example a relational database product) may be part of the infrastructure of a product platform relating to a product family of a different vendor.

Usually the controlled off-shoring model is a sensible starting point for US-based or European software vendors with a global market, which leads to the following picture.

(23)

Page 23 MDSD Teams Your Organisation research Prototype dev elop Infrastructure dev elop Product

Platform dev elop Product Family Members

Offshore Serv ice Prov ider

Open Source Proj ect

Infrastructure Vendor

«include»

Figure 9 - Responsibilities in the Software Supply Chain

In this picture the product platform contains the strategic assets, and the infrastructure contains the non-strategic assets. Note that under the heading of

infrastructure we also include 3rd_{party components that deliver business functionality}

that you build into your product. We note that there is no universal answer regarding Open Source components as strategic software assets. Relatively new Open Source software with an uncertain future may be viewed as non-strategic infrastructure. Infrastructure is part of the commodity inputs used to build your product line. Other commodity inputs include the services provided by offshore service providers that assemble product family members based on

the product platform,

formal component specifications, and

product prototypes developed on-shore in close collaboration with customers. The product family members built by the offshore supplier are of course also strategic assets. The important step in designing the end-to-end product development process is to ensure that the cost for switching to another offshore supplier is not prohibitively high. This is where MDSD adds significant value beyond an overall improvement in quality and productivity by encapsulating critical product design knowledge in machine- and human-usable format in tools and formal specifications.

(24)

4.1 The Importance of Open Source Infrastructure

In today's world of highly distributed systems, a significant proportion of a typical software system simply provides basic infrastructure services for distributed computing, security, persistence (the ability to permanently store data in databases) and so on. It no longer makes sense to develop proprietary infrastructure for the following reasons.

Infrastructure development is expensive.

Software infrastructure is typically far removed from what defines the competitive edge of an organization, unless the entire business is devoted to infrastructure development.

Customers increasingly demand software that is based on open standards, and want to be able to integrate applications purchased from a range of suppliers. Critics perceive the economics of Open Source software (www.opensource.org) to be limited to the scope of operating systems. However, other types of software are increasingly being commoditized. Open Source desktop office tools and additional examples of Open Source business software are starting to emerge [Compiere]. The Eclipse platform [Eclipse] provides a good example of the Open Source concept being successfully applied to software development tools.

In MDSD model-driven generators [Eclipse GMT] [GenFW] constitute a major part of the basic infrastructure for industrialized software development. In this space the number of Open Source offerings is growing, as is evident when searching the web for the terms "model driven" and "open source." In our assessment the future belongs to Open Source model-driven generator toolkits, where not only the basic generator is Open Source, but also commonly required model transformations are Open Source.

From the economic perspective of a commercial business, all software that does not encapsulate a unique business model or competitive advantage is best either purchased off-the-shelf or taken from a stock of public Open Source resources.

Once an Open Source resource has reached a certain level of maturity and is used successfully by a non-negligible number of organizations, proprietary alternatives quickly loose their appeal.

Today, putting off the Open Source movement as a fringe phenomenon is irresponsible from a commercial perspective, and software organizations who are governed by a culture of looking down on everything that's "not invented here" are risking the future viability of their business model.

Too often a decision to build is the default option and does not have to be justified according to the same criteria that are applied to decisions to buy external software or to use Open Source software.

(25)

Of course using Open Source software is not cost-free, but sharing the burden of infrastructure maintenance and evolution across a large base of user organizations is possibly as far as we can go in terms of "maximizing the work not done". Vendors of commercial software development tools can survive if they change their focus, by providing value-added components with a minimized risk of vendor lock-in on top of Open Source infrastructure.

(26)

5 Team Structure, Roles, and People

In this section we explain what roles are required to execute a model-driven development process.

5.1 Development of a Product Platform

The product platform consists of domain-specific meta models, models, frameworks, code generator configurations, and application development process descriptions. The development of all the artifacts requires a large bandwidth of knowledge that is typically distributed amongst a group of people within an organization. The roles described in this document are not intended to be job descriptions, they are much more representative of the various aspects that need to be covered in software development projects. One person can take on multiple roles, and the exact distribution of roles depends on the skill sets of the available resources. The one organizational aspect that does however have an impact on organizational structure is the separation of software product platform development from software application/product development. Customer Domain Engineer Domain Expert Domain Archtitecture Developer Domain Analysis Facilitator Language Designer _Prototype Developer Product Architect Technology Specialist Transformation Developer

Figure 10 Product Platform Development

Domain Experts

Developing a good product platform requires true expert knowledge in the domain. A "domain expert" should be someone who has built at least two significant applications in a domain or who is a non-software professional with deep knowledge of parts of the domain. For example to build an insurance application the following domain experts may be required: a lawyer with specialization on insurance claims processing, an insurance mathematician, a direct marketing specialist.

Expert knowledge is also relevant for software application/product development, but it has a special significance in the development of a software product platform.

(27)

Domain Engineer

This role is the combination of a Language Designer and Domain Analysis Moderator.

Language Designer

The Language Designer develops meta models, and is thus responsible for the definition of domain specific languages. In the design of languages, the Language Designer works closely together with Domain Experts, Product Managers, Requirements Analysts, and Customers. Regarding the implementation of a product platform, the Language Designer is the key link to the Product Platform Developers.

Domain Analysis Facilitator

The Domain Analysis Facilitator is responsible for the results of Domain Analysis. The determination of commonalities and variabilities n a domain is best achieved through a series of workshops that involve Domain Experts, Product Managers, Customers, Requirements Analysts, Product architects, and Product Platform Developers. The Domain Analysis Moderator can be the same person as the Language Designer.

Domain Architecture Developer (Product Platform Developer)

The Domain Architecture Developer is a summary of Product Architect, Prototype Developer, Technology Specialist, Transformation Developer. We use the term Domain Architecture Developer and not the term Framework Developer, because the product platform consists of much more than frameworks. The distribution of roles in a concrete team depends strongly on the specific context.

Product Architect

The Product Architect makes decisions about implementation technologies and together with the Language Designer develops the (sub)system structure within the product platform.

Prototype Developer

The Prototype Developer, together with Technology Specialists, develops application prototypes that provide a slither through the layers of the product architecture.

Technology Specialist

Technology specialists are required to find elegant implementations as quickly as possible. In contrast to traditional software development MDSD allows a very economical use of implementation technology expertise. Technology specialists are used primarily for the development of thin prototypes, and are subsequently only required when the binding to a specific technology needs to be changed. This is possible because in MDSD expert knowledge is captured in code templates, and can thus be applied mechanically and automatically during the software production process.

(28)

Transformation Developers

Transformation Developers are code generation experts who extract code templates from application prototypes. The development of code templates goes hand-in-hand with the development of domain-specific frameworks, they are two sides of the same coin. Both activities use the same application prototype (reference implementation) as a starting point. The objective is to achieve an optimal balance between the complexity of frameworks and the complexity of transformations (code templates) -neither should run out-of-control.

Further Roles

Besides the roles discussed above, the following roles are relevant for product platform development.

Customers: Customers should be involved in the development of prototypes (reference implementations). In order for usability considerations not to be ignored, the customer should not only provide domain experts but also potential end users - who may not have the deepest domain knowledge, but who'll have to use applications day in and day out.

Product Manager: If products are developed it is not sufficient just to consider the wishes of current customers, and the strategic direction of the product and the needs of potential customers need to be considered. The Product Manager should have not only a good overview over the use of the product with current customers, but also an overview of the target market.

Project Manager: Like in any software development endeavor, a project manager is required. In the MDSD context it is important for the project manager to be familiar and experienced in the rules that govern iterative software development projects.

Requirements Analysts: Requirements Analysts capture product/application requirements in the form of use cases and related techniques.

Test Engineer: The test Engineer is responsible for the development of Test Strategies and the development/configuration of tools for test automation. The generator toolkits that are used in MDSD, can also be helpful in test automation and the generation of test data.

5.2 Product/Application Development

The roles of application/product development are the same in MDSD as in other software development approaches, provided the product platform development activities are factored out of the normal application development process. I.e. application development teams do not:

Develop frameworks

Develop reference implementations or experiment with new implementation technologies

Analyse requirements that go beyond the individual application but are relevant to the entire domain

This shows that all the critical activities that may lead to project delays or quality compromises are factored out into the product platform development stream, and are

(29)

therefore decoupled from the deadline pressures of individual application development projects. This leads to a reduction in the risks of application development. To meet project deadlines, application development teams have the freedom to choose pragmatic implementation options where the product platform does not yet provide adequate support, and a proper implementation is factored into the application and the underlying product platform in a later release.

This technique works because MDSD ensures that a permanent team works on product platform development, and at no point are all resources allocated exclusively to application development. As long as the project managers stick to the MDSD rules for iterative development, there is no risk that all good principles are thrown overboard.

We don't prescribe a rigid team structure, after all, individual teams develop their own unique and efficient practices at the micro-scale, which are tailored to the knowledge and skills of individual team members. In MDSD we emphasize the importance of an appropriate structure at the macro-scale. For example the previously mentioned separation of product platform development from application/product development is essential. Application Engineering Application Engineer Application Architect Project Manager Customer Requirements Analyst Tester Domain Engineering Product Manager Domain Engineer Domain Architecture Developer Test Engineer Domain Expert

Figure 11 Product Platform Development and Application Development

Figure 11 summarizes which resources are required in the application development stream and which resources are required in the product platform (domain engineering) stream. The resources in the application development stream only need minimal knowledge of MDSD.

(30)

5.3 Effective Communication Across Teams

As soon as multiple teams are working in parallel, which is the case in any organization that runs more than one application development project at the same time, horizontal groups are required to ensure the enforcement of standards and to continuously improve the applied software development practices. The most important horizontal group is the Architecture Group.

The Architecture Group is responsible for determining the priorities of the Product Platform Development Team. The Architecture Group consists of the Application Architects (or Lead Designers) of the Application Development Teams and the Product Architect/Team Leader of the Product Platform Development Team.

The Quality Assurance Group is responsible for the definition and enforcement of qualiy standards. The Test Engineer is the technical leader of this group.

The Product Management Group is responsible for the quality of use cases and requirements work products. This group determines the priorities for the application development projects. It consists of Product Managers, Domain Experts, and Requirements Analysts.

The Project Management Group is responsible for smooth project management: achieving target deadlines, productivity measures, and the definition of project management standards.

5.4 The Role of the Architecture Group

It is essential that the Product Platform Development Team does not develop frameworks and related product platform assets in an ivory tower. In this context the Architecture Group provides the critical element of control. The Architecture Group will only be effective if each Application Development team contains one skilled and talented designer that represents the team in the Architecture Group. Care has to be taken that not all of the most experienced resources end up in the Product Platform Development Team. When the Application Development teams drive the priorities, experienced Application Architects can be motivated to lead application development teams.

This approach nicely scales to the scenario where application development is outsourced, and where one experienced Application Architect works together with the technical lead of the external team. In case the "external" team consists of a group of contracted, "internal" resources, the Application Architect may simply take on a team leader and coaching role.

The Architecture Group acts as the customer of the Product Platform Team and drives the platform development process using "Scope Trading" and "Validate Iteration", see [Bettin 2004].

5.5 The first MDSD Project

The first MDSD project of course does not require an overly formal structure, especially if less than 10 people are involved, and the whole team can be accommodated in a single room. The structure described in this document is relevant, once MDSD is scaled up to cover more than one and eventually all software development projects within an organization.

(31)

6 References

[Beck 2000] Kent Beck, 2000, Extreme Programming Explained: Embrace

Change, Addison-Wesley

[Bettin 2004] Jorn Bettin, 2004, Model-Driven Software Development: An emerging paradigm for industrialized software asset development,

http://www.softmetaware.com/mdsd-and-isad.pdf.

[Bettin 2003] Jorn Bettin, 2003, Best Practices for Component-Based Development and Model-Driven Architecture, http://www.softmetaware.com/best-practices-for-cbd-and-mda.pdf.

[Cockburn 2001] Alistair Cockburn, 2001, Agile Software Development, Addison-Wesley

[Compiere] Compiere ERP & CRM, http://www.compiere.org/

[Eclipse] Eclipse project, http://www.eclipse.org/

[Eclipse GMT] Generative Model Transformer project, http://www.eclipse.org/gmt/

[GenFW] Sourceforge.net, openArchitectureWare,