In a recent article, “Add Value in an outsourcing economy,” I made the following observation:
“…even though much of the actual development and support can be moved to lower-cost providers, the ability to break business requirements down into repeatable and replicated technology elements is not so easy to move outside of the building. You can begin encouraging your staff to be intimately involved in the movement toward patterns-based systems and software development.”
Several readers have asked me to be more specific in my views toward corporate adoption of patterns-based systems and the inclusion patterns as part of the standard software development lifecycle. Let's look at each of these issues in more detail.
Why patterns matter
As hardware platforms evolve, we’re able to solve more complex problems with more advanced software development tools and environments designed to take advantage of the increased speed and capacity provided by the platform. If you look at the types of problems we’ve been solving with computer technology during the past 40 years, the problems themselves can be categorized into common application types (financial and accounting systems, customer management systems, factory control and automation systems). But the systems themselves can be further decomposed into common software patterns that define not only how the individual functions work but also how they communicate with each other.
These “design patterns” allow programmers to create reusable, object-oriented objects that can be combined to create new systems more quickly and efficiently. Once architects and developers understand how to use design patterns as part of the system architecture and development process, they can use the same ideas and concepts to create applications on any hardware and software platform that supports object-oriented development. There’s a common misconception that these design patterns are somehow created. But design patterns are actually discovered by analyzing the common interactions between objects that have happened over years of systems analysis and software development.
A history of design patterns
Most software design experts attribute the current interest in software architecture using design patterns to the early work done by the Smalltalk community in the late '80s to define a common user interface framework. The Model-View-Controller framework divides the user interface into a Data Model, a View, and a Controller. The Controller manages interaction between the user’s View of the system and the computational elements of the program encapsulated in the Data Model.
Using this pattern, developers can create systems that separate each of these functions into independent objects and tightly define the communication that occurs between them. When done properly, the same Data Model can create multiple Controller and Views (and vice versa), allowing rapid development and enhancements of systems based on this simple concept.
The bible for design patterns, “Design Patterns: Elements of Reusable Object Oriented Software,” was released in 1994 as the result of a series of technical meetings that took place in the early '90s in an effort to promote the formal recognition of design patterns in the software development process. This book, referred to as the Gang of Four book (in deference to its four authors), describes 23 common patterns and how developers can use them to solve common software engineering problems. In J2EE shops, this book has become the de facto reference manual for system architects.
The patterns movement
Java developers creating enterprise software on the J2EE platform have harnessed the power of designing applications by first recognizing the common patterns that they implement and then constructing application objects using well-defined and standard practices; these practices are based on work done in the Java language using the Gang of Four patterns.
As the J2EE platform continues to gain a foothold in corporate America, much of its success can be attributed to developers’ ability to rapidly create new systems because of their understanding of these patterns. Until recently, most of the patterns-based work has been done on the J2EE platform.
But as Microsoft has recognized not only the power of patterns-based development but also the corporate acceptance of the pattern paradigm, its emphasis on arming its own consultants and those of key partners has steadily increased. In fact, Microsoft’s Patterns and Practices team has begun building an arsenal of information to assist all Microsoft customers in implementing systems based on common software patterns using the Microsoft enterprise platform.
Joining the movement
If they’re not already doing so, CIOs should be working with their architects and development teams to educate them on the value of developing reusable, object-oriented software using patterns. The beauty of placing the emphasis on system design using patterns rather than focusing on the deployment platform is that systems can be architected properly without regard for the platform on which it will ultimately be deployed.
Once the platform has been determined, developers can optimize the patterns-based architecture for the specific idiosyncrasies of the platform. But the architecture will be reusable for other platforms and can serve as the blueprint for how systems can interoperate regardless of the underlying platform. The end result is highly composable, interoperable software whose concepts can carry forward to new hardware platforms as they continue to evolve.