A Collaboration System: Case Study in Solution-Architecture Development-Methodology Application
Summary: It is important to recognize that process rigidity does not necessarily lead to success. This article mentions some of the major software-development life-cycle process categories, the objective being to help you avoid common pitfalls. (8 printed pages)
Stand in the middle of a field on a clear summer night, surrounded by fireflies. Observe how the rhythms that you perceive dissolve into idiosyncratic pulsations.
A few years ago, my employer had requested that I lead our effort to architect a collaboration solution for one of our larger customers, City Power & Light. It had been a long, arduous project, taking a little over two years of my time. I recall the first meeting, when the CIO introduced me to Janet, the architect who would lead the solution-development effort from the customer side...
At the time, Janet was a recent college hire. Upon first meeting, we exchanged business cards enthusiastically, and then scheduled our first project meeting to take a full day the following week. Our agenda included developing a project plan; reviewing the 200-page requirements document (!); getting acquainted with the other project-team members; brainstorming solutions; and writing a scope document for the project. I felt fortunate to have been offered the opportunity to work on this project. At the time, collaboration systems were "the next big thing," and I had not yet worked on creating this kind of application. Very few products existed that could be used to meet the requirements, so our buy/build decisions by default would have to include building components ourselves.
There are many software-development methodologies out there. They can be classified into a handful of general categories. In this article, I will mention some of the major software-development life-cycle process categories. Namely, the waterfall, iterative (or reuse-based), and agile-development approaches to the software-development life-cycle process will all be a part of my story. My purpose here is not to evangelize on behalf of any particular process, nor to review these processes in detail. I assume that you are already familiar with software-development methodologies. If this is not the case, check out the references at the end of this article for some very good sources of information on this topic.
Using the collaboration-system project as an example, I will show you how I adapted practices taken from several different software-development life-cycle methodologies in one engagement and, more importantly, why I did so. Processes themselves are tools—often, supported by software instrumentation, as in the case of the Rational Unified Process (RUP). However, a process need not become a religion. Artifacts and ideas from any of them can be included in whatever methodology you are following to create your solution, whenever you find that deficiencies in your own development process are the cause of problems. You can either introduce greater discipline or relax the rigorous application of a process.
As a practicing software architect who is responsible for overall system-solution design, my objective here is to help you avoid some of the pitfalls that I encountered. Therefore, this article will not provide an academic introduction to software-engineering methodologies, which is well outside the scope of this effort. There is a lesson in this story; but it is not about how to follow a software-development methodology as much as it is a caveat to remain flexible enough within it to recognize some of its deficiencies (should they arise) and to take action by augmenting your current procedures with ideas that are taken from other methodologies, instead of adhering rigorously to only one method.
When Janet and I co-chaired our first project meeting the following week, we were both well prepared. We shared complementary working styles, despite the differences in our experience levels. We worked not only to achieve the work set that was before us, but also to establish a strong partnership among us all: the software engineers, testers, and our project manager. We defined our project through team consensus, voting on our own rules regarding meeting frequency and length. The team agreed that holding frequent, short communications would be more productive. We also reviewed the artifacts; decided which ones we would produce for our project; and documented the ones that we would not produce, and how we would mitigate the risks that were associated with not producing those artifacts.
When it came to applying some of the more current software-development processes, City Power & Light (Janet's employer) was behind the times. The company mandated a strict waterfall development life cycle on all projects, because this corresponded with its project-funding and project-management procedures. The non-iterative waterfall development process, as implemented at City Power & Light, depends upon a couple of assumptions:
· The first assumption is that a completely plan-driven approach to software development will result in software with a significantly higher, measurable success rate and a substantially greater satisfaction level for the stakeholders.
· The second assumption is that, by and large, all of the information that is necessary to terminate a phase can be completely discovered well in advance of the beginning of the next phase.
In the case of our collaboration system, the second assumption meant that the requirements document that we were given prior to the start of our project was considered complete; it was assumed that there would be no requirements changes during the subsequent design phase (see Figure 1).
Because City Power & Light had already terminated the requirements-elicitation phase of the project, Janet and I were happy. We both figured that what was left for us to do was the fun part: starting the design and analysis, based on the system requirements. The document, at approximately 160 pages (not counting the glossary and five appendices), was hefty, to say the least. It was natural to believe—given the evidence at hand and the stipulations of the manager-stakeholders who were involved in the project—that the requirements document was, indeed, complete and fixed for the duration of the software life cycle.
The project hit very few snags. We seemed to have done a good job of time estimation. We made good build/buy decisions, so that we were, for the most part, on schedule in every phase—until we began the verification phase.
Figure 1. Waterfall development-process dependency diagram [Wikipedia]
When the verification phase began, we started integration and acceptance-testing. During acceptance-testing, the software was released to members of the application-user community to ensure that they were happy with the final product. The end users began to kick the tires and work with the software daily, to see how well the application matched their expectations and met their needs.
Here, our project hit its first major snag—pretty late in the game, but a fairly typical occurrence in many waterfall processes. When an omission has occurred during the requirements phase of the process, there will be features missing that might have been expected, but which were never explicitly requested. Our collaboration with end users was restricted by the waterfall process "rules of engagement."
As it turned out, our requirements document did not list something important, which became obvious to our users as soon as they had worked with the software each day. By following City Power & Light's development process rigidly, we assumed that the requirements were completely contained in the requirements document; features that were needed were never discovered or included in our design. Our stakeholders discovered that they needed an indication of presence and online status in the chat subsystem of the collaboration application. As it was currently developed, our users had to attempt to chat with someone before discovering whether the person whom they were contacting was online or free to talk at that moment.
It was clear that this was a significant feature; had we been able to circle back on the requirements with our specifiers—or, for that matter, verify the requirements through a prototype, as part of the software-development process—we would very likely have included the feature in the first release. Yet, there was no provision for doing so at City Power & Light; indeed, we had been strongly discouraged to avoid "impacting our business user's productivity" through any direct contact!
Before the next release of our project could also become plagued by requirements deficiencies, we decided to take action. Janet and I met with the project manager first, and convinced him to support our plan of action—namely, to argue for the creation of a prototype in collaboration with our end users, in the next release of our software. We met with our software engineers to gain their support. It was easy, because they wanted to be able to work a reasonable work week, instead of burning the midnight oil and throwing in last-minute (but essential) features, as they had had to do in the previous release. The PM, Janet, and I went before the Executive Project Board at City Power & Light. Our argument was simple: We could better avoid feature deficiencies in the next release if we were able to combine the requirements, design, and implementation phases by collaborating with a small number of users. By having only a small number of users participate, we hoped to ensure that we would not affect the business.
A second, smaller release was planned to include a presence indicator, a "do-not-disturb" switch, and other status features, in addition to GUI changes that were related to usability. We decided to add a prototyping effort—an idea that we borrowed from evolutionary software-development processes—to our existing waterfall process at City Power & Light. We still did a requirements document, but it was abbreviated, and it was not considered complete until the prototype was complete.
At this point, it is worthwhile to explain why I suggested that we try prototyping. In the mid-to-late 1990s, eXtreme Programming (XP) had not yet entered the scene. However, the concept of agile-development processes did exist and usually took the form of evolutionary or prototype-based systems. We met many of the conditions that were considered important factors for prototyping.
Firstly, we had to get the second release completed in a compressed time frame. Secondly, we believed that we had a small set of features to add (small scope), and that most of them were related to GUI/usability. In my own experience, the GUI/presentation tier of a distributed system often incurred the highest user-satisfaction risk in the project. Much of what makes a GUI easy to use is best determined by doing user-centered design, prototyping, or some combination of similar techniques.
Prototyping helps by making a system available quickly to a sample of end users who, by using the prototype, can make suggestions for changes and additions during the development phase. By using prototyping, we were able to bring end users into our project as collaborators. This had the effect of getting automatic buy-in and support for this subsequent release of the application, and creating stronger trust relationships among the project-team members and the stakeholders. To this day, I still strongly recommend that a prototype of the presentation layer be created as early as possible in a project, whenever it is feasible to do so.
Although an excellent form of rapid application development, prototyping can lead to significant scope and feature creep. And this is what we experienced during the second release of our system. Our developers had difficulty maintaining control over the number of new requests and features that users made during the second release. Because we all wanted to please our business users, and because they embraced the new system, given their participation in its creation, it was natural for both sides to find new features that would make the collaboration system more powerful and, thereby, expand the scope of the system release. In the end, several front-end presentation features that required business-tier support were promised, which resulted in the missing of our release date and more overtime than any of us would have liked—again.
When we readied ourselves for the third release, we reconsidered using the same method. We found in short order that, although the second release became extraordinarily popular, performance had degraded. This was due in part to all of the additional features that end users had requested, such as meetings (multicasting) and broadcasting. The increased scope also resulted in an expansion of the user base. And the increased usage, in turn, resulted in significant latencies and delays in normal chat conversations, as well as jitter in multimedia support.
Because our performance had degraded significantly after the second release, we knew that we had to improve our software-engineering approach to help us identify as many of our bottlenecks as early in our software-development process as possible—preferably, before we sent our application code for final testing. We did not think that we would have the time to reengineer during the verification phase of the project, which we considered too late in the project life cycle. We again had only a few new features to add. In other words, it was a small release.
What to do? After reviewing our situation, we reviewed our project-team skill levels. Could we adapt our methodology to help us identify performance bottlenecks earlier? Janet and I had both been reading about a new agile-programming methodology that was called eXtreme Programming [Beck, 2000].
One of the things that attracted us to eXtreme Programming was that it advocated pair programming and frequent refactoring for improvement of the application code. The pair programming that we implemented would consist of more experienced programmers being paired with less experienced ones in our project. eXtreme Programming also advocated small releases, frequent builds, and testing of each piece of code before moving on to new code. Also, it recommended joint ownership of the application code by all of the developers equally.
We were at a point in our application at which such ideas had great appeal for us. We had a mature, well-developed system. We had to make performance improvements, and we had only a few features to add this time around. We would ask our programmers to emphasize performance in all new development, and to consider refactoring opportunities to improve performance in our third release.
We did not adopt all eXtreme Programming processes, mind you. We adopted only what we could integrate easily into our existing organization, making small modifications to already extant processes at City Power & Light. This bears repeating: At no point did we ever drop the waterfall methodology that was already in place within the corporation. What we did was tailor the existing methodology to meet our needs. It is important to understand that risk is incurred when you change largely human processes. Like all other forms of risk, this kind of risk must be managed, and we did so by making small alterations to existing processes—not by dropping ours in favor of another.
In the end, we were very pleased with the results. We did, in fact, improve the application code in many ways, and performance did get much better. Another happy side effect of the effort was that the application source code also improved significantly; it was far more manageable, modifiable, and readable. These improvements gave us more easily maintainable code, with better scalability and more deployment options.
Enhanced scalability allowed us to add more nodes/servers to improve performance, as needs grew. In retrospect, we were very fortunate that our previous successes had earned us the trust of our sponsors, and our close collaboration with our end users earned us the respect and freedom that we needed to allow for some reasonable experimentation with new development techniques.
In the end, solution development is as much art as process. Because we are architects, we often emphasize processes over people. But, as critical as it is to employ discipline and best practices, it is also important to recognize that process rigidity does not necessary lead to success. In the case that we just reviewed, flexibility and a willingness to adapt long-standing practices in small ways, without accumulating excessive risk, can be as important as any other factors.
· When considering artifacts, what factors do you consider when you tailor the number and detail level of the artifacts that you will produce?
· How do you gain support for procedural changes when you have a project in trouble?
· What is the most effective way to prevent scope creep when you are creating a prototype of a system?
· [Beck, 2000] Beck, Kent. eXtreme Programming eXplained: Embrace Change. Reading, MA: Addison-Wesley Professional, 2000.
· [Wikipedia] Wikipedia contributors. "Waterfall model." Wikipedia, the Free Encyclopedia. 2007. (Cited January 10, 2007).
· Ambler, Scott W. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. New York: John Wiley & Sons, Inc., 2002.
· Cockburn, Alistair.Writing Effective Use Cases.Boston: Addison-Wesley Professional, 2001.
· Sommerville, Ian.Software Engineering. Sixth ed. Harlow, England; New York: Addison-Wesley, 2001.
Evolutionary process—A software-development process that combines the requirements-phase, design-phase, and implementation-phase activities of the waterfall process to develop rapidly a working demo or prototype of the software. In this way, end users can take a more active role in designing the software that they will use in collaboration with the project team.
Waterfall process—A linear, sequential software-development methodology that is divided into phases. A preceding phase must complete, before the next phase can begin.
About the author
Maureen Lecuona has over 27 years of IT industry experience, which spans employment in several major technology companies. She is an IBM-certified IT Architect, and is currently a practicing enterprise architect for a large financial information firm. Maureen holds an MS in CS from NJIT, a BA in Mathematics from Rutgers, and a BA in English Literature from Rutgers, too. She can be reached at email@example.com, when she isn't skydiving.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.