.NET Brings the Architect to the Fore
As .NET helps advance Microsoft technologies in the enterprise, the role of the software architect becomes increasingly important.
by Eric Lynn
April 2003 Issue
Recently, while attending JavaOne in San Francisco, Calif., I was struck by the number of attendees who identified themselves as software architects. In enterprises that focus on Microsoft development technologies, on the other hand, the position seems to have less prominence or isn't represented at all. I believe this isn't a coincidence, but I'm convinced that with the wide adoption of .NET, the role of software architects in Microsoft-focused enterprises is about to change. As I discuss the role of the software architect in the enterprise, I'll explain why the nature of .NET makes this role critical to the success of enterprise-level development efforts. I'll also cover how Microsoft's recognition of the importance of the software architect in .NET development has led it to offer new support resources for architects. With a proper understanding of the role an architect plays in the enterprise, you'll be better equipped to leverage their skills in your development efforts.
First, let me offer my definition of an architect. All too often development organizations create the architect position as a lead developer with a certain number of years of experience. Marc and Laura Sewell, authors of The Software Architect's Profession, write this practice "is akin to a talented plumber receiving promotions for his or her fine plumbing work until, finally, being promoted to an architect." An architect is much more than an effective and experienced technologist. He or she will likely have development and engineering experience and might even come from the ranks of senior or lead developers, but the roles he or she has played and the skills the position requires are quite distinct.
To explain the differences, I'll review three functions of the architect. First, an architect sees the world in term of forces to be balanced. Security is critical, but it must be balanced with ease-of-use. Performance can't be ignored, but the fastest design might be impossible to maintain or too difficult to develop to meet time-to-market requirements. An effective architect thinks creatively within the context of his experience to discover a range of solutions that balance the system of forces that apply to the target solution. He's aware of the standard forces, such as maintainability, performance, security, supportability, stability, scalability, and time to market. And he searches for the unique forces that apply to the project at hand.
Second, the architect must become the intermediary between the business and technical worlds. She must speak both languages, having the ability to see business issues through a technical lens and technical issues in a business context. Being bilingual, she becomes the advocate for users, business sponsors (those responsible for the return on investment, or ROI), and developers (see Figure 1).
For users, the architect helps mold an aesthetic vision and identify functional needs. She can translate the results into words and pictures that become the "blueprint" all parties can agree on. At the same time, the architect must communicate reality to the user. If you're building a new home, the architect is the one who tells you that building a round house is cost-prohibitive, but then proposes some different ways to work curves into the design. Because the architect listens carefully to and understands the user's needs, she's able to propose a solution the user is likely to approve of.
As a third-party project member who has experience and integrity, the architect can also make sure the construction crew (the developers) doesn't simply reject a design because of a lack of experience or discomfort with the techniques or technologies required. Any good manager knows that when a software developer tells him something can't be done, he needs to follow-up with questions to determine just what that means.
For business sponsors (who might or might not be the same as the users), the architect plays an early role in translating a business vision into a successful implementation. Architects must be able to explain the value proposition of current technologies. They most often think in terms of "why" and "when" rather than "how." They live and breathe ROI. The architect creates early cost estimates used to define scope. She also identifies risks that will drive the development schedule.
The architect also has the broad experience to bridge platforms, vendors, languages, and hardware. If a business sponsor explains the goals of a project and the architect proposes a single solution immediately, you're probably not working with a true architect. As one colleague of mine put it, "A senior developer is the one with all the answers; an architect is the one with all the questions."
For developers, the architect delivers a blueprint with the right level of detail. It describes user needs and selects high-level technical approaches. It provides well-defined runtime environments and interfaces. At this point, the architect has already made the buy vs. build decisions and has purchased the specified components. The blueprint also indicates reuse opportunities within the enterprise. The architect describes the elements that will need to be built in, the language of high-level models, and design patterns. In a few architecturally significant use cases, the architect might describe details at a sequence-diagram level, but the majority of the time, the development team decides construction details and styles.
Third, the architect maintains conceptual integrity over the development lifecycle. Architects make sure that, in the heat of the battle, the mission doesn't get lost. Working under the pressure of implementation schedules and technical hurdles, developers sometimes make decisions that cause a project to veer away from the business goals. The architect must make sure that the mission isn't undermined at any point in the development process. If compromises are required, the architect works with developers to discover a range of possible design alterations. It's the architect's responsibility to communicate these options, along with their ramifications, to users and business sponsors.
Java: The Architect's Playground
In most Microsoft development environments where I've worked, the architect's responsibilities were either unfilled or split between senior developers and project managers. In the past Microsoft training and resources catered almost exclusively to developers, with a focus on the "how" rather than the "why" or the "when." In many ways, there was a "brain drain" of architects from Microsoft shops into the Java world. It became almost a rite of passage for those with architecture skills to "grow up" and enter the ranks of Java architects. Java became the standard language for describing design patterns or other topics of interest to architects.
I believe .NET changes all that, and that architects will find scope for their skills within this new platform. .NET is different from previous Microsoft technologies in three ways of primary concern to architects.
First, .NET creates a cohesive approach to the enterprise. Previous Microsoft initiatives aimed at the enterprise were little more than a hodge-podge of products—often overlapping and incompatible. Microsoft always worked hard to make individual applications programmable, but its attempt to provide integration wasn't much more than a failed extrapolation of this programmable application paradigm. The .NET initiative does a much better job of taking all the Microsoft tools and products and making them effective building blocks.
The introduction of XML Web services gave Microsoft the impetus (and the excuse) to rewrite the ineffective communication layer between their products. This shift toward collaborative-focused products from application-focused products makes .NET fundamentally different in ways that give the enterprise architects a wide range of options. The transition is still in full swing as Microsoft products are being rewritten to be aware of, fully support, and run completely within the .NET platform.
But Microsoft has gone farther and has taken this collaborative focus into the development environments. While rewriting the communication layer, Microsoft designers decided to improve the programming layer. Designers have collapsed the various programming paradigms down to a single vision—the common language runtime (CLR)—without reducing it to a single language.
These changes combined provide the architect with a brand new set of tools. He can employ power tools such as BizTalk Server and Commerce Server or work with development teams equipped with a whole new set of high-precision hand tools from Visual Studio .NET (VS.NET).
Second, .NET lowers the barriers around "best practices." The Microsoft architect of the past couldn't always bring to bear the "best practices" presented by leading architectural thinkers in the industry. Limitations with Visual Basic and Active Server Pages (ASP) forced architects to decide between working with C++ and incurring the increased cost, or restricting their solutions to environments that couldn't fully implement industry standard design patterns. Incompatibilities in communication layers and cultural segregation made mixed environments of C++ and Visual Basic rare.
Technology weaknesses forced different approaches for each tier. ASP was particularly weak. Although Visual Basic struggled to implement object-oriented (OO) features, ASP could barely support structured programming. The architect spent much of his time refactoring AntiPattern solutions created by weak technology rather than designing creative business solutions.
.NET brings first-class object-orientation to every language and to every tier. For example, SQL Server will support .NET languages for stored procedures in the next iteration. The architect no longer has to choose between rapid application development (RAD) and OO. C# and Visual Basic .NET can fully support object-oriented, pattern-oriented design. Design paradigms aren't dictated by tier. The architect isn't forced to push functionality to a particular tier simply because it supports a programming paradigm that can produce maintainable code.
.NET, in some ways, leapfrogs the Java environment to provide support for architecturally significant trends in the industry. Its wide support for attributes provides a mechanism for Aspect-Oriented Programming (AOP) in a much simpler and integrated way than what is currently available in the Java platform.
Third, .NET provides an explosion of viable architectural options. Previous iterations of Microsoft technologies often contained a range of options, but it was widely known that many of them couldn't scale, required unacceptable security policies, or were remnants of some half-baked Microsoft initiative that had been abandoned subsequently. Business sponsors building development teams realized they needed lead developers who were aware of the pitfalls, tricks, and workarounds specific to the Microsoft technology rather than architects with a broad understanding of software design and development.
Design resources coming from Microsoft and third-party training companies tended to focus on the right way to implement Microsoft-distributed solutions, instead of providing a catalog of options. In the pre-.NET era you didn't learn "best practices," you learned the "best practice." You learned to build a stateless middle tier. You learned you should deploy a Web client to reduce distribution and support costs even though the UI might be brutally difficult to use. You learned to pass data between the tiers in disconnected ADO recordsets. You learned you must get as much logic as possible out of ASP. You learned to stay away from the server controls in ASP. Many of these "best practices" were more about the immaturity of the platform, tools, and communication layer than about ways to fuse the business needs with technology to meet the needs of the user.
.NET Provides Architects With Choices
Fortunately, .NET provides a range of viable options that actually work and represent meaningful alternatives. The architect has a choice between XML Web services and .NET Remoting. The architect can select from any number of object serialization approaches ranging across the entire spectrum of OO and relational approaches. Language choices are available within development teams and even within a single project. New deployment options decouple the decision about the client runtime platform from the cost of distribution. First-class support for mobile device programming in Visual Studio 2003 continues to increase the options available to the architect.
All these changes in the Microsoft development environment do more than support the role of architect within the enterprise; they make it critical to the future success of software initiatives. Training, development resources, and the structure of development organizations must mature with the .NET platform. Unfortunately, in many ways this is not happening today. Business sponsors are still looking to senior developers and managers to transition to the .NET platform in the same way that previous transitions were made. Those senior developers and managers are looking for the .NET "best practice," rather than understanding that .NET is about a range of options that balance forces. Training organizations and support literature have often remained focused on the "how" over the "why" and the "when."
Ironically, I find that architects that left Microsoft and moved into the Java/J2EE world better understand the paradigm shift required to transition to .NET. My own experience in transitioning to Java/J2EE brought me into the world of design patterns and gave me a much broader architecture understanding. Those skills were exactly what I needed as I began to work with companies making the transition to .NET. I believe the path to .NET will be easier for those who have exposure to Java.
Microsoft has begun to realize the importance of the architect to the success of .NET and has created a new small-group forum called the Microsoft Architect Roundtable. This forum addresses issues that have both business and technical elements (see the sidebar, "Microsoft's View of the Architect"). The company has also created new initiatives, including the .NET Architecture Center and Microsoft Patterns and Practices (see Resources). These initiatives are beginning to move the focus onto the "why" and the "when" necessary to implement .NET technologies in the enterprise successfully. For example, as an architect you would want to know what options you have for business entity persistence and why you might choose one over another. Articles on MSDN show five options and discuss the benefits and limits of each approach (see Resources). Or you might want to know how well ADO managed transactions scale when compared to COM+ initiated transactions. Or how much faster DataReaders are than a DataSet. Now, you can turn to MSDN and other resources to get some answers that will help architects, as well as developers, make smart choices.
The transition to .NET from previous Microsoft technologies is more than a technology transition. The maturity of the platform requires that you rethink and rework application design and development methodologies. You should also reconsider team structures. For many organizations, the transition to .NET should include the introduction or promotion of the role of the architect.
About the Author
Eric Lynn is the CEO of DeltaPoint Solutions—a company that facilitates the transition to new technologies. Eric is an architect with 12 years of hands-on experience in both Microsoft and Java technologies. He is the Chairman of the Microsoft Architect Roundtable for the Mid-America District. Reach Eric at .
|