Software development has always been a costly and time-consuming process. Specialised requirements and lack of skilled resources are just two of the difficulties facing many companies today.
For SMEs and Major corporation alike skills are in short supply causing many multi-functional tasks and roles being split into a number of individual operations, requiring in some cases a lower skill set
per se, but in turn needing a methodology and automation. The rise of methodologies such as Sigma 6 and Prince 2 are an attempt to encapsulate “common sense” and elements of experience into a “road-map” which can be followed by all concerned. As we all know, even satellite navigation systems can lead some one up the garden path, so use of such without “domain knowledge” or business knowledge within a vertical market can be just as confusing as no process what so ever.
For IT companies the pressure to deliver software, on time and within budget, have pushed developers to look for a way to increase value delivered, while decreasing development time wherever possible.
For many years now, efficient re-use of existing assets, either through object-oriented programming, component based development, or pattern based architecture, has been one of the core objectives for the IT industry as a whole. Re-use is seen as a means to combat many of the problems facing development teams. However, for many years and several different technology paradigms, this level of re-use has eluded the industry.
Economies of Scale vs. Economies of Scope
The differences between these two definitions are subtle and are aspects that have been proven outside of the software industry, in more established industries like manufacturing and fabrication. While both promise to reduce time and cost and improve product quality, they are actually quite different.
Economies of scale occur when the initial development of a design and subsequent construction of a prototype result in multiple copies of that prototype being created. In the manufacturing industry, it’s similar to a machine being built that can produce screws in bulk. In this case, re-use occurs in the latter stage of production, namely construction.
Economies of scope occur when multiple similar, but unique designs are produced in groups, as opposed to individually. Greenfield, a leading exponent of re-use practices uses the example of a car manufacturing plant that uses existing designs, such as chassis, body, and interiors, to produce several lines of distinct cars. Each product line is complete with custom features, but all share that same underlying design. Here the re-use occurs earlier in production, namely design and prototyping.
Greenfield’s research results point out that for years, the IT industry has been trying to apply economies of scale for achieving re-use, when in fact, the IT industry should have been trying to apply economies of scope to achieve re-use.
Chronic Problems of Software Development Many authors identity major problems with how the IT industry has attempted to achieve re-use. Unfortunately, simply altering how re-use is applied within an industry or an organisation won’t make systematic re-use a reality.
Monolithic Development Monolithic development means the creation of software in such a way as to make it difficult or even impossible, to utilise the resulting modules or components outside of a narrowly defined scope. Software development teams within large organisations are certainly familiar with this style of development. Several projects, several teams, all building isolated applications, without concern for what anyone else may be doing, or what, if any, domain knowledge they are embedding within the application. This results in large, inflexible applications that are of little use to anyone outside the original, intended audience. Even two projects within a single organisation can be faced with a large integration or interface effort in order for one application to take advantage of another’s functionality.
Why does this keep occurring within organisations? Industry leaders have championed design by assembly for years, and yet very few applications take advantage of existing components, even within their own organisation. Management should ask this of themselves.
Granularity Typical software development for business applications consists of a strikingly similar set of features and functionality. For example, many business applications read data from a database, present it to the user, allow the user to modify the data in some way, and then allow the user to persist the change back to the database. Even though this is an over simplification of most applications, the basics still remain the same across projects. It begs the question of why developers use such fine-grained tools as standard programming languages like C# and VB.NET for representing such basic patterns.
Part of the reason is the immaturity of modelling tools and languages. While a language such as UML is suitable for documenting software architecture, it is inadequate for allowing implementation to be derived from such models. UML lacks the extensibility required for generating large amount of code, and also lacks the breadth required to represent all aspects of software, including databases and user interfaces.
Process Immaturity In general the software industry as a whole has consistently proven that it is unable to deliver software product both on time and within budget. Attempts at refining this immaturity have followed two paths:
• Controlling complexity at the expense of change – Many “traditional” processes would fall under this heading, including RUP and Waterfall
• Controlling change at the expense of complexity – Most “agile” methodologies would fall under this heading, including SCRUM and XP and by hand. This often leads to higher quality, but also leads to performance and efficiency issues.
Migrating from a craftsmanship-based industry to a more industrial-based industry has been the path of progression for many more mature industries. If this is the end result for so many other industries, why is software development still based on small groups of highly specialised craftsmen?
Most people within the IT industry will agree that a form of standardisation and modularisation is the key to enabling the kind of re-use required for efficient industrialisation of software development. What they don’t agree on is the means to which this standardisation and modularisation is achieved. The way forward could well be to create model driven development in much the same way as prototyping with consideration of existing assets is achieved within the auto industry.
Models & Patterns Definition of Model-Driven Development is:Using models to capture high level information, usually expressed informally, and to automate its implementation, either by compiling models to produce executables, or by using them to facilitate the manual development of executables.
A small software vendor based on “factory approach” originally involved in warehouse design used this approach to transfer modular elements from within their original program to create solutions for a multitude of verticals varying form the Oil Sea Tanker movements for a major Oil company to airport baggage handling and runway efficiencies and planning. In fact they are now known as modelling specialists rather than just a warehouse design company.
The importance of models comes from their ability to keep a consistent representation of concepts within a project. For example, while it’s easy to draw and manipulate an object in a model, it’s much more difficult to manipulate the object at a lower level, because the object could be represented by class files, tables, and columns in a database.
Representing and manipulating core abstractions and concepts within a software system is only half the battle. The other half comes from being able to effectively use those models to generate the underlying implementation details represented by the model
Domain Specific Languages Domain Specific Languages (DSL’s) have long been a way to provide an abstraction on top of existing concepts within a specialised domain. Examples of a DSL include SQL and HTML. Both provide specialised languages for manipulating concepts within their respective domain: tables, rows, and columns in the case of SQL and elements, tables, and forms in the case of HTML. For years, DSL’s like these remained the only cost effective DSL’s because of their wide spread use and generalised concerns. No matter what your specific project entails, if you use a database, you can use SQL and if you use web pages, you can use HTML. Creating DSL’s for other, more vertical concerns was be used with others in future. As their solutions had been developed in isolation and in some cases in competition with each other their attempt at solution “bundling” resulted in true bungling. So much so they were forced to either sell out to venture capitalists or simply close elements of their operation.
For this kind of approach software must be carefully partitioned into distinct and reusable components and those components must readily fit together in a coherent manner. Configuration is the key to Software Product Lines, as projects must be able to pick and choose which components they want to utilise, and then generate an application off of that configuration.
While all of this promises much and sounds appealing, many companies have tried to provide the tools and components, only to fail under the load of using inflexible tools or proprietary formats.
Big name companies like Microsoft and Sun have released many of the components necessary for building and assembling in modular fashion. With the release of Visual Studio in 2005, Microsoft started to make considerable strides to enable the creation of not only Domain Specific Languages easier, but also to facilitate the integration of those languages within the IDE itself. Not to be outdone, Sun Microsystems brought out its own implementation of modular technology, with Java plug-ins and the like. The picture is ever changing in a positive manner for the IT industry and their clients alike.
Anyone wishing to get more information is encouraged to go to Microsoft’s Software Architecture Centre, where they discuss the topics presented above in greater detail, or simply call MWM-systems leading exponents of these concepts for free advice.
Article written by Angelo Quinlan, Senior Consultant.
References: Software Factories: Assembling Applications with Patterns, Frameworks, Models & Tools by Greenfield and Clark
<<Back
