Home 
CM Journal Articles SCM Techniques Number 2
CM Journal Articles SCM Techniques Number 2
|
 Software
Assembly & Subject Matter ExpertPatterns are a well-understood concept in software development. Thanks to Steve Berczuk and Brad Appleton, they are a part of the SCM vocabulary as well. So far, the SCM pattern vocabulary is relatively low-level, concentrated on describing repository layout, branching strategy and the like. The techniques discussed here are not patterns—they don't have the required structure, and don't provide prescriptive formulas for implementation. Instead, these are discrete, recognizable methods of software development or software configuration management. Configuration management is a discipline that connects to every single part of the software development process. This means that CM affects all parts of software development, but it also means that every part of the process impacts the configuration management activity of a project. Many of these techniques aren't pure configuration management—if there is such a thing. Instead, they are techniques that have a high impact on CM. Adopting these techniques may help your project overcome certain CM challenges. Making radical changes to address a single CM issue generally isn't a good idea. But understanding these techniques can help you contribute to shaping the future direction of your project. This series will talk about twenty-two techniques, from five categories. Here they are. Ceremonious Techniques
The Monolithic Development technique (in January) mentioned Software Assembly, and my parallel series on SCM Challenges mentioned Subject Matter Expert, so we'll cover those two techniques in this edition. Software Assembly Software Assembly is the natural extension of the Monolithic Development technique discussed in the last issue. An assembly is a collection of multiple ‘built' configuration items, some or all of which have their own development process and their own release identifiers. These complete items are incorporated together into an assembly. The assembly aspect is the key to this technique. Two separate products in different markets being developed in parallel is not an assembly-it is two separate instances of the monolithic development technique. Assembly components can be any kind of artifact. An entire application, some documents, a library of common routines-anything that makes sense to manage separately can be a component of a software assembly, including lower-level assemblies. This technique is useful when the individual members have different development teams, different technologies, or if they are at different levels of maturity. To justify this technique, at least one assembly member should be released separately from the assembly. If the members are only available as part of the assembly, it will be simpler and easier to stay with the monolithic approach. A common scenario is a member shared between two products. If you have, say, a Mac music player and a Windows music player, and both use a single decoder library for music formats, you may have two separate assemblies with a common shared component. You might still release the two products in lock-step, using Monolithic Development. This could be the case for a Java-based music player, for example. But if they really are separate products, you probably won't. When changes or problems are reported, it is important to correctly identify the member(s) impacted. The separate members will have separate release sequences, separate schedules, and possibly separate development teams. The initial stages of the change or problem work flow must route the ticket to the correct member team. With separate development teams, there may be separate change tracking systems. Obviously, the systems need to be integrated to enable passing tickets across the border. If the members are managed with the same system, some sort of virtual repository must be implemented, using separate databases or identification fields within a single database. In addition to the "major" assembly members, which have external visibility and a separate release schedule, there may be "minor" members. One obvious example is a lightweight member for the actual assembly itself. This would likely include documentation, any build or installation scripts or programs, and other "global" artifacts. There is no need for a separate release schedule for this member-it will use the release identification and schedule of the assembly. When an assembly includes many major members, they may well share common libraries. These shared libraries are very likely to need their own release identification, unless the library is tightly coupled to one of the components. As an example, a library for reading a file format might be tightly coupled to the application that uses that file format. But a library of common string functions would not be tightly coupled with any major member, although it might change with any of them. As a result, the string library would need its own release schedule, while the file format library might be able to use the same release schedule as its parent application. Software Assembly is predicated on having multiple, separately-managed assembly members. This leads immediately to several advantages. Having separate members allows separate development cycles for the members. It also means flexible release schedules. So long as the dependencies are met, an assembly can be released without having to wait for every single member to be updated. The assembly/member hierarchy means that divided teams can be managed more flexibly, and that different technologies (target platform, implementation language, etc.) can be included. Finally, partitioning the release into members formalizes the allocation and hand-off of problems and resources. Unfortunately, every advantage can be a disadvantage as well. The top-level "assembly" configuration item, as well as any interdependent components, must track the development and versioning of the separate members. The versioning of high-level members either must advance every single time a low-level member advances, or must skip over intermediate releases of low-level members. In the latter case there are significant compatibility risks. Dividing the assembly into separately managed members creates control issues. The formal hand-off of resources or problems usually means giving up control as well. Suddenly, bug-fix priority has to be negotiated instead of assigned. A project team responsible for a shared component will be adjusting the release schedule of that component to support all of its different clients. This can put the assembly's master schedule at risk, if a different assembly is demanding significant work in a shared member. The ultimate risk springs from shared dependencies. If two members of an assembly, or members of two separate assemblies, depend on a single lower-level member, there is the real risk that the two dependencies will get out of sync. If member A requires library version 3.1, while member B still uses (and ships with) library version 2.3, a conflict may well occur at build, assembly, or (worse) installation time. This problem is known as "DLL Hell" in the Windows world, and caused significant problems with early releases of the .NET platform. Now, operating systems have a mechanism for working around this issue with shared libraries. Your assembly will have to make whatever changes are needed to address this, and your testing and release teams, plus of course technical support, will have to know how to make things work. Implementing Software Assembly requires separating your change management repository into separate repositories, or implementing discriminating fields to emulate the separation. Almost immediately, releases and schedules will begin to diverge. You will likely have to restructure the codeface in your source repository to allow independent members to be build in isolation. The dependencies between members are a vulnerability that nearly everyone overlooks, usually at the expense of a day or so of lost productivity. The right answer is usually to formalize checking the provided release of each member as part of the build or install script. (I remember one instance where a blown install left us with C++ header files that were not in sync with the underlying libraries. It's amazing how much productivity you can lose by trusting the system files on a young operating system.) The costs of adopting Software Assembly are generally straightforward, and higher than you will probably like. Formalizing and segregating the components will have costs at nearly all levels. Project managers will have to take the time to separate issue tracking and scheduling, development managers will have to accommodate separate development cycles, including independent testing. Developers will frequently have to write additional code to formally separate the members-there is a big difference between a collection of common functions and a truly independent library. The CM team will have to implement whatever code repository changes are needed, as well as restructuring the change-control repository. The build and release folks will have to provide a separate build script for the emancipated members, as well as possibly adding separate build invocations. And of course the "separate" member will have to be integrated back into the client assemblies, requiring changes to the build and installation scripts of the client(s). While most of those costs will be up-front, the build and release processing will be ongoing costs. Depending on the number of members to be split out, and their size and complexity, you may need additional staff to perform these duties. Subject Matter Expert A Subject Matter Expert is exactly what it sounds like: one very knowledgeable individual, or on rare occasions a group that can speak with a single voice, whose answers and suggestions on a particular subject are considered definitive. This technique is not specific to configuration management-there can be SMEs for any number of fields or technologies working together in an organization. But even if the subject is not CM, formally using a SME will have an impact on the development lifecycle. A SME is useful when a project depends on a difficult or complex discipline, but the discipline is not sufficiently popular or well-documented to have a recognized market or specialty field of its own. For example, Struts development is a popular sub-discipline of Java coding and has fairly broad market appeal. If a job listing calls for Struts experience, not much more needs to be said. On the other hand, H.263 is a protocol that isn't generally recognized, and job listings that call for it will typically have some attached explanation; they also generally include a list of alternative qualifications for candidates. Struts programming is common enough, and well-documented enough, that developers and their leads can probably have a technical conversation about any issues that come up. H.263 is not-any conversation will generally be filled with explanations and simplifications. This is a good indicator that a SME would be valuable. Creating (or appointing) a SME is appropriate when the knowledge or experience of the SME is critical to the success of one or more projects, and when it is difficult or impossible to disseminate or replace the expertise. The automotive, defense, and telecommunications industries are filled with these niches. The standards and protocols they use are complex, and the cost of failure is relatively high. In addition, there just isn't a large pool of developers with knowledge of the particular industry details. A SME is hard to create-becoming a SME is comparable to getting a post-graduate degree in a particular subject. In general SMEs are found, not created. It is possible to create a SME by deliberate effort, but such efforts frequently fail, either because the intended expert is resistant to being ‘siloed' into a particular technology or because the newly-minted SME leaves for greener pastures. Part of creating a SME is allocating enough funding to ensure the expert doesn't leave. If you can't or won't offer a 25 to 50 percent salary premium to ensure the SME stays put, then the SME isn't really critical to the success of your project. Another name for a subject matter expert is "administrator." Many software packages, like CM tools or databases, are supported by in-house experts. The same is true for "build engineers" and "installer specialists." One difference between the SME and the IT specialist is that dedicated specialists or administrators tend to have full control over their systems. A CM tool administrator will be responsible for implementing nearly all the changes and updates to the system, while a software (or hardware) development SME is only responsible for a portion of the product. Depending on the subject matter, a SME might only have design- or architecture-level involvement in a product. The IT field tends to treat nearly all changes as the domain of a SME-email changes are made by the "Notes administrator" and database changes are assigned to the DBA. Because so many tools have training and administration requirements, IT work flows almost always include a routing step that assigns changes to the specialist associated with a tool or technology. This represents a significant change for development teams. Development change processes generally assume that changes are approved by technical management, and after this approval any developer can implement the change. The SME technique requires that all changes be investigated for overlap with the subject matter. This means that problem and change request processes must be updated to include routing, impact analysis, and sign-off by the relevant SME(s), if any. The advantages of a Subject Matter Expert are those of centralization. A SME is a single individual aware of all the issues, so coordination and synchronization problems are eliminated. Similarly, the SME can provide a faster decision loop than a group- or hierarchy-based system. Another advantage of the SME technique is that a SME can be bought (or stolen) from the competition. Provided you can locate one in the first place, a SME is a quick way to get a project going in a challenging field. An additional advantage is authority. Hiring the right expert may serve a legal, marketing, or technical purpose by providing documentable expertise. In the case of non-technical experts (say, a medical doctor) this may limit the SME to involvements only in the requirements or user interface of the product. But that is frequently enough. The disadvantages of the technique tend to mirror the advantages. First and foremost, SMEs are hard to find, and if a project is technically challenging enough to need a SME, then not finding one will likely kill the project (or at least the schedule). SMEs represent a bottleneck in communications and in the CM work flow. If a SME is unresponsive, or if an excessive number of changes are being routed to the SME, this can delay the entire team. Also, SMEs present two risks that other approaches can avoid. A SME is, by definition, a single point of failure. If anything happens to your SME, the whole project is jeopardized. A more subtle risk is that a SME is a single point of view. You are trusting the SME to be experienced enough, and have a sufficiently rounded view, to consider all the alternatives. If your SME gets locked in to a single approach, there are no other voices to push for an alternate approach. Implementing Subject Matter Expert is relatively straightforward. The first requirement is, of course, an expert. You need a really smart, experienced professional to fill the role. Because the expert will be interacting with knowledgeable non-experts, it is critical that you not try to "fake it" with SME. The expert has to have credibility with the team, or decisions will turn into arguments, and the benefits of the technique are lost. Some projects just can't benefit from a SME. For example, a project that is succeeding with an agile software development technique probably won't benefit from the technique. First, because the customer representative is generally the expert in those models, and second because the agile techniques are egalitarian and decentralized. SME, of course, is anything but egalitarian and decentralized. For a project to benefit from SME, it must be amenable to centralized decision-making by an authoritative expert. Agile teams can adapt to a SME by separating the design or architecture phase from the implementation, or by including the SME in the customer representative role. In many technical projects, this is appropriate, since the ‘customer' is an abstract aggregate of standards and interoperability requirements. Organizations that are hierarchical in nature will generally have an easier time incorporating a SME into their process. Appointing a SME will tend to increase the workload for the SME. As a result, the project will have compensate with extra man-hours or extra headcount, and will need to off-load some of the non-critical functions previously performed by the SME. Finally, the formal processes and work flow used by the project will need to be changed. The design, change, and problem or bug work flows must be examined for impact on the critical subject, and any changes that affect or are affected by the critical subject must be routed past the SME. Making these changes to your internal tools may require another form of subject matter expert-a consultant. Most of the costs associated with a SME are simple. There will be time lost hiring or designating the SME, and adapting your processes. This time may or may not impact the project schedule, depending on when you roll out the technique. There will be financial costs, too, associated with the SME. When you realize that you have a SME, and formalize the position, that expertise becomes a resume item-if you aren't willing to pay for the knowledge, one of your competitors probably is. Because your processes have to change to incorporate the SME, there may be some disruption while the changes are made, and while the team learns to follow the updated processes. And finally, there is the risk that you will lose your SME to a "matrix" approach. An industry expert represents a corporate resource. The cost to your project is the SME's time spent working for other teams. You no longer have exclusive access to the resource, and must plan accordingly. Looking Ahead I'll try to cover two techniques each month, but there's no fixed order. If you have a particular technique you'd like to have discussed earlier, drop me a line. If you have a technique that I haven't identified, please, please let me know-I don't claim this list is exhaustive. Austin Hastings has spent more than 20 years in the software industry. He has been a developer, system administrator, CM specialist, manager and consultant. Currently he is principal consultant for Longacre, a software CM and process automation consultancy. Austin lives in the southern part of New Jersey (the garden of the Garden State) but travels the world helping to keep software under control. Contact him at Austin_Hastings@Yahoo.com, or through CM Crossroads.
Set as favorite
Bookmark
Email this
Hits: 4260 Trackback(0)Comments (2)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... There are. Depending on how wide-spread the variations are, you may want to look at using Software Assembly, Component-based Development, or Software Product Lines. (Google is your friend for all of these.) =Austin |
kavitha
said:
 |
... Any best practice for release of an application with minor variations for different geographic location?? |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
