To inspire my two previous posts are 'MVC pattern: Controller is too big' and 'Template projects in software development'., the current post is written base on my deeper thinking how to create the re-usable artifacts in a software company. More ideas are completed after my study on Software Product Line and Software Factories. I will write two posts about the template architecture, the first post is the introduction about the needs and benefits of template architecture, the second post is my suggestion of building template architecture and how to manage it via knowledge management system.

First, we go to the common related technical problems

1. Lack high technical skilled resources

In the resource market, there are just rare high technical skilled resources who has experience of developing architecture, design for various kinds of project and technologies. In Software Company, the ratio of technical architectures resource also is less than the needs of organization.

2. Re-discovering and Re-inventing common solution domain

Solution domain is discovered or invented in other product is not distributed to related products in a product line. Organization takes a lot effort for re-create solution for problem that is solved before, the solution can catch the traps of previous ones or the quality is not good enough.

3. Monolithic Construction - No reusable components

Not only solution domain is not kept in all products in product line but reusable components across products, product lines are not defined. In addition, organization does not have strategy of defining the re-use level of component, what is reused and how it is re-used. The rigid architecture is also the reason cause all components in one product are heavily tight, that cause its components can not be used separately and it is hard to bring one component to other products except bring many related components (but they are not related business domain of new product) and perform tuning code for new products.

4. Inefficient of R&D activities

Nowadays, there are many methodologies, toolkits, frameworks that help development members can increase their productivity and organization can deliver the better quality product with competitive cost. Normally, the cost for R&D occupies 2-3% operation cost of organization and it is not much cost to have the outstanding result especially in small-medium size company. In any company, focusing on some specific technologies and tools is the wise approach to strengthen organization knowledge instead of assigning limited number of resources to research many tools, frameworks

Long time ago, software organizations realize that some components can be re-used across projects and they define the process that promote re-usability of software artifacts, they are documentation, architecture, module, components or API library. However, lacking the good process also the criteria, guidelines, strategy for creating reusable artifacts take many companies effort without the valuable result. By categorizing projects into separated product lines that helps software company can limit the number of product lines they are developing also define the better strategy for reuse. The reusability is not limited in API library, component etc but the group of products that share the similar business domain or architecture, technology. Product lines is the rather new terminology and there are only few resources about it, recently Software Factories term are raised many times and it has different meaning to Product Line though it is derived from Product Line. However both of them promote the reusability of software artifacts.

Product lines introduction

According to [9], Software product lines represent a significant departure from software reuse schemes in which attempts are made to make assets as general as possible without the context provided by an architecture and a scope definition, and from opportunistic reuse schemes in which low-payoff assets are scavenged adhoc from a reuse repository.

Product lines pay off because the investment in the core assets is allocated across the entire family of products. The core assets provide a production capability that allows rapid construction of high-quality products.

Build a product line is a complicated task. In general, it takes a long time for building a set of related products especially it is true for outsource company that usually not control what products they will receive in future. Though maintain the business modeling across the products in one product line is difficult but the task that maintain the architecture also the reusable components in one product line is simpler. One template architecture is applied for one product line that is distinguished to others by architecture, technology also the domain knowledge. One template architecture consists:

Architecture design:

• Software patterns: Integration patterns, design patterns, infrastructure patterns.
• Object Oriented Principles: Open-Closed principles, Liskov principles, etc

Domain knowledge(s): Healthcare, eLearning, Telecom, etc

Technology and Platforms:

• Operating system: Windows, Linux, …
• Platform: Java, .NET, etc and its version platform.

Re-usable components:

• Common API: validation, logging, caching etc
• Domain API: HL7 (Healthcare), Barcode, EDI etc

Development workspace:

• Tools: are used to build product base on template architecture. That includes development tool, build tool and deploy tool.
• Guidelines: document guides people how to build product base on template architecture. It includes using common patterns, object oriented principles also usage of common and domain API. In addition, it also guides the usage of tools or practices of implementing on specific problem domain.
• Samples: it guides development in practice via samples for basic problem that can serve to solve harder domain problem.

There are two things need to be considered, they are domain knowledge (that belong to business area) and technical artifacts like architecture, components (that belongs to technical area). One architecture that fit with one domain also it depends on deployment model. Two template architectures can reuse the same artifacts, such as two healthcare applications on window and web environment can share the components like HL7, EDI etc but they can have different software patterns for separated deployment model.

Benefits of template architecture

1. Increase productivity

The easiest thing we can see that productivity is increased, the cost is decreased. Development team members do not need to create or implementation from scratch, but they develop base on an existing TA that have guidelines, best practices also expert can support them use the TA.

2. Predictable result, higher quality

Due to TA is built by experienced technical geeks, also it is contributed by many real practices from previous projects, the feasible of solution or architecture are proven that make any solution base on TA is predictable and it has good quality

3. Re-use of skills, resources

Lack of high technical resources also they are many frameworks, toolkits, etc that has the same functionalities cause R&D is difficult to define what area they should focus in. By fixing with one solution for one kind of problem that cause organization gather all efforts for this problem instead of dispersing its effort. Members also learn the best tools, best practices of solution and have deep knowledge on it instead that they know many functional areas but only introduction level.

4. Competitive advantage

It is obvious that if one organization can provide the good solution to client, deliver the high quality product and the cost is competitive, that company has competitive advantage compare with its opponent.

5. Resource allocation

By simple usage of Template Architecture also it contains guidelines, practices. That free some experienced technical geeks outside project development. Team members can develop application base on Template Architecture, which are very easier to detect any violations to architecture and implementation. The experienced technical geeks can be assigned to more important tasks such as mentor technical activities, building other template architecture.

Reference

[1], Nguyen Phuc Hai – Template projects in Software Development, http://www.haiphucnguyen.net/blog/?p=36

[2], Nguyen Phuc Hai – MVC Pattern: Controller is too big, http://www.haiphucnguyen.net/blog/?p=42

[3], Software Factories – http://www.softwarefactories.com/

[4], Edward Bakker – Factories 201, http://www.edwardbakker.nl/

[5], Spring Framework, http://www.springframework.org

[6], Spring Modules, https://springmodules.dev.java.net/

[7], Enterprise Library 3.0 – April 2007, Documentation

[8], Jezz Santos - Factories’ ABC, http://blogs.msdn.com/jezzsa/archive/2006/08/09/sfxjargon.aspx

[9], Software Engineering Institute – Software Product Lines, http://www.sei.cmu.edu/productlines/

[10], Gunther Lenz and Christoph Wienands - Practical Software Factories in .NET

[11], Jack Greenfield, Keith Short et al – Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools